When cross-compiling libstdc++, LFS support is turned on unconditionally, even if the target does not support LFS. As a result, linking fails (there is no fseeko64 for the target). May be related to #22388
Created attachment 12854 [details] Add configure option to en- or disable-largefile libstdc++/ChangeLog 2007-01-04 Bernhard Fischer <aldot@gcc.gnu.org> PR libstdc++/30365 * configure.ac: Add AC_SYS_LARGEFILE to add --{en,dis}able-largefile. * acinclude.m4 (GLIBCXX_CHECK_LFS): Only define _GLIBCXX_USE_LFS if LFS was not turned off. * crossconfig.m4: Ditto. configure needs to be regenerated, but i don't have the needed 2.59 autoconf version anymore.
First uclibc really should support Large file support either the way BSD handle it (in my mind the correct way) or the way SYSV does. If this code can even compile, then uclibc's headers are inccorect in saying it supports fseeko64.
I don't understand: looking at configure.ac, GLIBCXX_CHECK_LFS is run *only* if $GLIBCXX_IS_NATIVE is true. Otherwise, _GLIBCXX_USE_LFS remains undefined... By the way, *when* _GLIBCXX_USE_LFS is defined, the library uses lseek64 (in basic_file_stdio.cc), *not* fseeko64, and I'd like to also understand how possibly on this target the former is called from somewhere?!?
Hmm: case "$target" in *-uclinux*) # Don't enable LFS with uClibc ;; *) AC_DEFINE(_GLIBCXX_USE_LFS) esac
(In reply to comment #2) > First uclibc really should support Large file support either the way BSD handle > it (in my mind the correct way) or the way SYSV does. The user can optionally turn it off. This is a feature for folks that *know* that their devices only have let's say 64MB unified storage anyway. > > If this code can even compile, then uclibc's headers are inccorect in saying it > supports fseeko64. You're right in that it doesn't compile. It complains about an unknown func fseeko64. As you can see in crosscompile.m4, LFS is turned on unconditionally for anything that is not uClinux and i'm on linux, not uClinux.
(In reply to comment #3) > By the way, *when* _GLIBCXX_USE_LFS is defined, the library uses lseek64 (in > basic_file_stdio.cc), *not* fseeko64, and I'd like to also understand how > possibly on this target the former is called from somewhere?!? Sorry, this last point of mine is wrong: forgot that currently the library also uses fseeko64, in stdio_sync_filebuf.h
removing wrong keyword link-failure
(In reply to comment #4) > Hmm: > case "$target" in > *-uclinux*) > # Don't enable LFS with uClibc > ;; > *) > AC_DEFINE(_GLIBCXX_USE_LFS) > esac These bits in crossconfig.m4 are not correct, of course (don't know who added that). Given the current implementation, we should safely enable LFS *only* on linux.
By the way, the attached patch seems wrong, because changes GLIBCXX_CHECK_LFS, which is not run at all when $GLIBCXX_IS_NATIVE is false.
(In reply to comment #5) > (In reply to comment #2) > > First uclibc really should support Large file support either the way BSD handle > > it (in my mind the correct way) or the way SYSV does. > > The user can optionally turn it off. This is a feature for folks that *know* > that their devices only have let's say 64MB unified storage anyway. But it could connect to a network device which is going to be larger .... > As you can see in crosscompile.m4, LFS is turned on unconditionally for > anything that is not uClinux and i'm on linux, not uClinux. The comment does not match up with the actually check :). -- Pinski
(In reply to comment #9) > By the way, the attached patch seems wrong, because changes GLIBCXX_CHECK_LFS, > which is not run at all when $GLIBCXX_IS_NATIVE is false. > The hunk against acinclude.m4 should perhaps be dropped. It was a sledgehammer approach to make sure that if toplevel gcc was configured with --disable-largefile, then absolutely no .*LFS.* was defined. Once again removing the incorrect keyword link-failure.
Another sparse observation: GLIBCXX_CHECK_LFS probably can be changed to be simply an AC_TRY_COMPILE, because in C++ missing prototypes are diagnosed at compile time.
The question is how did JSM get uclibc to work when he patched libstdc++ for it (PR 14939) ? Was he using a newer uclibc which actually has LFS support or something else?
(In reply to comment #10) > (In reply to comment #5) > > (In reply to comment #2) > > > First uclibc really should support Large file support either the way BSD handle > > > it (in my mind the correct way) or the way SYSV does. > > > > The user can optionally turn it off. This is a feature for folks that *know* > > that their devices only have let's say 64MB unified storage anyway. > > But it could connect to a network device which is going to be larger .... Turning off LFS is something the user wanted explicitely. You'd usually have RPC support turned off, no support for networked filesystems, NBDs etc in this case, so there is no chance that this would happen if turned off explicitely.
(In reply to comment #13) > The question is how did JSM get uclibc to work when he patched libstdc++ for it > (PR 14939) ? Was he using a newer uclibc which actually has LFS support or > something else? He forced LFS on for anybody that turned C++ support on (in buildroot, i assume). I've fixed this bug recently to honour the user's explicit settings.
Irrespective of the other "historical" issues, assuming the test can be changed to an AC_TRY_COMPILE, probably can be run also for crosses, we can pass to it an --enable-lfs library configury argument and run it always, for increased flexibility, indeed.
Oh you can turn off LFS in uclibc :). So even disabling it for uclibc directly is not correct. Having a flag might be a good option but I feel it is the wrong thing to do stuff. I really don't think turning off LFS and using libstdc++ is a good idea anyways because STL just bloats things anyways. I have not got even a simple hello world program to use less than 256k of code size/data yet for spu-elf.
(In reply to comment #10) > The comment does not match up with the actually check :). I have a patch pending that fixes all these incorrect occurances of "uclibc" where it ment to say "uClinux". I intended to send it later on as normal patch without a (separate) PR, ok?
(In reply to comment #16) > Irrespective of the other "historical" issues, assuming the test can be changed > to an AC_TRY_COMPILE, probably can be run also for crosses, we can pass to it > an --enable-lfs library configury argument and run it always, for increased > flexibility, indeed. > Note that there is already an AC_SYS_LARGEFILE (i.e. an --enable-largefile, not --enable-lfs). Care to provide a patch which does what you suggested above? :) TIA
Subject: Re: No possibility to disable large file support (LFS) On Thu, 4 Jan 2007, pinskia at gcc dot gnu dot org wrote: > The question is how did JSM get uclibc to work when he patched libstdc++ for it > (PR 14939) ? Was he using a newer uclibc which actually has LFS support or > something else? I configure uClibc with LFS support enabled. Since I made cross-Linux configurations require link tests to work in order to build libstdc++ (because of another area where uClibc is configurable, <math.h> functions), it should be possible to use the link test for LFS support rather than unconditionally enabling it.
(In reply to comment #20) > Since I made cross-Linux configurations require link tests to work in > order to build libstdc++ (because of another area where uClibc is > configurable, <math.h> functions), it should be possible to use the link > test for LFS support rather than unconditionally enabling it. Ah, that would be so simple. On the other hand, do you think changing the test to be a compile test would cause any trouble? In general, I believe the fewer link tests we have the better.
Subject: Re: No possibility to disable large file support (LFS) On Thu, 4 Jan 2007, pcarlini at suse dot de wrote: > ------- Comment #21 from pcarlini at suse dot de 2007-01-04 13:12 ------- > (In reply to comment #20) > > Since I made cross-Linux configurations require link tests to work in > > order to build libstdc++ (because of another area where uClibc is > > configurable, <math.h> functions), it should be possible to use the link > > test for LFS support rather than unconditionally enabling it. > > Ah, that would be so simple. On the other hand, do you think changing the test > to be a compile test would cause any trouble? In general, I believe the fewer > link tests we have the better. uClibc has this unfortunate habit of declaring functions in the headers even if they are configured out and so not present in the library. So for anything involving uClibc, link tests are more reliable.
(In reply to comment #22) > uClibc has this unfortunate habit of declaring functions in the headers > even if they are configured out and so not present in the library. So for > anything involving uClibc, link tests are more reliable. I see, thanks.
Created attachment 12855 [details] nb: includes regenerated configure For now I'd like to go with this simple patch, per Joseph' suggestions. By the way, in the meanwhile I learned that other TRY_COMPILE tests are run under the same heading. Bernhard, can you test it (i.e., check that your cross builds with it)? Thanks in advance.
(In reply to comment #24) > For now I'd like to go with this simple patch, per Joseph' suggestions. By the > way, in the meanwhile I learned that other TRY_COMPILE tests are run under the > same heading. Of course I meant TRY_LINK, sorry.
Subject: Re: No possibility to disable large file support (LFS) "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | I really don't think turning off LFS and using libstdc++ is a good idea anyways | because STL just bloats things anyways. Where is the connection? -- Gaby
(In reply to comment #24) > Created an attachment (id=12855) [edit] > nb: includes regenerated configure > > For now I'd like to go with this simple patch, per Joseph' suggestions. By the > way, in the meanwhile I learned that other TRY_COMPILE tests are run under the > same heading. > > Bernhard, can you test it (i.e., check that your cross builds with it)? Thanks > in advance. > Works like a charm (tested with 4.2). Please install to trunk, 4.2 and 4.1, TIA.
Subject: Bug 30365 Author: paolo Date: Sat Jan 6 22:38:07 2007 New Revision: 120531 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120531 Log: 2007-01-06 Paolo Carlini <pcarlini@suse.de> PR libstdc++/30365 * crossconfig.m4 (case *-linux*): Run crossconfig.m4. * configure: Regenerate. Added: trunk/libstdc++-v3/ChangeLog-2006 Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/crossconfig.m4
Subject: Bug 30365 Author: paolo Date: Sat Jan 6 22:38:41 2007 New Revision: 120532 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120532 Log: 2007-01-06 Paolo Carlini <pcarlini@suse.de> PR libstdc++/30365 * crossconfig.m4 (case *-linux*): Run crossconfig.m4. * configure: Regenerate. Added: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog-2006 Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/configure branches/gcc-4_2-branch/libstdc++-v3/crossconfig.m4
This is not a regression, AFAIK, thus let's have it fixed for mainline and 4.2.0 first. We can consider backporting the change to 4_1 branch later on...