GCC 4.3.0 configure failure: libgcc

GCC 4.3.0 configure failure: libgcc

[James Molloy]

Hi,

I'm attempting to build GCC 4.3.0 - and I thought I had succeeded until 
I realised that the 'all-gcc' make target (now?) doesn't build libgcc.a.

So I'm now trying to make the 'all' target, and I'm getting a configure 
error in the libgcc directory. An extract of the config.log follows:

    configure:4082: g++ -c -g -O2  conftest.cc >&5
    conftest.cc: In function 'int main()':
    conftest.cc:13: error: 'exit' was not declared in this scope
    configure:4088: $? = 1
    configure: failed program was:
    | /* confdefs.h.  */
    |
    | #define PACKAGE_NAME ""
    | #define PACKAGE_TARNAME ""
    | #define PACKAGE_VERSION ""
    | #define PACKAGE_STRING ""
    | #define PACKAGE_BUGREPORT ""
    | /* end confdefs.h.  */
    |
    | int
    | main ()
    | {
    | exit (42);
    |   ;
    |   return 0;
    | }

As you can see, the test program autoconf is generating does not include 
<cstdlib>, so g++ is perfectly correct in erroring.

I'm not certain how to fix this - is it just a case of hacking the 
config.in file? I'd appreciate any help.

Compiling GCC 4.3.0 from source using G++ 4.1.2, autoconf 2.61, and 
automake 1.10.

Thanks,

James

Re: GCC 4.3.0 configure failure: libgcc

[Ralf Wildenhues]

Hello James,

* James Molloy wrote on Tue, May 06, 2008 at 04:24:37PM CEST:
>
> I'm attempting to build GCC 4.3.0 - and I thought I had succeeded until  
> I realised that the 'all-gcc' make target (now?) doesn't build libgcc.a.

>    configure:4082: g++ -c -g -O2  conftest.cc >&5
>    conftest.cc: In function 'int main()':
>    conftest.cc:13: error: 'exit' was not declared in this scope

> As you can see, the test program autoconf is generating does not include  
> <cstdlib>, so g++ is perfectly correct in erroring.

> Compiling GCC 4.3.0 from source using G++ 4.1.2, autoconf 2.61, and  
> automake 1.10.

Use Autoconf 2.59 to generate configure (and Automake 1.9.6).  Better
yet, do not regenerate configure scripts at all, just use those shipped
with 4.3.0.

Newer Autoconf versions don't take care to declare exit any more.
The GCC macros need to be adjusted for this before using newer Autoconf.
I'll post a patch.

Hope that helps.

Cheers,
Ralf

Re: GCC 4.3.0 configure failure: libgcc

[James Molloy]

Ralf Wildenhues wrote:
> Hello James,
>
> * James Molloy wrote on Tue, May 06, 2008 at 04:24:37PM CEST:
>   
>> I'm attempting to build GCC 4.3.0 - and I thought I had succeeded until  
>> I realised that the 'all-gcc' make target (now?) doesn't build libgcc.a.
>>     
>
>   
>>    configure:4082: g++ -c -g -O2  conftest.cc >&5
>>    conftest.cc: In function 'int main()':
>>    conftest.cc:13: error: 'exit' was not declared in this scope
>>     
>
>   
>> As you can see, the test program autoconf is generating does not include  
>> <cstdlib>, so g++ is perfectly correct in erroring.
>>     
>
>   
>> Compiling GCC 4.3.0 from source using G++ 4.1.2, autoconf 2.61, and  
>> automake 1.10.
>>     
>
> Use Autoconf 2.59 to generate configure (and Automake 1.9.6).  Better
> yet, do not regenerate configure scripts at all, just use those shipped
> with 4.3.0.
>
> Newer Autoconf versions don't take care to declare exit any more.
> The GCC macros need to be adjusted for this before using newer Autoconf.
> I'll post a patch.
>
> Hope that helps.
>
> Cheers,
> Ralf
>   
Hi Ralf,

