long long size compute failure during make of gcc-4.6.1 on OS X 10.7 Lion

[Bruce Hoglund]

On Sep 7, 2011, at 10:02 AM, Jonathan Wakely wrote:

> On 7 September 2011 14:52, Bruce Hoglund wrote:
>> 
>> On Sep 7, 2011, at 4:27 AM, Jonathan Wakely wrote:
>> 
>>> On 7 September 2011 06:06, Ian Lance Taylor wrote:
>>>> This is probably the wrong config.log file.  You need the one in the
>>>> directory in which configure is being run.  In this case,
>>>> gcc/config.log.
>>>> 
>>>> In general, the bottommost parts of config.log are not helpful.  You
>>>> need to look for the failing test.
>>> 
>>> Which to remind you, was:
>>> configure: error: cannot compute sizeof (long long)
>> 
>> 
>> Yes, thank you.
>> 
>> I simplistically searched for the string "long" & it was not found in the config.log. As a guess, I'd say the failure to compute the size of the long long was a collateral damage effect from some other failure, such as the one I sent Ian:
> 
> No, you looked in the wrong config.log
> 
> As Ian said, you need to look for config.log in the directory where
> configure is being run, that is NOT necessarily the directory where
> YOU ran configure.  When you run the top-level configure it
> recursively runs configure scripts in sub-directories.  One of those
> failed.
> 
> In your case it says there is an error in /Users/bhoglund/tmp/gcc46/gcc:
> 
> checking size of long long... configure: error: in
> `/Users/bhoglund/tmp/gcc46/gcc':
> configure: error: cannot compute sizeof (long long)
> See `config.log' for more details.
> 
> So that's the directory where you need to look in config.log, which as
> Ian said is gcc/config.log
> 
> Look in there, you will find the "cannot compute sizeof (long long)"
> error, with more details.


I have attached the ~/tmp/gcc46/gcc/config.log file. As for understanding…

"
 static long int longval () { return (long int) (sizeof (short)); }
| static unsigned long int ulongval () { return (long int) (sizeof (short)); }
| #include <stdio.h>
| #include <stdlib.h>
| int
| main ()
| {
| 
|   FILE *f = fopen ("conftest.val", "w");
|   if (! f)
|     return 1;
|   if (((long int) (sizeof (short))) < 0)
|     {
|       long int i = longval ();
|       if (i != ((long int) (sizeof (short))))
| 	return 1;
|       fprintf (f, "%ld", i);
|     }
|   else
|     {
|       unsigned long int i = ulongval ();
|       if (i != ((long int) (sizeof (short))))
| 	return 1;
|       fprintf (f, "%lu", i);
|     }
|   /* Do not output a trailing newline, as this causes \r\n confusion
|      on some platforms.  */
|   return ferror (f) || fclose (f) != 0;
| 
|   ;
|   return 0;
| }
configure:5771: result: 0
configure:5785: checking size of int
configure:5790: gcc -o conftest -g -fkeep-inline-functions    conftest.c  >&5
Undefined symbols for architecture x86_64:
  "___builtin___stpncpy_chk", referenced from:
      ___inline_stpncpy_chk in ccL1VweA.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
configure:5790: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */

"

Looks like the checker program ( "confdefs.h") did not have an uptodate idea of w the x86_64 architecture should have or not have, but I may be quite wrong.

While there are other 'failed' "confdefs.h" program examples in this config.log, even an amateur like me was unsurprised by:
	"conftest.c:11:28: fatal error: ac_nonexistent.h: No such file or directory"

I mean, who would have thought ac_nonexistent.h would have no file or directory?  

(That's another of my poor attempts at a joke), and I do appreciate your help and patience!


Bruce


-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: application/octet-stream
Size: 38246 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20110907/6fd423ba/attachment.obj>
-------------- next part --------------