Re: build/1458: compile failed on hpux11

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

The following reply was made to PR build/1458; it has been noted by GNATS.

From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: heppe@techsoftamerica.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: build/1458: compile failed on hpux11
Date: Fri, 18 Jun 2004 00:32:17 -0400 (EDT)

 Okay, I see the problem.
 
 I was depending on an internal mechanism of configure scripts to avoid
 this problem.  But it looks like that mechanism was modified in gdb
 6.1.1 and perhaps gdb 6.1.  So I will have to find another fix.
 
 Here's another a recapitulation of the analysis:
 
   intl/gettextP.h has code with "static inline nls_uint32 SWAP(i) ..."
   intl/configure has an autoconf test for "inline"
   but the test is only for "inline", not "static inline"
   so the autoconf test says that your compiler supports "inline"
   autoconf enables ac_cv_c_inline
   but that is not enough for "static inline ..."
 
 If you look carefully in the build log, you can see that different
 subdirectories give different results for the 'inline' test:
 
   Configuring in libiberty
   checking for inline... no
   ...
   Configuring in bfd
   checking for inline... inline
   ...
   Configuring in intl
   checking for inline... inline
 
 The libiberty/configure test says:
 
   typedef int foo_t;
   static inline foo_t static_foo () {return 0; }
   inline foo_t foo () {return 0; }
 
 This is a good test and it works on your platform,
 disabling ac_cv_c_inline.
 
 libiberty/configure and intl/configure shared a cache, so that the good
 libiberty/configure test would go first and suppress the bad
 intl/configure test.  I was counting on that cache to make
 intl/configure re-use the results of the good libiberty/configure test.
 
 (The difference between libiberty/ and intl/ is that libiberty/
 was processed with autoconf 2.59, and intl/ was processed with
 autoconf 2.12.1).
 
 But as of 2004-01-04, these two directories do not share a cache
 anymore, so intl/configure runs its own bad test and gets the bad result
 for ac_cv_c_inline.
 
 Here's something to try:
 
   export ac_cv_c_inline=no
   configure ; make ; make install
 
 I haven't tried this on an hppa-hpux machine yet, but I did try it
 on native i686-pc-linux-gnu, and it did force all the 'inline'
 tests to 'no'.
 
 Can you try that on a fresh build, and mail in the output from
 'configure' and 'make' and 'make install'?  (I don't need the
 output from unpacking the tarball, though).  The most interesting
 lines are the 'inline' tests in 'make'.
 
 This problem in intl/configure has already been fixed in the
 gcc version of the intl/ subdirectory, so it ought to be fixed
 for good the next time someone imports gcc/intl to src/intl.
 If the "export ac_cv_inline=no" works for you, I'll ask about
 getting that to happen.
 
 Michael C