[Buildroot] buildroot 2012.11 large file support

[Buildroot] buildroot 2012.11 large file support

[Berns]

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] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Berns]

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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Arnout Vandecappelle]

  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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Willy Lambert]

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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Fabio Porcedda]

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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Thomas Petazzoni]

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

[Buildroot] buildroot 2012.11 large file support

[Arnout Vandecappelle]

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] buildroot 2012.11 large file support

[Victor Hiairrassary]

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

[Buildroot] buildroot 2012.11 large file support

[Peter Korsgaard]

>>>>> "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

[Buildroot] buildroot 2012.11 large file support

[Arnout Vandecappelle]

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

[Buildroot] buildroot 2012.11 large file support

[Victor Hiairrassary]

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