* [Buildroot] buildroot 2012.11 large file support @ 2012-12-10 12:35 Berns 2012-12-10 14:53 ` Willy Lambert 2012-12-11 9:30 ` Berns 0 siblings, 2 replies; 32+ messages in thread From: Berns @ 2012-12-10 12:35 UTC (permalink / raw) To: buildroot Hi i have tried to build at91sam9263ek_defconfig (without any modification) with the latest release 2012.11 on a 32bit Ubuntu12.04 machine. The build of the toolchain fails with : .../buildroot-2012.11/output/toolchain/uClibc_dev//usr/include/features.h:21 9:5: Fehler: #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, uClibc was built without large file support enabled. Large file support isn't select and i have also checked it with make uclibc-menuconfig for uclibc. The same problem happend with beaglebone_defconfig. After "make clean" and selecting "large file support" the build process works. This problem doesn't happend with release 2012.08. Has anybody a hint for me ? Thanks Rainer ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 12:35 [Buildroot] buildroot 2012.11 large file support Berns @ 2012-12-10 14:53 ` Willy Lambert 2012-12-10 19:20 ` Peter Korsgaard 2012-12-11 9:30 ` Berns 1 sibling, 1 reply; 32+ messages in thread From: Willy Lambert @ 2012-12-10 14:53 UTC (permalink / raw) To: buildroot 2012/12/10 Berns <Berns@beka-elektronik.de>: > Hi > > i have tried to build at91sam9263ek_defconfig (without any modification) > with the latest release 2012.11 on a 32bit Ubuntu12.04 machine. > The build of the toolchain fails with : > .../buildroot-2012.11/output/toolchain/uClibc_dev//usr/include/features.h:21 > 9:5: Fehler: #error It appears you have defined _FILE_OFFSET_BITS=64. > Unfortunately, uClibc was built without large file support enabled. > > Large file support isn't select and i have also checked it with make > uclibc-menuconfig for uclibc. > The same problem happend with beaglebone_defconfig. > > After "make clean" and selecting "large file support" the build process > works. > > This problem doesn't happend with release 2012.08. > > Has anybody a hint for me ? I have just had the same problem, is it possible that this is a regression of the 2012.11 version ? > > Thanks > > Rainer > > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 14:53 ` Willy Lambert @ 2012-12-10 19:20 ` Peter Korsgaard 2012-12-10 19:38 ` Willy Lambert 2012-12-12 10:21 ` Fabio Porcedda 0 siblings, 2 replies; 32+ messages in thread From: Peter Korsgaard @ 2012-12-10 19:20 UTC (permalink / raw) To: buildroot >>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: Hi, >> Large file support isn't select and i have also checked it with make >> uclibc-menuconfig for uclibc. >> The same problem happend with beaglebone_defconfig. >> >> After "make clean" and selecting "large file support" the build process >> works. >> >> This problem doesn't happend with release 2012.08. >> >> Has anybody a hint for me ? Willy> I have just had the same problem, is it possible that this is a Willy> regression of the 2012.11 version ? I don't think so. I just did a: make at91sam9263ek_defconfig && make Without any problems. What exactly did you do? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 19:20 ` Peter Korsgaard @ 2012-12-10 19:38 ` Willy Lambert 2012-12-10 20:38 ` Peter Korsgaard 2012-12-12 10:21 ` Fabio Porcedda 1 sibling, 1 reply; 32+ messages in thread From: Willy Lambert @ 2012-12-10 19:38 UTC (permalink / raw) To: buildroot 2012/12/10 Peter Korsgaard <jacmet@uclibc.org>: >>>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: > > Hi, > > >> Large file support isn't select and i have also checked it with make > >> uclibc-menuconfig for uclibc. > >> The same problem happend with beaglebone_defconfig. > >> > >> After "make clean" and selecting "large file support" the build process > >> works. > >> > >> This problem doesn't happend with release 2012.08. > >> > >> Has anybody a hint for me ? > > Willy> I have just had the same problem, is it possible that this is a > Willy> regression of the 2012.11 version ? > > I don't think so. I just did a: > > make at91sam9263ek_defconfig && make > > Without any problems. What exactly did you do? make. just make after having DL latest stable version few days ago from a tgz. Doing a make menuconfig don't change anything, and as far as I can remember, menuconfig was telling us about this problem (something depending on largefile). I know this has little sense, but before doing any configuration I want to begin from a stable build, and test step by step when doing configuration. I have an existing system that I want to replace by a custom linux, so it's basically "copy/pasting" config. But I don't believe doing all the config in one strike is realistic ^^. (and BTW, hi all, I'm new with buildroot). > > -- > Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 19:38 ` Willy Lambert @ 2012-12-10 20:38 ` Peter Korsgaard 2012-12-10 21:30 ` Willy Lambert 0 siblings, 1 reply; 32+ messages in thread From: Peter Korsgaard @ 2012-12-10 20:38 UTC (permalink / raw) To: buildroot >>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: Hi, >> I don't think so. I just did a: >> >> make at91sam9263ek_defconfig && make >> >> Without any problems. What exactly did you do? Willy> make. With what configuration? 'make' with a clean tree will just run menuconfig for you. Willy> just make after having DL latest stable version few days ago from a Willy> tgz. Doing a make menuconfig don't change anything, and as far as I Willy> can remember, menuconfig was telling us about this problem (something Willy> depending on largefile). Did you perhaps forget to run 'make clean' after changing something in your toolchain configuration? Willy> (and BTW, hi all, I'm new with buildroot). Welcome! -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 20:38 ` Peter Korsgaard @ 2012-12-10 21:30 ` Willy Lambert 2012-12-10 22:05 ` Peter Korsgaard 2012-12-11 15:09 ` Willy Lambert 0 siblings, 2 replies; 32+ messages in thread From: Willy Lambert @ 2012-12-10 21:30 UTC (permalink / raw) To: buildroot 2012/12/10 Peter Korsgaard <jacmet@uclibc.org>: >>>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: > > Hi, > > >> I don't think so. I just did a: > >> > >> make at91sam9263ek_defconfig && make > >> > >> Without any problems. What exactly did you do? > > Willy> make. > > With what configuration? 'make' with a clean tree will just run > menuconfig for you. > Yes, so I just quit it so it leaves the default config (which seems to have a problem with large file) > Willy> just make after having DL latest stable version few days ago from a > Willy> tgz. Doing a make menuconfig don't change anything, and as far as I > Willy> can remember, menuconfig was telling us about this problem (something > Willy> depending on largefile). > > Did you perhaps forget to run 'make clean' after changing something in > your toolchain configuration? I'm quite sure I did it (make clean + make distclean + rm ccache). But to be sure I'll retry from zero tomorrow. I'm not blocked I already have my root image (with large file enabled), I'm currently setting up qemu to test it, our remark is just that default config seems dummy. > > Willy> (and BTW, hi all, I'm new with buildroot). > > Welcome! > Thanks ! > -- > Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 21:30 ` Willy Lambert @ 2012-12-10 22:05 ` Peter Korsgaard 2012-12-11 2:13 ` Willy Lambert 2012-12-11 15:09 ` Willy Lambert 1 sibling, 1 reply; 32+ messages in thread From: Peter Korsgaard @ 2012-12-10 22:05 UTC (permalink / raw) To: buildroot >>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: Hi, Willy> Yes, so I just quit it so it leaves the default config (which Willy> seems to have a problem with large file) Ok, that also works here: yes '' | make oldconfig make Willy> I'm not blocked I already have my root image (with large file Willy> enabled), I'm currently setting up qemu to test it, our remark is just Willy> that default config seems dummy. Notice that we have a bunch of preconfigured qemu defconfigs (look in configs/) -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 22:05 ` Peter Korsgaard @ 2012-12-11 2:13 ` Willy Lambert 2012-12-11 7:04 ` Peter Korsgaard 0 siblings, 1 reply; 32+ messages in thread From: Willy Lambert @ 2012-12-11 2:13 UTC (permalink / raw) To: buildroot 2012/12/10 Peter Korsgaard <jacmet@uclibc.org>: >>>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: > > Hi, > > Willy> Yes, so I just quit it so it leaves the default config (which > Willy> seems to have a problem with large file) > > Ok, that also works here: > > yes '' | make oldconfig > make > > Willy> I'm not blocked I already have my root image (with large file > Willy> enabled), I'm currently setting up qemu to test it, our remark is > just > Willy> that default config seems dummy. > > Notice that we have a bunch of preconfigured qemu defconfigs (look in > configs/) > thanks for this tips I overlooked that. I'm on a x86 atom so there is little config to preset. > -- > Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 2:13 ` Willy Lambert @ 2012-12-11 7:04 ` Peter Korsgaard 2012-12-11 8:43 ` Willy Lambert 0 siblings, 1 reply; 32+ messages in thread From: Peter Korsgaard @ 2012-12-11 7:04 UTC (permalink / raw) To: buildroot >>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: Willy> Yes, so I just quit it so it leaves the default config (which Willy> seems to have a problem with large file) >> >> Ok, that also works here: >> >> yes '' | make oldconfig >> make Does that work for you? >> Notice that we have a bunch of preconfigured qemu defconfigs (look in >> configs/) >> Willy> thanks for this tips I overlooked that. I'm on a x86 atom so Willy> there is little config to preset. Is your build machine an atom? If so, beware that your build times are going to be quite long. Don't you have access to any faster machines? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 7:04 ` Peter Korsgaard @ 2012-12-11 8:43 ` Willy Lambert 2012-12-11 9:09 ` Thomas Petazzoni 0 siblings, 1 reply; 32+ messages in thread From: Willy Lambert @ 2012-12-11 8:43 UTC (permalink / raw) To: buildroot 2012/12/11 Peter Korsgaard <jacmet@uclibc.org>: >>>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: > > Willy> Yes, so I just quit it so it leaves the default config (which > Willy> seems to have a problem with large file) > >> > >> Ok, that also works here: > >> > >> yes '' | make oldconfig > >> make > > Does that work for you? > > >> Notice that we have a bunch of preconfigured qemu defconfigs (look in > >> configs/) > >> > > Willy> thanks for this tips I overlooked that. I'm on a x86 atom so > Willy> there is little config to preset. > > Is your build machine an atom? If so, beware that your build times are > going to be quite long. Don't you have access to any faster machines? > Sorry, I was not clear. My *target* is an atom N450 on a PCM-3362 Advantech board : http://www.advantech.com/products/PCM-3362/mod_2B69DA4C-D506-4AEA-8CC3-F6E58E3CBC87.aspx If by chance anyone here has worked on this... My build machine is a quad i5, a bit overclocked, the compilation time is reasonable. But for time being I'm just trying to compile a "default" buildroot and run in into qemu. (btw I have difficulties to put my RFS, in tgz format (cause it's the default) into a .img file, is there any Buildroot hints for this, or should I switch to other "RFS image output format") > -- > Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 8:43 ` Willy Lambert @ 2012-12-11 9:09 ` Thomas Petazzoni 2012-12-12 1:04 ` Willy Lambert 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-11 9:09 UTC (permalink / raw) To: buildroot Dear Willy Lambert, On Tue, 11 Dec 2012 09:43:48 +0100, Willy Lambert wrote: > But for time being I'm just trying to compile a "default" buildroot > and run in into qemu. > (btw I have difficulties to put my RFS, in tgz format (cause it's the > default) into a .img file, is there any Buildroot hints for this, or > should I switch to other "RFS image output format") Please read board/qemu/x86_64/readme.txt or board/qemu/x86/readme.txt and use the corresponding qemu_x86_64_defconfig and qemu_x86_defconfig default configuration as starting points. Those configuration are known working for Qemu, and the readme.txt file explain how to start them in Qemu. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 9:09 ` Thomas Petazzoni @ 2012-12-12 1:04 ` Willy Lambert 0 siblings, 0 replies; 32+ messages in thread From: Willy Lambert @ 2012-12-12 1:04 UTC (permalink / raw) To: buildroot 2012/12/11 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Willy Lambert, > > On Tue, 11 Dec 2012 09:43:48 +0100, Willy Lambert wrote: > >> But for time being I'm just trying to compile a "default" buildroot >> and run in into qemu. >> (btw I have difficulties to put my RFS, in tgz format (cause it's the >> default) into a .img file, is there any Buildroot hints for this, or >> should I switch to other "RFS image output format") > > Please read board/qemu/x86_64/readme.txt or board/qemu/x86/readme.txt > and use the corresponding qemu_x86_64_defconfig and qemu_x86_defconfig > default configuration as starting points. > > Those configuration are known working for Qemu, and the readme.txt file > explain how to start them in Qemu. > Thanks a lot ! The buildroot doc is in general quite good, but after you have created your images you are alone in the dark :D. This kind of information about running a default config in qemu or hints on how to install your rootfs on your target would be welcome. > Best regards, > > Thomas > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 21:30 ` Willy Lambert 2012-12-10 22:05 ` Peter Korsgaard @ 2012-12-11 15:09 ` Willy Lambert 2012-12-11 16:10 ` Thomas Petazzoni 1 sibling, 1 reply; 32+ messages in thread From: Willy Lambert @ 2012-12-11 15:09 UTC (permalink / raw) To: buildroot 2012/12/10 Willy Lambert <lambert.willy@gmail.com>: > 2012/12/10 Peter Korsgaard <jacmet@uclibc.org>: >>>>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: >> >> Hi, >> >> >> I don't think so. I just did a: >> >> >> >> make at91sam9263ek_defconfig && make >> >> >> >> Without any problems. What exactly did you do? >> >> Willy> make. >> >> With what configuration? 'make' with a clean tree will just run >> menuconfig for you. >> > > Yes, so I just quit it so it leaves the default config (which seems to > have a problem with large file) > >> Willy> just make after having DL latest stable version few days ago from a >> Willy> tgz. Doing a make menuconfig don't change anything, and as far as I >> Willy> can remember, menuconfig was telling us about this problem (something >> Willy> depending on largefile). >> >> Did you perhaps forget to run 'make clean' after changing something in >> your toolchain configuration? > > I'm quite sure I did it (make clean + make distclean + rm ccache). But > to be sure I'll retry from zero tomorrow. I did this again from another machine (silvie at silvie-VirtualBox:~/buildroot-2012.11$ uname -a Linux silvie-VirtualBox 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux) In short : wget buildroot, tar -xf, make, a menuconfig pops, I exit and save config, make, wait a bit ... and it fails with the above error about large file system. So I'm sure now that the default config has a problem with largefiles. I'm sorry I'm too new to investigate further. Should I open a bug ticket ? I did not try other versions of gcc as proposed by Berns. But my gcc version is : ard at ard-host(10.0):/opt/buildroot/output/host/usr$ ./x86_64-buildroot-linux-uclibc/bin/gcc --version gcc (Buildroot 2012.11-svn2-dirty) 4.6.3 I wonder about the "svn2-dirty" tag. > > I'm not blocked I already have my root image (with large file > enabled), I'm currently setting up qemu to test it, our remark is just > that default config seems dummy. > >> >> Willy> (and BTW, hi all, I'm new with buildroot). >> >> Welcome! >> > > Thanks ! > >> -- >> Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 15:09 ` Willy Lambert @ 2012-12-11 16:10 ` Thomas Petazzoni 2012-12-12 0:35 ` Arnout Vandecappelle 2012-12-12 9:20 ` Willy Lambert 0 siblings, 2 replies; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-11 16:10 UTC (permalink / raw) To: buildroot Dear Willy Lambert, On Tue, 11 Dec 2012 16:09:46 +0100, Willy Lambert wrote: > I did this again from another machine > (silvie at silvie-VirtualBox:~/buildroot-2012.11$ uname -a > Linux silvie-VirtualBox 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 > 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux) > > In short : > wget buildroot, tar -xf, make, a menuconfig pops, I exit and save > config, make, wait a bit ... and it fails with the above error about > large file system. > > So I'm sure now that the default config has a problem with largefiles. > I'm sorry I'm too new to investigate further. Should I open a bug > ticket ? > > I did not try other versions of gcc as proposed by Berns. But my gcc > version is : > ard at ard-host(10.0):/opt/buildroot/output/host/usr$ > ./x86_64-buildroot-linux-uclibc/bin/gcc --version > gcc (Buildroot 2012.11-svn2-dirty) 4.6.3 > I wonder about the "svn2-dirty" tag. Can you do: make clean rm .config make menuconfig / exit / save env > buildroot-fails.env make 2>&1 | tee buildroot-fails.log cp output/toolchain/uClibc-0.9.33.2/.config buildroot-fails.uClibc.config And then put somewhere online (do *NOT* send them by e-mail on the list, it will be too large) the buildroot-fails.env, buildroot-fails.log and buildroot-fails.uClibc.config files. I have just built the default Buildroot configuration on two Ubuntu 12.04 machines, with zero problem. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 16:10 ` Thomas Petazzoni @ 2012-12-12 0:35 ` Arnout Vandecappelle 2012-12-12 10:16 ` Thomas Petazzoni 2012-12-12 9:20 ` Willy Lambert 1 sibling, 1 reply; 32+ messages in thread From: Arnout Vandecappelle @ 2012-12-12 0:35 UTC (permalink / raw) To: buildroot Note that Maxime already reported this problem three months ago: http://lists.busybox.net/pipermail/buildroot/2012-September/059193.html On 11/12/12 17:10, Thomas Petazzoni wrote: > Dear Willy Lambert, > > On Tue, 11 Dec 2012 16:09:46 +0100, Willy Lambert wrote: > >> I did this again from another machine >> (silvie at silvie-VirtualBox:~/buildroot-2012.11$ uname -a >> Linux silvie-VirtualBox 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 >> 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux) >> >> In short : >> wget buildroot, tar -xf, make, a menuconfig pops, I exit and save >> config, make, wait a bit ... and it fails with the above error about >> large file system. >> >> So I'm sure now that the default config has a problem with largefiles. >> I'm sorry I'm too new to investigate further. Should I open a bug >> ticket ? >> >> I did not try other versions of gcc as proposed by Berns. But my gcc >> version is : >> ard at ard-host(10.0):/opt/buildroot/output/host/usr$ >> ./x86_64-buildroot-linux-uclibc/bin/gcc --version >> gcc (Buildroot 2012.11-svn2-dirty) 4.6.3 >> I wonder about the "svn2-dirty" tag. > > Can you do: > > make clean > rm .config > make menuconfig / exit / save > env> buildroot-fails.env > make 2>&1 | tee buildroot-fails.log > cp output/toolchain/uClibc-0.9.33.2/.config buildroot-fails.uClibc.config > > And then put somewhere online (do *NOT* send them by e-mail on the > list, it will be too large) the buildroot-fails.env, > buildroot-fails.log and buildroot-fails.uClibc.config files. Except for the environment, I don't expect we'll see much interesting in these... Probably more useful are all the config.log under output/toolchain/gcc* (especially output/toolchain/gcc-*-final/*/libgcc/config.log and config.h) I vaguely remember having looked at this or a similar problem, and coming to the conclusion that there are some files that gcc builds a few files in libgcc with the host's config.h instead of the target's. And if I remember correctly, this was still the same in gcc 4.7 and upstream git. Rainer, you reported that it works with gcc 4.5; can you check if it is still broken in gcc 4.7? It would be interesting to diff the config.log results between 4.5 and 4.6. So maybe, put a tarball of the whole output dir with a 4.5 and a 4.6 build in a pastebin... > I have just built the default Buildroot configuration on two Ubuntu > 12.04 machines, with zero problem. Did you try it on an i386 machine? Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 0:35 ` Arnout Vandecappelle @ 2012-12-12 10:16 ` Thomas Petazzoni 2012-12-12 11:01 ` Thomas Petazzoni 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-12 10:16 UTC (permalink / raw) To: buildroot Dear Arnout Vandecappelle, On Wed, 12 Dec 2012 01:35:27 +0100, Arnout Vandecappelle wrote: > Except for the environment, I don't expect we'll see much interesting > in these... > > Probably more useful are all the config.log under output/toolchain/gcc* > (especially output/toolchain/gcc-*-final/*/libgcc/config.log and config.h) I have now reproduced the problem on a fresh installation of Ubuntu 12.04 32 bits. Nothing fancy in my system: it is an Ubuntu server, with just the base packages + the minimal dependencies for Buildroot to run. I have posted at http://free-electrons.com/~thomas/pub/largefile-build-problem.tar.gz a tarball that contains: logfile <-- this is the full build log output/build/host-autoconf-2.68/config.log output/build/host-gmp-5.0.5/config.log output/build/host-mpc-1.0.1/config.log output/build/host-m4-1.4.16/config.log output/build/host-mpfr-3.1.1/config.log output/build/host-libtool-2.2.10/config.log output/build/host-binutils-2.21.1/libiberty/config.log output/build/host-binutils-2.21.1/binutils/config.log output/build/host-binutils-2.21.1/bfd/config.log output/build/host-binutils-2.21.1/config.log output/build/host-binutils-2.21.1/gprof/config.log output/build/host-binutils-2.21.1/intl/config.log output/build/host-binutils-2.21.1/gas/config.log output/build/host-binutils-2.21.1/etc/config.log output/build/host-binutils-2.21.1/ld/config.log output/build/host-binutils-2.21.1/opcodes/config.log output/build/host-automake-1.11.6/config.log output/toolchain/gcc-4.6.3-initial/libiberty/config.log output/toolchain/gcc-4.6.3-initial/libdecnumber/config.log output/toolchain/gcc-4.6.3-initial/lto-plugin/config.log output/toolchain/gcc-4.6.3-initial/libcpp/config.log output/toolchain/gcc-4.6.3-initial/zlib/config.log output/toolchain/gcc-4.6.3-initial/config.log output/toolchain/gcc-4.6.3-initial/build-i686-pc-linux-gnu/libiberty/config.log output/toolchain/gcc-4.6.3-initial/build-i686-pc-linux-gnu/fixincludes/config.log output/toolchain/gcc-4.6.3-initial/fixincludes/config.log output/toolchain/gcc-4.6.3-initial/intl/config.log output/toolchain/gcc-4.6.3-initial/gcc/config.log output/toolchain/gcc-4.6.3-intermediate/libiberty/config.log output/toolchain/gcc-4.6.3-intermediate/libdecnumber/config.log output/toolchain/gcc-4.6.3-intermediate/lto-plugin/config.log output/toolchain/gcc-4.6.3-intermediate/libcpp/config.log output/toolchain/gcc-4.6.3-intermediate/zlib/config.log output/toolchain/gcc-4.6.3-intermediate/config.log output/toolchain/gcc-4.6.3-intermediate/build-i686-pc-linux-gnu/libiberty/config.log output/toolchain/gcc-4.6.3-intermediate/build-i686-pc-linux-gnu/fixincludes/config.log output/toolchain/gcc-4.6.3-intermediate/fixincludes/config.log output/toolchain/gcc-4.6.3-intermediate/i586-buildroot-linux-uclibc/libgcc/config.log output/toolchain/gcc-4.6.3-intermediate/intl/config.log output/toolchain/gcc-4.6.3-intermediate/gcc/config.log output/toolchain/uClibc-0.9.33.2/.config I haven't looked into them for now. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 10:16 ` Thomas Petazzoni @ 2012-12-12 11:01 ` Thomas Petazzoni 2012-12-12 11:03 ` Thomas Petazzoni 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-12 11:01 UTC (permalink / raw) To: buildroot On Wed, 12 Dec 2012 11:16:28 +0100, Thomas Petazzoni wrote: > I haven't looked into them for now. Ok, a quick investigation shows that crtstuff.c includes auto-host.h, which contains _FILE_OFFSET_BITS. crtstuff.c is built for the target, and therefore should normally not include auto-host.h, as noted by the following comment: == /* FIXME: Including auto-host is incorrect, but until we have identified the set of defines that need to go into auto-target.h, this will have to do. */ #include "auto-host.h" == -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 11:01 ` Thomas Petazzoni @ 2012-12-12 11:03 ` Thomas Petazzoni 2012-12-12 12:47 ` Thomas Petazzoni 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-12 11:03 UTC (permalink / raw) To: buildroot Dear Thomas Petazzoni, On Wed, 12 Dec 2012 12:01:59 +0100, Thomas Petazzoni wrote: > > On Wed, 12 Dec 2012 11:16:28 +0100, Thomas Petazzoni wrote: > > > I haven't looked into them for now. > > Ok, a quick investigation shows that crtstuff.c includes auto-host.h, > which contains _FILE_OFFSET_BITS. crtstuff.c is built for the target, > and therefore should normally not include auto-host.h, as noted by the > following comment: > > == > /* FIXME: Including auto-host is incorrect, but until we have > identified the set of defines that need to go into auto-target.h, > this will have to do. */ > #include "auto-host.h" > == (sorry for not finishing the e-mail) And this is causing problems for cross-compilation. For example: http://www.archivum.info/gcc-patches at gcc.gnu.org/2005-11/00293/Patch-to-crtstuff.c-to-undefine-some-macros-after-auto-host.h.html. According to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21481 it is quite clear that crtstuff.c should not include auto-host.h, but apparently, it is not that simple. Thing that remains not understood is what change between 4.5 and 4.6 broke this. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 11:03 ` Thomas Petazzoni @ 2012-12-12 12:47 ` Thomas Petazzoni 2012-12-12 16:47 ` Peter Korsgaard 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-12 12:47 UTC (permalink / raw) To: buildroot Dear Thomas Petazzoni, On Wed, 12 Dec 2012 12:03:41 +0100, Thomas Petazzoni wrote: > Thing that remains not understood is what change between 4.5 and 4.6 > broke this. Apparently, what changed is that the gcc/configure.ac has gained a AC_SYS_LARGEFILE check: $ grep LARGEFILE toolchain/gcc-4.6.3/gcc/configure.ac AC_SYS_LARGEFILE $ grep LARGEFILE toolchain/gcc-4.5.4/gcc/configure.ac $ On gcc >= 4.6, this means that a #define _FILE_OFFSET_BITS 64 is added to auto-host.h, which breaks the build of crtstuff.c for the target as uClibc headers warn that _FILE_OFFSET_BITS is set to 64 even though largefile support is not enabled. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 12:47 ` Thomas Petazzoni @ 2012-12-12 16:47 ` Peter Korsgaard 2012-12-12 17:32 ` Thomas Petazzoni 0 siblings, 1 reply; 32+ messages in thread From: Peter Korsgaard @ 2012-12-12 16:47 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Thomas> Dear Thomas Petazzoni, Thomas> On Wed, 12 Dec 2012 12:03:41 +0100, Thomas Petazzoni wrote: >> Thing that remains not understood is what change between 4.5 and 4.6 >> broke this. Thomas> Apparently, what changed is that the gcc/configure.ac has gained a Thomas> AC_SYS_LARGEFILE check: Thomas> $ grep LARGEFILE toolchain/gcc-4.6.3/gcc/configure.ac Thomas> AC_SYS_LARGEFILE Thomas> $ grep LARGEFILE toolchain/gcc-4.5.4/gcc/configure.ac Thomas> $ Thomas> On gcc >= 4.6, this means that a #define _FILE_OFFSET_BITS 64 is added Thomas> to auto-host.h, which breaks the build of crtstuff.c for the target as Thomas> uClibc headers warn that _FILE_OFFSET_BITS is set to 64 even though Thomas> largefile support is not enabled. Hmm, we already pass --disable-largefile to the gcc configure script, except for the first 2 passes. Does it work if we add $(DISABLE_LARGEFILE) to the gcc1 / gcc2 configure steps? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 16:47 ` Peter Korsgaard @ 2012-12-12 17:32 ` Thomas Petazzoni 2012-12-12 20:15 ` Peter Korsgaard 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-12 17:32 UTC (permalink / raw) To: buildroot Dear Peter Korsgaard, On Wed, 12 Dec 2012 17:47:29 +0100, Peter Korsgaard wrote: > Hmm, we already pass --disable-largefile to the gcc configure script, > except for the first 2 passes. Does it work if we add > $(DISABLE_LARGEFILE) to the gcc1 / gcc2 configure steps? !largefile build is OK if we pass $(DISABLE_LARGEFILE) to gcc1 and gcc2 configure steps, so it solves the build problem. I haven't done more testing though (testing the generated code, building with largefile enabled, etc.). That said, doesn't --disable-largefile disables largefile support at the level of gcc itself, rather than taking into account the fact that largefile support is not available on the target? Of course, it has the consequence that _FILE_OFFSET_BITS is no longer defined to 64 in auto-conf.h, which works around the problem. But gcc (the host binary) should be capable of being built with largefile support on a 32 bits host, even if the 32 bits target has no largefile support. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 17:32 ` Thomas Petazzoni @ 2012-12-12 20:15 ` Peter Korsgaard 2012-12-12 22:21 ` Thomas Petazzoni 0 siblings, 1 reply; 32+ messages in thread From: Peter Korsgaard @ 2012-12-12 20:15 UTC (permalink / raw) To: buildroot >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, >> Hmm, we already pass --disable-largefile to the gcc configure script, >> except for the first 2 passes. Does it work if we add >> $(DISABLE_LARGEFILE) to the gcc1 / gcc2 configure steps? Thomas> !largefile build is OK if we pass $(DISABLE_LARGEFILE) to gcc1 and gcc2 Thomas> configure steps, so it solves the build problem. I haven't done more Thomas> testing though (testing the generated code, building with largefile Thomas> enabled, etc.). Cool, great - I'll commit that then. Thomas> That said, doesn't --disable-largefile disables largefile support at Thomas> the level of gcc itself, rather than taking into account the fact that Thomas> largefile support is not available on the target? Of course, it has the Thomas> consequence that _FILE_OFFSET_BITS is no longer defined to 64 in Thomas> auto-conf.h, which works around the problem. But gcc (the host Thomas> binary) should be capable of being built with largefile support on a 32 Thomas> bits host, even if the 32 bits target has no largefile support. So for the cross compiler to be able to access large files? Is that really important? I doubt people are using buildroot with 2G+ source/object/library files? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 20:15 ` Peter Korsgaard @ 2012-12-12 22:21 ` Thomas Petazzoni 2012-12-12 23:47 ` Arnout Vandecappelle 0 siblings, 1 reply; 32+ messages in thread From: Thomas Petazzoni @ 2012-12-12 22:21 UTC (permalink / raw) To: buildroot Dear Peter Korsgaard, On Wed, 12 Dec 2012 21:15:44 +0100, Peter Korsgaard wrote: > Thomas> !largefile build is OK if we pass $(DISABLE_LARGEFILE) to > Thomas> gcc1 and gcc2 configure steps, so it solves the build > Thomas> problem. I haven't done more testing though (testing the > Thomas> generated code, building with largefile enabled, etc.). > > Cool, great - I'll commit that then. > > Thomas> That said, doesn't --disable-largefile disables largefile > Thomas> support at the level of gcc itself, rather than taking into > Thomas> account the fact that largefile support is not available on > Thomas> the target? Of course, it has the consequence that > Thomas> _FILE_OFFSET_BITS is no longer defined to 64 in auto-conf.h, > Thomas> which works around the problem. But gcc (the host binary) > Thomas> should be capable of being built with largefile support on a > Thomas> 32 bits host, even if the 32 bits target has no largefile > Thomas> support. > > So for the cross compiler to be able to access large files? Is that > really important? I doubt people are using buildroot with 2G+ > source/object/library files? It's not that we care too much about this (even though some crazy library like Qt with debugging symbols reaches a very fat size, several hundreds of MBs in size), but the fact that it is an ugly workaround to use the side-effect of disabling largefile on gcc to make it play nice with a target system that has largefile disabled. Right now, when largefile is disabled for the target, it is disabled for the cross gcc, when largefile is enabled for the target, it is enabled for the cross gcc. Doesn't make much sense. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 22:21 ` Thomas Petazzoni @ 2012-12-12 23:47 ` Arnout Vandecappelle 2012-12-13 10:45 ` Victor Hiairrassary 0 siblings, 1 reply; 32+ messages in thread From: Arnout Vandecappelle @ 2012-12-12 23:47 UTC (permalink / raw) To: buildroot On 12/12/12 23:21, Thomas Petazzoni wrote: > Dear Peter Korsgaard, > > On Wed, 12 Dec 2012 21:15:44 +0100, Peter Korsgaard wrote: > >> Thomas> !largefile build is OK if we pass $(DISABLE_LARGEFILE) to >> Thomas> gcc1 and gcc2 configure steps, so it solves the build >> Thomas> problem. I haven't done more testing though (testing the >> Thomas> generated code, building with largefile enabled, etc.). >> >> Cool, great - I'll commit that then. >> >> Thomas> That said, doesn't --disable-largefile disables largefile >> Thomas> support at the level of gcc itself, rather than taking into >> Thomas> account the fact that largefile support is not available on >> Thomas> the target? Of course, it has the consequence that >> Thomas> _FILE_OFFSET_BITS is no longer defined to 64 in auto-conf.h, >> Thomas> which works around the problem. But gcc (the host binary) >> Thomas> should be capable of being built with largefile support on a >> Thomas> 32 bits host, even if the 32 bits target has no largefile >> Thomas> support. >> >> So for the cross compiler to be able to access large files? Is that >> really important? I doubt people are using buildroot with 2G+ >> source/object/library files? > > It's not that we care too much about this (even though some crazy > library like Qt with debugging symbols reaches a very fat size, several > hundreds of MBs in size), but the fact that it is an ugly workaround to > use the side-effect of disabling largefile on gcc to make it play nice > with a target system that has largefile disabled. > > Right now, when largefile is disabled for the target, it is disabled > for the cross gcc, when largefile is enabled for the target, it is > enabled for the cross gcc. Doesn't make much sense. Indeed, it would make much more sense to disable largefile unconditionally while building any gcc stage (uClibc won't complain if _FILE_OFFSET_BITS is not set). At least, I guess --disable-largefile only says something about the gcc executable, not about the crtstuff and other target support... And it also deserves a BIG FAT comment explaining why this is needed. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-12 23:47 ` Arnout Vandecappelle @ 2012-12-13 10:45 ` Victor Hiairrassary 2012-12-13 10:55 ` Peter Korsgaard 2012-12-13 11:06 ` Arnout Vandecappelle 0 siblings, 2 replies; 32+ messages in thread From: Victor Hiairrassary @ 2012-12-13 10:45 UTC (permalink / raw) To: buildroot So maybe boost package should no more depend on BR2_LARGEFILE? Le 13 d?c. 2012 ? 00:47, Arnout Vandecappelle <arnout@mind.be> a ?crit : > On 12/12/12 23:21, Thomas Petazzoni wrote: >> Dear Peter Korsgaard, >> >> On Wed, 12 Dec 2012 21:15:44 +0100, Peter Korsgaard wrote: >> >>> Thomas> !largefile build is OK if we pass $(DISABLE_LARGEFILE) to >>> Thomas> gcc1 and gcc2 configure steps, so it solves the build >>> Thomas> problem. I haven't done more testing though (testing the >>> Thomas> generated code, building with largefile enabled, etc.). >>> >>> Cool, great - I'll commit that then. >>> >>> Thomas> That said, doesn't --disable-largefile disables largefile >>> Thomas> support at the level of gcc itself, rather than taking into >>> Thomas> account the fact that largefile support is not available on >>> Thomas> the target? Of course, it has the consequence that >>> Thomas> _FILE_OFFSET_BITS is no longer defined to 64 in auto-conf.h, >>> Thomas> which works around the problem. But gcc (the host binary) >>> Thomas> should be capable of being built with largefile support on a >>> Thomas> 32 bits host, even if the 32 bits target has no largefile >>> Thomas> support. >>> >>> So for the cross compiler to be able to access large files? Is that >>> really important? I doubt people are using buildroot with 2G+ >>> source/object/library files? >> >> It's not that we care too much about this (even though some crazy >> library like Qt with debugging symbols reaches a very fat size, several >> hundreds of MBs in size), but the fact that it is an ugly workaround to >> use the side-effect of disabling largefile on gcc to make it play nice >> with a target system that has largefile disabled. >> >> Right now, when largefile is disabled for the target, it is disabled >> for the cross gcc, when largefile is enabled for the target, it is >> enabled for the cross gcc. Doesn't make much sense. > > Indeed, it would make much more sense to disable largefile unconditionally > while building any gcc stage (uClibc won't complain if _FILE_OFFSET_BITS is > not set). At least, I guess --disable-largefile only says something about > the gcc executable, not about the crtstuff and other target support... > > And it also deserves a BIG FAT comment explaining why this is needed. > > Regards, > Arnout > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286540 > Essensium/Mind http://www.mind.be > G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle > GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-13 10:45 ` Victor Hiairrassary @ 2012-12-13 10:55 ` Peter Korsgaard 2012-12-13 11:06 ` Arnout Vandecappelle 1 sibling, 0 replies; 32+ messages in thread From: Peter Korsgaard @ 2012-12-13 10:55 UTC (permalink / raw) To: buildroot >>>>> "Victor" == Victor Hiairrassary <victor.hiairrassary.ml@gmail.com> writes: Victor> So maybe boost package should no more depend on BR2_LARGEFILE? Ehh, what does that have to do with the compilation issue on Ubuntu 12.04 when you don't enable largefile? Presumably boost is marked as needing largefile because it does? -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-13 10:45 ` Victor Hiairrassary 2012-12-13 10:55 ` Peter Korsgaard @ 2012-12-13 11:06 ` Arnout Vandecappelle 2012-12-13 11:28 ` Victor Hiairrassary 1 sibling, 1 reply; 32+ messages in thread From: Arnout Vandecappelle @ 2012-12-13 11:06 UTC (permalink / raw) To: buildroot On 13/12/12 11:45, Victor Hiairrassary wrote: > So maybe boost package should no more depend on BR2_LARGEFILE? That has no relation at all with gcc... _Maybe_ the new boost version has lost its dependency on largefile, but I doubt it. I just tried it and it fails with a very cryptic error message. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-13 11:06 ` Arnout Vandecappelle @ 2012-12-13 11:28 ` Victor Hiairrassary 0 siblings, 0 replies; 32+ messages in thread From: Victor Hiairrassary @ 2012-12-13 11:28 UTC (permalink / raw) To: buildroot Previous boost package does not depend on BR2_LARGEFILE! I have add it else boost build fails. Le 13 d?c. 2012 ? 12:06, Arnout Vandecappelle <arnout@mind.be> a ?crit : > On 13/12/12 11:45, Victor Hiairrassary wrote: >> So maybe boost package should no more depend on BR2_LARGEFILE? > > That has no relation at all with gcc... > > _Maybe_ the new boost version has lost its dependency on largefile, but I > doubt it. I just tried it and it fails with a very cryptic error message. > > Regards, > Arnout > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286540 > Essensium/Mind http://www.mind.be > G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle > GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 16:10 ` Thomas Petazzoni 2012-12-12 0:35 ` Arnout Vandecappelle @ 2012-12-12 9:20 ` Willy Lambert 1 sibling, 0 replies; 32+ messages in thread From: Willy Lambert @ 2012-12-12 9:20 UTC (permalink / raw) To: buildroot 2012/12/11 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Willy Lambert, > > On Tue, 11 Dec 2012 16:09:46 +0100, Willy Lambert wrote: > >> I did this again from another machine >> (silvie at silvie-VirtualBox:~/buildroot-2012.11$ uname -a >> Linux silvie-VirtualBox 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 >> 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux) >> >> In short : >> wget buildroot, tar -xf, make, a menuconfig pops, I exit and save >> config, make, wait a bit ... and it fails with the above error about >> large file system. >> >> So I'm sure now that the default config has a problem with largefiles. >> I'm sorry I'm too new to investigate further. Should I open a bug >> ticket ? >> >> I did not try other versions of gcc as proposed by Berns. But my gcc >> version is : >> ard at ard-host(10.0):/opt/buildroot/output/host/usr$ >> ./x86_64-buildroot-linux-uclibc/bin/gcc --version >> gcc (Buildroot 2012.11-svn2-dirty) 4.6.3 >> I wonder about the "svn2-dirty" tag. > > Can you do: > > make clean > rm .config > make menuconfig / exit / save > env > buildroot-fails.env > make 2>&1 | tee buildroot-fails.log > cp output/toolchain/uClibc-0.9.33.2/.config buildroot-fails.uClibc.config > all my precedent try were on a virtual machines i386. One is latest Ubuntu, the other is a not-updated Dedian Squeeze from early 2011. Logs will come in private mail, because I don't know how to share them easily. Here is the other command results (that you probably don't need) : silvie at silvie-VirtualBox:~/buildroot-2012.11$ make clean rm -rf /home/silvie/buildroot-2012.11/output/host/usr/i586-buildroot-linux-uclibc/sysroot /home/silvie/buildroot-2012.11/output/target /home/silvie/buildroot-2012.11/output/images /home/silvie/buildroot-2012.11/output/host \ /home/silvie/buildroot-2012.11/output/stamps /home/silvie/buildroot-2012.11/output/build /home/silvie/buildroot-2012.11/output/toolchain /home/silvie/buildroot-2012.11/output/staging \ /home/silvie/buildroot-2012.11/output/legal-info silvie at silvie-VirtualBox:~/buildroot-2012.11$ rm .config silvie at silvie-VirtualBox:~/buildroot-2012.11$ make menuconfig mkdir -p /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" obj=/home/silvie/buildroot-2012.11/output/build/buildroot-config -C support/kconfig -f Makefile.br mconf make[1]: entrant dans le r?pertoire ? /home/silvie/buildroot-2012.11/support/kconfig ? /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -MM *.c > /home/silvie/buildroot-2012.11/output/build/buildroot-config/.depend 2>/dev/null || : make[1]: quittant le r?pertoire ? /home/silvie/buildroot-2012.11/support/kconfig ? make[1]: entrant dans le r?pertoire ? /home/silvie/buildroot-2012.11/support/kconfig ? /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c conf.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/conf.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c lxdialog/checklist.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/checklist.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c lxdialog/inputbox.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/inputbox.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c lxdialog/menubox.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/menubox.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c lxdialog/textbox.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/textbox.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c lxdialog/util.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/util.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c lxdialog/yesno.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/yesno.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -c mconf.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/mconf.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config -I. -c /home/silvie/buildroot-2012.11/output/build/buildroot-config/zconf.tab.c -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/zconf.tab.o /usr/bin/gcc -DCURSES_LOC="<ncurses.h>" -DLOCALE -I/home/silvie/buildroot-2012.11/output/build/buildroot-config /home/silvie/buildroot-2012.11/output/build/buildroot-config/mconf.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/zconf.tab.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/checklist.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/util.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/inputbox.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/textbox.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/yesno.o /home/silvie/buildroot-2012.11/output/build/buildroot-config/lxdialog/menubox.o -lncurses -o /home/silvie/buildroot-2012.11/output/build/buildroot-config/mconf rm /home/silvie/buildroot-2012.11/output/build/buildroot-config/zconf.tab.c make[1]: quittant le r?pertoire ? /home/silvie/buildroot-2012.11/support/kconfig ? # # configuration written to /home/silvie/buildroot-2012.11/.config # *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. silvie at silvie-VirtualBox:~/buildroot-2012.11$ > And then put somewhere online (do *NOT* send them by e-mail on the > list, it will be too large) the buildroot-fails.env, > buildroot-fails.log and buildroot-fails.uClibc.config files. > even compressed ? It is just 200ko. > I have just built the default Buildroot configuration on two Ubuntu > 12.04 machines, with zero problem. > > Thanks, > > Thomas > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 19:20 ` Peter Korsgaard 2012-12-10 19:38 ` Willy Lambert @ 2012-12-12 10:21 ` Fabio Porcedda 1 sibling, 0 replies; 32+ messages in thread From: Fabio Porcedda @ 2012-12-12 10:21 UTC (permalink / raw) To: buildroot On Mon, Dec 10, 2012 at 8:20 PM, Peter Korsgaard <jacmet@uclibc.org> wrote: >>>>>> "Willy" == Willy Lambert <lambert.willy@gmail.com> writes: > > Hi, > > >> Large file support isn't select and i have also checked it with make > >> uclibc-menuconfig for uclibc. > >> The same problem happend with beaglebone_defconfig. > >> > >> After "make clean" and selecting "large file support" the build process > >> works. > >> > >> This problem doesn't happend with release 2012.08. > >> > >> Has anybody a hint for me ? > > Willy> I have just had the same problem, is it possible that this is a > Willy> regression of the 2012.11 version ? > > I don't think so. I just did a: > > make at91sam9263ek_defconfig && make > > Without any problems. What exactly did you do? I've the same problem, I'm using Ubuntu 12.10 32bit. This configurations doesn't work: A) make at91sam9263ek_defconfig && make https://dl.dropbox.com/u/14668671/log-at91sam9263ek.txt.bz2 B) defconfig: BR2_arm=y BR2_GCC_VERSION_4_7_X=y https://dl.dropbox.com/u/14668671/log-gcc4.7.txt.bz2 C) defconfig: BR2_arm=y https://dl.dropbox.com/u/14668671/log.txt.bz2 This configuration build fine: BR2_arm=y BR2_GCC_VERSION_4_5_X=y https://dl.dropbox.com/u/14668671/log-gcc4.5.txt.bz2 Best regards -- Fabio Porcedda ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-10 12:35 [Buildroot] buildroot 2012.11 large file support Berns 2012-12-10 14:53 ` Willy Lambert @ 2012-12-11 9:30 ` Berns 2012-12-12 6:05 ` Peter Korsgaard 1 sibling, 1 reply; 32+ messages in thread From: Berns @ 2012-12-11 9:30 UTC (permalink / raw) To: buildroot I changed from gcc 4.6.X to gcc 4.5.X and now it works. Maybe it's an isue with ubuntu 12.04 and gcc 4.6.X. -----Original Message----- From: buildroot-bounces@busybox.net [mailto:buildroot-bounces at busybox.net]On Behalf Of Berns Sent: Monday, December 10, 2012 1:36 PM To: buildroot at busybox.net Subject: [Buildroot] buildroot 2012.11 large file support Hi i have tried to build at91sam9263ek_defconfig (without any modification) with the latest release 2012.11 on a 32bit Ubuntu12.04 machine. The build of the toolchain fails with : .../buildroot-2012.11/output/toolchain/uClibc_dev//usr/include/features.h:21 9:5: Fehler: #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, uClibc was built without large file support enabled. Large file support isn't select and i have also checked it with make uclibc-menuconfig for uclibc. The same problem happend with beaglebone_defconfig. After "make clean" and selecting "large file support" the build process works. This problem doesn't happend with release 2012.08. Has anybody a hint for me ? Thanks Rainer _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 32+ messages in thread
* [Buildroot] buildroot 2012.11 large file support 2012-12-11 9:30 ` Berns @ 2012-12-12 6:05 ` Peter Korsgaard 0 siblings, 0 replies; 32+ messages in thread From: Peter Korsgaard @ 2012-12-12 6:05 UTC (permalink / raw) To: buildroot >>>>> "Berns" == Berns <Berns@BEKA-Elektronik.de> writes: Berns> I changed from gcc 4.6.X to gcc 4.5.X and now it works. Berns> Maybe it's an isue with ubuntu 12.04 and gcc 4.6.X. Ok, interesting. I don't find anything specific about any largefile changes in 12.04, but will try to find time to install it in a vm to have a look. Could you perhaps put the entire (compressed) failing build log online somewhere so I can have a look? E.G.: make >log.txt 2>&1 bzip2 log.txt -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2012-12-13 11:28 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-10 12:35 [Buildroot] buildroot 2012.11 large file support Berns 2012-12-10 14:53 ` Willy Lambert 2012-12-10 19:20 ` Peter Korsgaard 2012-12-10 19:38 ` Willy Lambert 2012-12-10 20:38 ` Peter Korsgaard 2012-12-10 21:30 ` Willy Lambert 2012-12-10 22:05 ` Peter Korsgaard 2012-12-11 2:13 ` Willy Lambert 2012-12-11 7:04 ` Peter Korsgaard 2012-12-11 8:43 ` Willy Lambert 2012-12-11 9:09 ` Thomas Petazzoni 2012-12-12 1:04 ` Willy Lambert 2012-12-11 15:09 ` Willy Lambert 2012-12-11 16:10 ` Thomas Petazzoni 2012-12-12 0:35 ` Arnout Vandecappelle 2012-12-12 10:16 ` Thomas Petazzoni 2012-12-12 11:01 ` Thomas Petazzoni 2012-12-12 11:03 ` Thomas Petazzoni 2012-12-12 12:47 ` Thomas Petazzoni 2012-12-12 16:47 ` Peter Korsgaard 2012-12-12 17:32 ` Thomas Petazzoni 2012-12-12 20:15 ` Peter Korsgaard 2012-12-12 22:21 ` Thomas Petazzoni 2012-12-12 23:47 ` Arnout Vandecappelle 2012-12-13 10:45 ` Victor Hiairrassary 2012-12-13 10:55 ` Peter Korsgaard 2012-12-13 11:06 ` Arnout Vandecappelle 2012-12-13 11:28 ` Victor Hiairrassary 2012-12-12 9:20 ` Willy Lambert 2012-12-12 10:21 ` Fabio Porcedda 2012-12-11 9:30 ` Berns 2012-12-12 6:05 ` Peter Korsgaard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.