[gnupg-devel] libassuan-0.9.2 build feedback
Werner Koch
wk at gnupg.org
Tue Oct 10 12:57:22 CEST 2006
On Thu, 5 Oct 2006 18:01, Nelson H. F. Beebe said:
> In builds of libassuan-0.9.2 in 34 compilation environments on a score
> of different Unix systems, the builds and validation tests succeeded
> in 18 of them.
Thanks.
> This happens because LDFLAGS is not propagated properly from the
> configure environment to the Makefile. A restart with
>
> make LIBS='-L/usr/local/lib -lpth' all check
>
> produced a successful build and validation.
I have fixed this by not using the pth version of the library in the
test.
> checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t
> 9.45 real 1.59 user 4.42 sys
> make: *** No targets specified and no makefile found. Stop.
>
> Like GNU/Linux on the AMD64 architecture, Mac OS X on the Intel Xeon
> EM64T system provides a 32-bit world and a 64-bit world. Apple
> supplies fat binaries and libraries that contain code for both worlds,
> and often, also for the same worlds in the older PowerPC systems.
> However, at end user sites, preparation of fat files is too
> problematic and failure prone, so I follow the practice on the AMD64
> of having /usr/local/lib32 for 32-bit libraries, and /usr/local/lib
> for 64-bit libraries. Something prevents socklen_t from being seen in
> the 64-bit world on Mac OS X.
Thanks for explaining. Can you cut out the part from config.log where
this happens. Maybe I can find a way to work around it.
> ============================================================
> Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5
> Remote gcc version: gcc (GCC) 3.4.3
> assuan-uds.c: In function `uds_reader':
> assuan-uds.c:73: warning: implicit declaration of function `CMSG_SPACE'
> assuan-uds.c:95: warning: cast increases required alignment of target type
> assuan-uds.c:96: warning: implicit declaration of function `CMSG_LEN'
There are now replacements for this.
> assuan-uds.c:99: error: `SCM_RIGHTS' undeclared (first use in this function)
But unfortunately not for this. Need to check stevens how it worked
with odler systems.
>
> ========================================================================
> Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); FreeBSD 5.0-RELEASE #0
> Remote gcc version: gcc (GCC) 3.4.3
> /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here
> assuan-util.c: In function `__sputc':
> assuan-util.c:31: error: storage class specified for parameter `alloc_func'
Not yet fixed.
> ============================================================
> Machinetype: DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM); OSF/1 4.0F
> Remote gcc version: gcc (GCC) 3.3.3
> assuan-uds.c:85: error: structure has no member named `msg_control'
> assuan-uds.c:86: error: structure has no member named `msg_controllen'
> assuan-uds.c:95: error: structure has no member named `msg_control'
Should work now However without descripot passing. It is not yet used
by gnupg and that should no pose any problem. We will use descriptor
passing merely for performance acceleration.
> ========================================================================
> Machinetype: Sun Sun Fire V240 (2 UltraSPARC-IIIi CPUs, 1280 MHz, 8GB RAM); Solaris 9
> __xnet_sendmsg ../src/libassuan.a(assuan-io.o)
> ld: fatal: Symbol referencing errors. No output written to fdpassing
Might work now as the required libs are now passed to ld.
> ========================================================================
> Machinetype: Sun Ultra Enterprise 450/400 (4 UltraSPARC-II CPUs, 400 MHz); Solaris 7
> ========================================================================
> Machinetype: Intel Pentium 4 (1800 MHz); Solaris 10 x86
> Remote c99 version: cc: Sun C 5.8 Patch 121016-02 2006/03/31
> Configure environment: CC=/opt/SUNWspro/bin/c99 CFLAGS="-I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib"
>
> checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t
Interesting. The code to check socklen_t is from gnulib and thus
should be tests, but well, there must be something wrong.
Salam-Shalom,
Werner
More information about the Gnupg-devel
mailing list