1.8+ (1.9) SunOS/Soalaris install problem

[Jan 'RedBully' Seiffert]

John Arbash Meinel wrote:
> Jari Aalto wrote:
>> $ uname -a
> 
>>    SunOS host 5.9 Generic_122300-32 sun4u sparc
> 
>> $ gcc --version
>>    gcc (GCC) 3.4.5
> 
>> The 1.7 installed ok, but the 1.8 and 1.9 gives following errors. Could
>> someone know what is needed?
> 
>> Jari
> 
> ...
> 
>> gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include/python2.5 -c bzrlib/_dirstate_helpers_c.c -o build/temp.solaris-2.9-sun4u-2.5/bzrlib/_dirstate_helpers_c.o
>> In file included from bzrlib/_dirstate_helpers_c.c:31:
>> bzrlib/_dirstate_helpers_c.h:8:20: stdint.h: No such file or directory
>> bzrlib/_dirstate_helpers_c.c: In function `__pyx_f_19_dirstate_helpers_c_13ProcessEntryC__process_entry':
>> bzrlib/_dirstate_helpers_c.c:3712: warning: '__pyx_exc_lineno' might be used uninitialized in this function
> 
>>   Failed to build "bzrlib._dirstate_helpers_c".
>>   Use --allow-python-fallback to use slower python implementations instead.
> 
>> error: command 'gcc' failed with exit status 1
> 
> 
> We are expecting to find 'stdint.h' because we are looking for the
> "intptr_t" type.
> 
> Do you know where it is supposed to be found on Sun OS?
> 

In stdint.h on C99 Systems.
But since gcc 3.4.5 is not really C99 (and you are not passing any "-std=" to
the compiler) you may try inttypes.h
At least this works on:
> $ l /usr/include/inttypes.h
>       9299 -rw-r--r--   1 root     bin         2094 Apr  6  2002 /usr/include/inttypes.h
> $ uname -a
> SunOS host 5.9 Generic_122300-30 sun4u sparc SUNW,UltraAX-i2
> $ gcc --version
> gcc (GCC) 3.2.2

And once even gcc-2.95.5.

Unfortunatly there is no #if header_exists so one have to work around with the
typical HAVE_* passed on the command line by the -D switch, like:
#ifdef HAVE_STDINT_H
# include <stdint.h>
#else
# include <inttypes.h>
#endif

> $ HAVE_STDINT_H=`echo "#include <stdint.h>" | gcc -x c -E - 2>&1 > /dev/null && echo HAVE_STDINT_H || echo HAVENOT_STDINT_H`
> $ gcc -D$HAVE_STDINT_H -foo -fbar ...

Maybe some fiddling with the redirection...

> At the moment we have this code block:
> 
> #ifndef _DIRSTATE_HELPERS_C_H
> #define _DIRSTATE_HELPERS_C_H
> 
> /* for intptr_t */
> #ifdef _MSC_VER
> #include <io.h>
> #else
> #include <stdint.h>
> #endif
> 
> #endif
> 
> We can certainly extend that for Sun, even if it is only "ifdef SUN:
> typedef int intptr_t
> "
> 

Uhm, no, that makes my stomach hurt. Yes in this specific routine, this may
work, but when someone starts to use it for something else...

> We use that as part of this code:
> 
> cdef int _is_aligned(void *ptr):
>     """Is this pointer aligned to an integer size offset?
> 
>     :return: 1 if this pointer is aligned, 0 otherwise.
>     """
>     return ((<intptr_t>ptr) & ((sizeof(int))-1)) == 0
> 
> I believe "intptr_t" is an integer large enough to hold a pointer,

Yes

> and is necessary because some things really don't like it when you do
> integer math on a "void *".

It's not about 'like', it's about binary operations (& | ^ ~) are not defined on
pointer types. In normal operation, what would be their result?
This alignment check is a deep poke into the binary representation of a pointer,
normally opaque by the C-Standard. But works on most common hardware platforms.

> 
> John
> =:->
Greetings
	Jan