bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] Building gettext-0.18.3.2 for G4 processor fails in un


From: Daiki Ueno
Subject: Re: [bug-gettext] Building gettext-0.18.3.2 for G4 processor fails in unsetenv.c
Date: Tue, 06 May 2014 15:21:17 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Peter Dyballa <address@hidden> writes:

>       time env LANG=C 
> PATH=/Developer45/usr/bin:/usr/local/texlive/2013/bin/x86_64-darwin:$PATH 
> ./configure --target=ppc-apple-darwin10.8.0 --build=i686-apple-darwin10.8.0 
> --prefix=.../wp2latex.3.65/build --libdir=.../wp2latex.3.65/build/lib-G4 
> --enable-shared=no --disable-csharp --disable-openmp --disable-acl 
> --disable-libasprintf --disable-rpath --with-pic 
> CPPFLAGS="-I.../wp2latex.3.65/build/include" CFLAGS="-arch ppc -isysroot 
> /Developer45/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -mcpu=G4 -m32 -H 
> -pipe -fPIC -fast -mtune=G4 -mpowerpc-gfxopt -faltivec -maltivec 
> -mabi=altivec -pthread -finline-functions" LDFLAGS="-arch ppc 
> -Wl,-dead_strip_dylibs -Wl,-bind_at_load -Wl,-t" CC=gcc-4.0 CPP=cpp-4.0 
> CXX=g++-4.0 CXXCPP="g++-4.0 -E" LD=gcc-4.0 OBJDUMP=gobjdump

I'm totally unfamiliar with the cross compiling on Mac OS X, but is the
above supposed to work?  When I cross compile something on GNU/Linux, I
do:

  ./configure --host=x86_64-w64-mingw32

then CC, LD, etc are automatically set to:

  CC = x86_64-w64-mingw32-gcc
  LD = /usr/bin/x86_64-w64-mingw32-ld

and those tools pick the correct system headers and library paths.

>       checking for unsetenv... yes
>       checking for unsetenv() return type... int
>       checking whether unsetenv obeys POSIX… no

I have no idea why this is detected as 'int', while the actual return
value seems to be void when compiling:

>       unsetenv.c: In function 'rpl_unsetenv':
>       unsetenv.c:123: error: void value not ignored as it ought to be
>       make[4]: *** [unsetenv.lo] Error 1

Are you able to check what is happening there by writing some small test
programs?  For example, similar to the one used in the configure script:

$ cat >test-unsetenv.c <<EOF
#undef _BSD
#define _BSD 1 /* unhide unsetenv declaration in OSF/1 5.1 <stdlib.h> */
#include <stdlib.h>
extern
#ifdef __cplusplus
"C"
#endif
int unsetenv (const char *name);
EOF

$ gcc ...ppc64 CFLAGS... -c test-unsetenv.c

> So obviously in unsetenv.c neither
>
>       extern void unsetenv (const char *);
>
> nor
>
>       extern int unsetenv (const char *);
>
> happens, only
>
>       # undef unsetenv
>
> in the #else part of the #if _LIBC || !HAVE_UNSETENV clause.

I think this is unreleated, since those declarations are in stdlib.h and
unsetenv.c has #include <stdlib.h>.

Regards,
-- 
Daiki Ueno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]