Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 195947 - sys-libs/glibc-2.6.1 doesn't compile w/ -D_FILE_OFFSET_BITS=64
Summary: sys-libs/glibc-2.6.1 doesn't compile w/ -D_FILE_OFFSET_BITS=64
Status: VERIFIED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-15 14:06 UTC by John (EBo) David
Modified: 2007-10-15 20:36 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
glibc-2.6.1/temp/environment (glibc_environment,189.32 KB, text/plain)
2007-10-15 14:08 UTC, John (EBo) David
Details
glibc-2.6.1/temp/build.log (glibc_build.log,56.12 KB, text/plain)
2007-10-15 14:59 UTC, John (EBo) David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John (EBo) David 2007-10-15 14:06:52 UTC
I have a consistent problem with conflicting types for __mmap while compiling glibc with _FILE_OFFSET_BITS=64 either set on 32 bit architectures which require explicit offset alignment, and 64 bit architectures which set the variable implicitly.

Background: 

Before upgrading several of our Beowulf cluster nodes from AMD-MP's to Intel-Core 2 Duo's I was running some modeling software which required _FILE_OFFSET_BITS=64 to be explicitly set.  There was some upgrade (long ago enough I do not remember the details) which first exercised the bug.  I removed the flag and everything compiled.  Soon after I had to replace several nodes, and the upgrade re-exercised the bug.

Observation:

When it first appeared I tracked the problem down to the mmap definitions in glibc-*/include/sys/mman.h and glibc-*/misc/sys/mman.h.  The salient difference being the __THROW at the end of the declaration in glibc-*/misc/sys/mman.h.  Before attempting to hack glibc source I wanted to post the bug and see if anyone has a workaround or fix.

Repeatability:

On my system always (Gentoo sync'ed daily).



Attached you will find the build.log and glibc-2.6.1/temp/environment (which appear to contain the "info" data -- I'll repost that if you need any additional information).

  EBo --
Comment 1 John (EBo) David 2007-10-15 14:08:53 UTC
Created attachment 133539 [details]
glibc-2.6.1/temp/environment

glibc-2.6.1/temp/environment
Comment 2 John (EBo) David 2007-10-15 14:59:39 UTC
Created attachment 133545 [details]
glibc-2.6.1/temp/build.log

the build log.  Clipped for size limitation and provide close to minimal error reproduction.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2007-10-15 18:25:53 UTC
Stop sticking stuff like this into your C[XX]FLAGS.
Comment 4 John (EBo) David 2007-10-15 20:36:47 UTC
While your reply came across as rude it did cause me to verify something.

I removed -D_FILE_OFFSET_BITS=64 from the CFLAGS line a year ago or more.

What I missed, however, was that I had overwritten CFLAGS at the end of the make.conf file when I was testing some experimental code and I missed cleaning it up.  So, yes!  I have stopped stick[ing] stuff like that in [my] CFLAGS.  Now why I tried it 3 years ago in the first place was the fact that the global climate models we were running required it to be set + *all* system libraries which the GCM used had to have it set too or we'd get weird numerical errors -- so I set it global (after spending weeks trying to figure out why the regression tests return non-trivial different results).

No longer needed, and now make.conf is being cleaned up.  Sorry for wasting your time.