User account creation filtered due to spam.

Bug 30365 - No possibility to disable large file support (LFS)
Summary: No possibility to disable large file support (LFS)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: 4.2.0
Assignee: Paolo Carlini
URL:
Keywords: build, patch
Depends on:
Blocks:
 
Reported: 2007-01-04 11:06 UTC by Bernhard Reutner-Fischer
Modified: 2007-01-06 22:46 UTC (History)
1 user (show)

See Also:
Host:
Target: i586-linux-uclibc
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-01-04 18:45:25


Attachments
Add configure option to en- or disable-largefile (593 bytes, patch)
2007-01-04 11:21 UTC, Bernhard Reutner-Fischer
Details | Diff
nb: includes regenerated configure (1.17 KB, patch)
2007-01-04 20:25 UTC, Paolo Carlini
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Reutner-Fischer 2007-01-04 11:06:20 UTC
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
Comment 1 Bernhard Reutner-Fischer 2007-01-04 11:21:41 UTC
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.
Comment 2 Andrew Pinski 2007-01-04 11:23:49 UTC
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.
Comment 3 Paolo Carlini 2007-01-04 11:27:49 UTC
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?!?
Comment 4 Andrew Pinski 2007-01-04 11:31:25 UTC
Hmm:
    case "$target" in
      *-uclinux*)
        # Don't enable LFS with uClibc
        ;;
      *)
        AC_DEFINE(_GLIBCXX_USE_LFS)
    esac
Comment 5 Bernhard Reutner-Fischer 2007-01-04 11:32:08 UTC
(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.
Comment 6 Paolo Carlini 2007-01-04 11:33:04 UTC
(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
Comment 7 Bernhard Reutner-Fischer 2007-01-04 11:36:31 UTC
removing wrong keyword link-failure
Comment 8 Paolo Carlini 2007-01-04 11:36:44 UTC
(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.
Comment 9 Paolo Carlini 2007-01-04 11:41:29 UTC
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.
Comment 10 Andrew Pinski 2007-01-04 11:45:27 UTC
(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
Comment 11 Bernhard Reutner-Fischer 2007-01-04 11:46:00 UTC
(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.
Comment 12 Paolo Carlini 2007-01-04 11:46:50 UTC
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.
Comment 13 Andrew Pinski 2007-01-04 11:47:48 UTC
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?
Comment 14 Bernhard Reutner-Fischer 2007-01-04 11:49:15 UTC
(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.
Comment 15 Bernhard Reutner-Fischer 2007-01-04 11:51:09 UTC
(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.

Comment 16 Paolo Carlini 2007-01-04 11:53:11 UTC
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.
Comment 17 Andrew Pinski 2007-01-04 11:54:37 UTC
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.
Comment 18 Bernhard Reutner-Fischer 2007-01-04 12:58:18 UTC
(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?
Comment 19 Bernhard Reutner-Fischer 2007-01-04 13:00:49 UTC
(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
Comment 20 joseph@codesourcery.com 2007-01-04 13:07:18 UTC
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.

Comment 21 Paolo Carlini 2007-01-04 13:12:11 UTC
(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.
Comment 22 joseph@codesourcery.com 2007-01-04 13:17:19 UTC
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.

Comment 23 Paolo Carlini 2007-01-04 13:19:38 UTC
(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.
Comment 24 Paolo Carlini 2007-01-04 20:25:46 UTC
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.
Comment 25 Paolo Carlini 2007-01-04 20:31:31 UTC
(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.
Comment 26 Gabriel Dos Reis 2007-01-05 07:02:10 UTC
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
Comment 27 Bernhard Reutner-Fischer 2007-01-06 19:36:25 UTC
(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.
Comment 28 paolo@gcc.gnu.org 2007-01-06 22:38:22 UTC
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

Comment 29 paolo@gcc.gnu.org 2007-01-06 22:38:51 UTC
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

Comment 30 Paolo Carlini 2007-01-06 22:46:02 UTC
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...