[Buildroot] JFFS2 / MTD suggestions

[Buildroot] JFFS2 / MTD suggestions

[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.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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] JFFS2 / MTD suggestions

[Lloyd Sargent]

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


On Apr 7, 2009, at 10:35 AM, Thomas Petazzoni wrote:

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

[Buildroot] JFFS2 / MTD suggestions

[Peter Korsgaard]

>>>>> "Lloyd" == Lloyd Sargent <lloyd@cannasoftware.com> 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.

-- 
Bye, Peter Korsgaard

[Buildroot] JFFS2 / MTD suggestions

[Cyril HAENEL]

Thomas Petazzoni a ?crit :
> 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
>   
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

-- 

Cyril Haenel
Registered Linux User #332632

[Buildroot] JFFS2 / MTD suggestions

[Peter Korsgaard]

>>>>> "Cyril" == Cyril HAENEL <chaenel@free.fr> 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).

-- 
Bye, Peter Korsgaard

[Buildroot] JFFS2 / MTD suggestions

[Cyril HAENEL]

Peter Korsgaard a ?crit :
>>>>>> "Cyril" == Cyril HAENEL <chaenel@free.fr> 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

-- 

Cyril Haenel
Registered Linux User #332632

[Buildroot] JFFS2 / MTD suggestions

[Peter Korsgaard]

>>>>> "Cyril" == Cyril HAENEL <chaenel@free.fr> 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?

-- 
Bye, Peter Korsgaard

[Buildroot] JFFS2 / MTD suggestions

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 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.

-- 
Bye, Peter Korsgaard

[Buildroot] JFFS2 / MTD suggestions

[Thomas Petazzoni]

Le Tue, 07 Apr 2009 19:02:43 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] JFFS2 / MTD suggestions

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

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

-- 
Bye, Peter Korsgaard