Problem with LZO package in ARM configuration, need help to solve the problem

Hi all, I always have a problem with the LZO package when I activate the JFFS2 filesystem as output filesystem (generic arm target). Please read the entire explanation because I maybe found the problem but I don't know how to solve it.

When I do a make, everything is OK until the .configure script of the lzo package, the script blocks at this point :

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

I looked in the configure script, and I found the blocking point. It's near line 5540 (I modified the script to do different tests and I don't remember the exact line number) :

if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
(eval $ac_compile) 2>conftest.er1 ac_status=$?
grep -v '^ *+' conftest.er1 >conftest.err rm -f conftest.er1
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5 (exit $ac_status); } &&

     { ac_try='test -z "$ac_cxx_werror_flag"             || test ! -s 

conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); }; } &&
{ ac_try='test -s conftest.$ac_objext'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); }; }; then
ac_compiler_gnu=yes
else
[...]

It's this line which blocks and never return : (eval $ac_compile) 2>conftest.er1
I put the follow line before the "if", to know the content of $ac_compile :

eval echo "$as_me:$LINENO: \"$ac_compile\""

It gives me :

arm-linux-g++ -c -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 conftest.cc >&5

I opened another console, I gone into build_arm/lzo-2.03 directory, and I tried to launch this command line. And it blocks....
Thus I tried to delete command line options one by one.

I first deleted the "-isysroot /home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir" option. After that, it doesn't block but there is an error :

cc1plus: error: invalid option `abi=apcs-gnu'
cc1plus: error: unrecognized command line option "-fsysroot=/home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir/"

Thus I deleted the "abi=apcs-gnu" and "--sysroot=/home/nlc/developpement/linuxEmbedded/buildroot/build_arm/staging_dir/" option :

arm-linux-g++ -c -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 conftest.cc

No error, and no blocking !

Any idea from where the problem can come from ?

I maybe have an idea : why does the script use arm-linux-g++ compiler and not the complete path to the previously built arm compiler toolchain ? Because in fact it seems the configure script uses the arm-linux-g++ compiler _installed_ _on_ _my_ _machine_ !! But this compiler is and old version (gcc3.4) and has nothing to do with buildroot normally !!??

Regards,
Cyril

Cyril Haenel
Registered Linux User #332632

Hi,

Cyril> Any idea from where the problem can come from ?

Not right away...

Cyril> I maybe have an idea : why does the script use arm-linux-g++ compiler Cyril> and not the complete path to the previously built arm compiler Cyril> toolchain ?
Cyril> Because in fact it seems the configure script uses the arm-linux-g++ Cyril> compiler _installed_ _on_ _my_ _machine_ !! But this compiler is and Cyril> old version (gcc3.4) and has nothing to do with buildroot normally Cyril> !!??

Ok, quick test - Rename the old compiler to arm-linux-g++-old and try again - Does it still hang?

Bye, Peter Korsgaard

Peter Korsgaard a ?crit :

When I rename arm-linux-g++ to arm-linux-g++old, its blocks too but on arm-linux-c++...
Thus I renamed arm-linux-* and it works now, thank Peter !! The configure script do this :

checking for arm-linux-g++... no
checking for arm-linux-c++... no
checking for arm-linux-gpp... no
checking for arm-linux-aCC... no
checking for arm-linux-CC... no
checking for arm-linux-cxx... no
checking for arm-linux-cc++... no
checking for arm-linux-cl... no
checking for arm-linux-FCC... no
checking for arm-linux-KCC... no
checking for arm-linux-RCC... no
checking for arm-linux-xlC_r... no
checking for arm-linux-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... yes

In fact when we activate jffs2 filesystem output, lzo must be compiled for the host, thus why does it first try to use arm-linux-g++ !? It's why I am the only one to have this problem since some week, because I am the only one to have a arm toolchain installed on my computer !!

There is surely a bug to fix somewhere, but I don't know where !?

Cyril

Cyril Haenel
Registered Linux User #332632

Hi,

Cyril> In fact when we activate jffs2 filesystem output, lzo must be compiled Cyril> for the host, thus why does it first try to use arm-linux-g++ !? It's Cyril> why I am the only one to have this problem since some week, because I Cyril> am the only one to have a arm toolchain installed on my computer !!

Cyril> There is surely a bug to fix somewhere, but I don't know where !?

Hmm, are you sure this is lzo-host compilation, and not lzo for the target?

Bye, Peter Korsgaard

I think lzo is compiled in the 2 configuration, for the host and for the target.
Because when we activate the jffs2 filesystem output, I think buildroot need mkfs.jffs2 and I think mkfs.jffs2 needs lzo.
But because mtd-utils (and also mkfs.jffs2) is provided in the target, I think lzo is also compiled for the target.

Cyril Haenel
Registered Linux User #332632

Hi,

Cyril> I think lzo is compiled in the 2 configuration, for the host and for Cyril> the target.
Cyril> Because when we activate the jffs2 filesystem output, I think Cyril> buildroot need mkfs.jffs2 and I think mkfs.jffs2 needs lzo. Cyril> But because mtd-utils (and also mkfs.jffs2) is provided in the target, Cyril> I think lzo is also compiled for the target.

Exactly - What is it that fails, lzo for the host or lzo for the target? (the directory name should show it)

Bye, Peter Korsgaard

The problem was in build_arm directory, thus I think it's the target compilation which fails when we have an already installed (old) arm toolchain.

Cyril Haenel
Registered Linux User #332632

Cyril> The problem was in build_arm directory, thus I think it's the target Cyril> compilation which fails when we have an already installed (old) arm Cyril> toolchain.

I see from the first mail that you mentioned build_arm/lzo-2.03, so that's for the target (host would be build_arm/lzo-2.03-host).

I guess the issue is that lzo thinks you have a C++ compiler because of the old compiler in your path, even though you haven't enabled C++ support in your compilation.

Again, please post your .config

Bye, Peter Korsgaard

Cyril> The problem was in build_arm directory, thus I think it's the target Cyril> compilation which fails when we have an already installed (old) arm Cyril> toolchain.

I've just committed a workaround to git (a035275) - Could you give it a try please?

Bye, Peter Korsgaard

Sorry, but I don't understand, what do you want I try to do ?

Cyril Haenel
Registered Linux User #332632

Cyril> Sorry, but I don't understand, what do you want I try to do ?

Checkout git (git clone git://git.buildroot.net/buildroot) and do a fresh build to see if my fix solved your problem.

Bye, Peter Korsgaard

Ok, I use svn habitually, it's why I didn't understood !

The git clone is in progress, I keep you informed

Cyril Haenel
Registered Linux User #332632

I reactived my old arm toolchain installation, and with the last git version it works ;)

Thank you again for you help

Cyril

Cyril Haenel
Registered Linux User #332632

Cyril> No error, and no blocking !

Cyril> Any idea from where the problem can come from ?

Do you have C++ support enabled in BR? Please post your .config (again?)

Bye, Peter Korsgaard