* GCC 4.3.0 configure failure: libgcc
@ 2008-05-06 14:27 James Molloy
2008-05-06 23:25 ` Ralf Wildenhues
0 siblings, 1 reply; 5+ messages in thread
From: James Molloy @ 2008-05-06 14:27 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GCC 4.3.0 configure failure: libgcc
2008-05-06 14:27 GCC 4.3.0 configure failure: libgcc James Molloy
@ 2008-05-06 23:25 ` Ralf Wildenhues
2008-05-07 8:16 ` James Molloy
0 siblings, 1 reply; 5+ messages in thread
From: Ralf Wildenhues @ 2008-05-06 23:25 UTC (permalink / raw)
To: James Molloy; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GCC 4.3.0 configure failure: libgcc
2008-05-06 23:25 ` Ralf Wildenhues
@ 2008-05-07 8:16 ` James Molloy
2008-05-07 21:06 ` gcc 4.2.x large file support Jonathan Saxton
0 siblings, 1 reply; 5+ messages in thread
From: James Molloy @ 2008-05-07 8:16 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* gcc 4.2.x large file support
2008-05-07 8:16 ` James Molloy
@ 2008-05-07 21:06 ` Jonathan Saxton
2008-05-08 7:31 ` Michael Haubenwallner
0 siblings, 1 reply; 5+ messages in thread
From: Jonathan Saxton @ 2008-05-07 21:06 UTC (permalink / raw)
To: gcc-help
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.)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gcc 4.2.x large file support
2008-05-07 21:06 ` gcc 4.2.x large file support Jonathan Saxton
@ 2008-05-08 7:31 ` Michael Haubenwallner
0 siblings, 0 replies; 5+ messages in thread
From: Michael Haubenwallner @ 2008-05-08 7:31 UTC (permalink / raw)
To: Jonathan Saxton; +Cc: gcc-help
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-05-08 6:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-06 14:27 GCC 4.3.0 configure failure: libgcc James Molloy
2008-05-06 23:25 ` Ralf Wildenhues
2008-05-07 8:16 ` James Molloy
2008-05-07 21:06 ` gcc 4.2.x large file support Jonathan Saxton
2008-05-08 7:31 ` Michael Haubenwallner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).