bug-coreutils
[Top][All Lists]
Advanced

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

coreutils-7.1 - Compile Issue - Assuming defined preprocessor symbols ha


From: Peter Bray
Subject: coreutils-7.1 - Compile Issue - Assuming defined preprocessor symbols have a value
Date: Fri, 27 Feb 2009 06:10:04 -0800 (PST)

Hi All,

  I ran into a small problem compiling coreutils-7.1 on Solaris 10. The problem 
only occurred on Solaris 10 SPARC in 64-bit mode, and not Solaris 10 x86 in 
64-bit, all with gcc 4.1.2. The problem does not occur in either SPARC or x86 
when compiling for 32-bit binaries (for obvious reasons). But the problem is a 
little more generic in nature.

  In lib/inttypes.in.h the following line appears 4 times:

#  if (@APPLE_UNIVERSAL_BUILD@ ? _LP64 : @INT64_MAX_EQ_LONG_MAX@)

  The problem arises if _LP64 is defined but does not have a value. The error 
seen is "error: operator '?' has no right operand". It seems that Sun include 
files (specifically /usr/include/sys/isa_defs.h) have the following definition:

#define        _LP64

  It seems that someone has updated build-aux/config.guess after noticing a 
similar problem for __LP64__ when using Sun cc vs GCC, but I'm using GCC and to 
confuse me even more 'cpp -dM /dev/null' says _LP64 is 1, I'm guessing that 
isa_defs.h is redefining it.

  I'm not sure of the correct solution to this problem, using 
CFLAGS="-D_LP64=1" did not help, probably due to the redefinition mentioned 
above.

  I wish I could help more by providing a patch, but I'm not sure of the right 
approach. I considered trying to stringify the symbol and test it against the 
empty string to see if I needed to redefine it. But my cpp skills are buried in 
parts of my brain which are having access issues :-( Also I currently have 
access to gcc-4.1.2 on Solaris 10, not exactly a wide and varied range of 
testing platforms and compilers.

Regards,

Peter Bray
Sydney, Australia

PS: If you are running into this problem and _know_ that its safe to set _LP64 
to 1, then placing a "#define _LP64 1" on the line immediately before the first 
instance of its use in lib/inttypes.in.h and rebuilding will get you a 
functional (test suite passing save ls/color-clear-to-eol for which a patch 
exists) on Solaris 10 SPARC64.

PSS: All but ls/color-clear-to-eol pass on Solaris 10 Update 6 with gcc-4.1.2, 
in all combinations of {SPARC,X86} with {32-bit,64-bit} executables.




      Stay connected to the people that matter most with a smarter inbox. Take 
a look http://au.docs.yahoo.com/mail/smarterinbox




reply via email to

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