Thanks for the reply. I haven't regenerated the configure script at all, 
I'm using the vanilla one as shipped with the stable 4.3.0 release.

So really I'm not sure if the bug is with autoconf or gcc's config.in - 
I've found a workaround with help from members of freenode.net#osdev who 
have had the same problem - it seems more widespread than I first thought.

The workaround is to compile the targets "all-gcc all-target-libgcc" 
then install "install-gcc install-target-libgcc" - which for some reason 
completes successfully.

I really have no idea why - the same configure script in the libgcc 
subdirectory must be called, surely.

I reply with this in the hope that it will be useful in bug tracking.

Cheers,

James

gcc 4.2.x large file support

[Jonathan Saxton]

I think I have found a problem in the g++ header files concerning large file
support.  I have seen it on two different AIX machines, one running AIX 5.3
and using gcc 4.1.2, the other running AIX 5.2 and using a slightly later
version of gcc, namely 4.2.2.

cstdio carefully #undefs all the routines in stdio.h and then issues a
"using" directive for each.  The problem is that when large file support is
enabled, routines like fgetpos() have been remapped to the 64-bit
equivalents, fgetpos64() in this example.

From stdio.h:

	#ifdef _LARGE_FILES
	  #define fgetpos fgetpos64
	#endif

	#ifdef _LARGE_FILE_API
	   extern int fgetpos64(FILE *, fpos64_t *);
	#endif


Then cstdio does

	#undef fgetpos

and later ...

	using ::fgetpos;

which yields a compilation error because there is no such routine.

The following source code illustrates the problem.

testio.cpp
==========

#include <cstdio>

int main(int argc, char *argv[])
{
   FILE
      *ff;

   ff = fopen("grober.nix", "w");
   if (ff == 0)
   {
      puts("File open failed");
   }
   else
   {
      fprintf(ff, "To a %s, happiness is a warm %s\n",
                       "maggot", "cowpat");
                fclose(ff);
   }
   return 0;
}

When compiled with:
   g++ testio.cpp
no error is elicited and the program (a.out) does what is expected.
Compiling with
   g++ -D_LARGE_FILES testio.cpp
yields

In file included from testio.cpp:1:
/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/include/c++/cstdio:109:
error: '::fgetpos' has not been declared
/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/include/c++/cstdio:111:
error: '::fopen' has not been declared
/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/include/c++/cstdio:116:
error: '::freopen' has not been declared
/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/include/c++/cstdio:119:
error: '::fsetpos' has not been declared
testio.cpp: In function 'int main(int, char**)':
testio.cpp:8: error: 'fopen' was not declared in this scope

All the routines listed in the error messages are subject to the 64-bit
remapping done by stdio.h and broken by cstdio.

Now I tried the same thing on some other platforms, namely
   HPUX ia64	g++ 4.2.2
   HPUX parisc	g++ 4.2.2
   Linux x86_64	g++ 3.4.5
   Linux x86	g++ 3.4.6
and none of those exhibited the problem described above.  I confess that I
do not know why, and it suggests that either my analysis is flawed or the
large file support is not being used by C++ programs on those platforms.

(I noted that _LARGE_FILES and _LARGE_FILE_API are disjoint but I did not
spend any time trying to figure out why.)

Re: gcc 4.2.x large file support

[Michael Haubenwallner]

On Wed, 2008-05-07 at 15:05 -0400, Jonathan Saxton wrote:
> I think I have found a problem in the g++ header files concerning large file
> support.  I have seen it on two different AIX machines, one running AIX 5.3
> and using gcc 4.1.2, the other running AIX 5.2 and using a slightly later
> version of gcc, namely 4.2.2.
> 
> cstdio carefully #undefs all the routines in stdio.h and then issues a
> "using" directive for each.  The problem is that when large file support is
> enabled, routines like fgetpos() have been remapped to the 64-bit
> equivalents, fgetpos64() in this example.

This is http://gcc.gnu.org/PR20366

HTH,
/haubi/