This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See crosstool-NG for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

uClibc toolchain without large file support build fails


I'm having an issue with crosstool-ng-1.18.0 that seems the same as
the one described here on buildroot:

http://comments.gmane.org/gmane.comp.lib.uclibc.buildroot/50741

Essentially, if you attempt to build a uClibc-based toolchain without
large file support on a 32-bit machine/vm with recent gcc, the build
fails in

[ALL  ]    In file included from
/home/andrew/x-tools/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:28:0,
[ALL  ]                     from
/home/andrew/toolchainbuild/.build/src/gcc-linaro-4.7-2013.01/libgcc/../gcc/tsystem.h:88,
[ALL  ]                     from
/home/andrew/toolchainbuild/.build/src/gcc-linaro-4.7-2013.01/libgcc/crtstuff.c:62:
[ERROR]    /home/andrew/x-tools/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/include/features.h:219:5:
error: #error It appears you have defined _FILE_OFFSET_BITS=64.
Unfortunately, uClibc was built without large file support enabled.

It looks like even though the file is meant for the target, crtstuff.c
needs to pull in "auto-host.h", which pulls in the _FILE_OFFSET_BITS
and causes the uClibc headers to error out.

For now, I've simply '#undef _FILE_OFFSET_BITS' after including
"auto-host.h", which seems to work, although I'm not sure how safe it
is.

Any ideas what a proper fix might be?

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]