JFFS2 / MTD suggestions
Hi,
When selecting jffs2 as the output filesystem, mtd-utils gets compiled both on the host and on the target. I think that generating a jffs2 filesystem image should *not* trigger the compilation/installation of mtd-utils inside the target since this is not necessary.
Moreover, the compilation of host mtd-utils fails with "lzo/lzo1.h not found" if the liblzo-dev package is not installed on the host. We should probably add a test checking this and telling the user to install liblzo-dev, because the current state is quite confusing.
Sincerly,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
I ran into this issue as well and ""lzo/lzo1.h not found" is terribly confusing. Adding just "on host" to the end of the message would clarify it immensely.
Cheers,
Lloyd
Quoted 24 lines · Thomas Petazzoni
Hi,
When selecting jffs2 as the output filesystem, mtd-utils gets compiled both on the host and on the target. I think that generating a jffs2 filesystem image should *not* trigger the compilation/installation of mtd-utils inside the target since this is not necessary.
Moreover, the compilation of host mtd-utils fails with "
lzo/lzo1.hnot found" if the liblzo-dev package is not installed on the host. We should probably add a test checking this and telling the user to install liblzo-dev, because the current state is quite confusing.Sincerly,
Thomas
Signature · 8 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Lloyd" == Lloyd Sargent <[email protected]> writes:
Lloyd> I ran into this issue as well and ""lzo/lzo1.h not found" is terribly Lloyd> confusing. Adding just "on host" to the end of the message would Lloyd> clarify it immensely.
Notice that this is not an error message we're writing, but an error message from configure/gcc.
Anyway, the real fix is to build lzo for the host before mkfs.jffs2, just like we do for the target.
Signature · 1 line
Bye, Peter Korsgaard
Thomas Petazzoni a ?crit :
Quoted 7 lines
Hi,
When selecting jffs2 as the output filesystem, mtd-utils gets compiled both on the host and on the target. I think that generating a jffs2 filesystem image should *not* trigger the compilation/installation of mtd-utils inside the target since this is not necessary.
Quoted 9 lines
Moreover, the compilation of host mtd-utils fails with "
lzo/lzo1.hnot found" if the liblzo-dev package is not installed on the host. We should probably add a test checking this and telling the user to install liblzo-dev, because the current state is quite confusing.Sincerly,
Thomas
Hi,
On my machine I have a strange problem when I activate jffs2 as the output filesystem. The build process blocks when building the lzo package :
configure: Configuring LZO 2.03
checking build system type... i386-pc-linux-gnu
checking host system type... arm-unknown-linux-gnu
checking target system type... arm-unknown-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no checking for arm-linux-gcc... /home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir/usr/bin/arm-linux-uclibc-gcc -Os -pipe -Os -I/home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir/usr/include -I/home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir/include --sysroot=/home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir/ -isysroot/home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir -mabi=apcs-gnu
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
[...]
[...]
[...]
checking how to recognise dependent libraries... pass_all
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for arm-linux-g++... arm-linux-g++
checking whether we are using the GNU C++ compiler...
1 hour after it's alway blocked on the last line...
Any idea !?
Regards,
Cyril
Signature · 2 lines
Cyril Haenel Registered Linux User #332632
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Cyril" == Cyril HAENEL <[email protected]> writes:
Cyril> checking whether we are using the GNU C++ compiler...
Cyril> 1 hour after it's alway blocked on the last line...
Cyril> Any idea !?
Not really, but take a look at the configure script around there to see what it is doing (add a few echo lines).
Signature · 1 line
Bye, Peter Korsgaard
Peter Korsgaard a ?crit :
Quoted 13 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Cyril" == Cyril HAENEL <[email protected]> writes:
Cyril> checking whether we are using the GNU C++ compiler...
Cyril> 1 hour after it's alway blocked on the last line...
Cyril> Any idea !?
Not really, but take a look at the configure script around there to see what it is doing (add a few echo lines).
I need to try to print some echo to find the blocking part in the configure script, but I tried to launch the configure script manually from the lzo directory with the right option :
./configure --target=arm-linux --host=arm-linux --build=i386-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --without-html-dir --disable-gtk-doc --disable-nls --disable-largefile
And it works !! And make compiles lzo successfully. Really curious, the configure script blocks (with exactly the same command line) only when called from high level makefile !?
Cyril
Signature · 2 lines
Cyril Haenel Registered Linux User #332632
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Cyril" == Cyril HAENEL <[email protected]> writes:
Hi,
Cyril> ./configure --target=arm-linux --host=arm-linux
Cyril> --build=i386-pc-linux-gnu --prefix=/usr --exec-prefix=/usr Cyril> --sysconfdir=/etc --without-html-dir --disable-gtk-doc --disable-nls Cyril> --disable-largefile
Cyril> And it works !! And make compiles lzo successfully.
You also need to set CC to your target compiler and so on.
Cyril> Really curious, the configure script blocks (with exactly the same Cyril> command line) only when called from high level makefile !?
Well, you need to compare apples to apples - Buildroot sets a bunch of environment variables before calling configure as you can see when you run it.
It's kind of hard to debug here as I cannot reproduce it. Do you have C++ support enabled in your config? Do you get anything interesting in the build_arm/lzo-2.03/config.log file?
Signature · 1 line
Bye, Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Thomas> Hi,
Thomas> When selecting jffs2 as the output filesystem, mtd-utils gets Thomas> compiled both on the host and on the target. I think that Thomas> generating a jffs2 filesystem image should *not* trigger the Thomas> compilation/installation of mtd-utils inside the target since Thomas> this is not necessary.
Agreed.
Thomas> Moreover, the compilation of host mtd-utils fails with Thomas> "lzo/lzo1.h not found" if the liblzo-dev package is not Thomas> installed on the host. We should probably add a test checking Thomas> this and telling the user to install liblzo-dev, because the Thomas> current state is quite confusing.
Or even better, compile lzo for the host and link against that.
Signature · 1 line
Bye, Peter Korsgaard
Le Tue, 07 Apr 2009 19:02:43 +0200,
Peter Korsgaard <[email protected]> a ?crit :
Quoted 1 line
Or even better, compile lzo for the host and link against that.
I know that's what we do for automake, autoconf, pkg-config, m4 and a bunch of other stuff. But I must admit, that personnaly, I'm not really a fan of this. I would rather prefer to leverage what's installed on the host, and consider that Buildroot having dependencies on installed packages (liblzo-dev and others) is normal.
Currently, one of the strong advantage of Buildroot compared to more heavyweight solutions like OpenEmbedded is that the time for Buildroot checkout to the first basic root filesystem being produced is very small (15 minutes or so). If we start compiling more and more host tools to the point that we basically recompile everything that's on the host, we'll to some extent loose this advantage.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 1 line
Quoted 1 line
Or even better, compile lzo for the host and link against that.
Thomas> I know that's what we do for automake, autoconf, pkg-config, m4 and a Thomas> bunch of other stuff. But I must admit, that personnaly, I'm not Thomas> really a fan of this. I would rather prefer to leverage what's Thomas> installed on the host, and consider that Buildroot having dependencies Thomas> on installed packages (liblzo-dev and others) is normal.
Yes, that works as long as the dependencies are stable and we can work with the various versions available. That's unfortunately often not the case, and then the easiest solution is to simply build it ourselves.
I think lzo clearly fits in the:
- Not available on most systems
- Small and hence quick to compile
- Users (mkfs.jffs2) needs a fairly specific version
Category.
Thomas> Currently, one of the strong advantage of Buildroot compared Thomas> to more heavyweight solutions like OpenEmbedded is that the Thomas> time for Buildroot checkout to the first basic root Thomas> filesystem being produced is very small (15 minutes or Thomas> so). If we start compiling more and more host tools to the Thomas> point that we basically recompile everything that's on the Thomas> host, we'll to some extent loose this advantage.
True. It's a tradeoff ofcourse, but from looking at various bug reports we're unfortunately not in a situation today where people can just download BR on a random machine and run tar jxvf && make menuconfig && make and expect it to work all the time.
Adding more dependencies on the host is not going to make this any better.
Signature · 1 line
Bye, Peter Korsgaard