Devel

[tomlohave]

add host-gcc

[tomlohave]

Rudi, can you test this ?

[warped-rudi]

In order to really test this I need a full rebuild. Takes some time...

First thing I noticed: 'packages/system/bash/config/bashrc' is no longer needed.

[warped-rudi]

Not yet a full rebuild, but polkit fails here:

  CCLD     polkitd
/home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/armv6-openbricks-linux-gnueabihf-ld.bfd: warning: libstdc++.so.6, needed by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/armv6-openbricks-linux-gnueabihf/sysroot/usr/local/lib/libmozjs-17.0.so, not found (try using -rpath or -rpath-link)

[tomlohave]

Le 23/11/2014 17:59, Rudi Ihle a écrit : Hello Rudi,

Not yet a full rebuild, but polkit fails here:

CCLD polkitd /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/armv6-openbricks-linux-gnueabihf-ld.bfd: warning: libstdc++.so.6, needed by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/armv6-openbricks-linux-gnueabihf/sysroot/usr/local/lib/libmozjs-17.0.so, not found (try using -rpath or -rpath-link)

did you have the patch about gcc-final applied ? this one is needed It solves this issue. — Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64124972.

www.geexbox.org mailto:tomlohave@openbricks.org

[tomlohave]

Le 23/11/2014 18:38, tomlohave@gmail.com a écrit :

Le 23/11/2014 17:59, Rudi Ihle a écrit : Hello Rudi,

Not yet a full rebuild, but polkit fails here:

CCLD polkitd /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/armv6-openbricks-linux-gnueabihf-ld.bfd: warning: libstdc++.so.6, needed by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/armv6-openbricks-linux-gnueabihf/sysroot/usr/local/lib/libmozjs-17.0.so, not found (try using -rpath or -rpath-link)

did you have the patch about gcc-final applied ? this one is needed It solves this issue. this ones exactly : https://github.com/OpenBricks/openbricks/commit/c8abfacfd42ddf31b172198553bbe0da5e99b83a — Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64124972.

[tomlohave]

Le 23/11/2014 17:00, Rudi Ihle a écrit :

In order to really test this I need a full rebuild. Takes some time...

First thing I noticed: 'packages/system/bash/config/bashrc' is no longer needed.

great, I forget this one. Will correct this — Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64122643.

www.geexbox.org mailto:tomlohave@openbricks.org

[tomlohave]

Le 23/11/2014 18:40, Thomas Genty a écrit :

Le 23/11/2014 18:38, tomlohave@gmail.com a écrit :

Le 23/11/2014 17:59, Rudi Ihle a écrit : Hello Rudi,

Not yet a full rebuild, but polkit fails here:

CCLD polkitd /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/armv6-openbricks-linux-gnueabihf-ld.bfd: warning: libstdc++.so.6, needed by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/armv6-openbricks-linux-gnueabihf/sysroot/usr/local/lib/libmozjs-17.0.so, not found (try using -rpath or -rpath-link)

did you have the patch about gcc-final applied ? this one is needed It solves this issue. this ones exactly : https://github.com/OpenBricks/openbricks/commit/c8abfacfd42ddf31b172198553bbe0da5e99b83a

can you check if it is correctly installed ? here is what I have about libstdc++ : find build/build.cuboxi.eglibc/toolchain/ -name libstdc++.so build/build.cuboxi.eglibc/toolchain/armv7-openbricks-linux-gnueabihf/sysroot/usr/local/lib/libstdc++.so build/build.cuboxi.eglibc/toolchain/armv7-openbricks-linux-gnueabihf/lib/libstdc++.so

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64124972.

[warped-rudi]

The patch to gcc-final was in effect. But I'm the make process did not rebuild gcc-final. I guess it's really time to start from scratch...

[tomlohave]

Le 23/11/2014 19:24, Rudi Ihle a écrit :

The patch to gcc-final was in effect. But I'm the make process did not rebuild gcc-final. I guess it's really time to start from scratch...

in fact , you don't need to rebuild everything, just : ./scripts/unpackagedev gcc-final ./scripts/clean ccache should do the trick — Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64128364.

[warped-rudi]

Another problem: Full build breaks when configuring systemd:

checking for msgmerge... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge
checking for msgfmt... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgfmt
checking for gmsgfmt... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgfmt
/home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge)
configure: error: GNU gettext tools not found; required for intltool

[tomlohave]

Le 23/11/2014 21:54, Rudi Ihle a écrit :

Another problem: Full build breaks when configuring systemd:

grrrr it works here. I have 5 or 6 build from scratch ...

|checking for msgmerge... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge checking for msgfmt... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgfmt checking for gmsgfmt... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgfmt /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge) configure: error: GNU gettext tools not found; required for intltool

checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking whether NLS is requested... yes checking for intltool >= 0.40.0... 0.40.6 found checking for intltool-update... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/intltool-update checking for intltool-merge... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/intltool-merge checking for intltool-extract... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/intltool-extract checking for xgettext... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/xgettext checking for msgmerge... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/msgmerge checking for msgfmt... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/msgfmt checking for gmsgfmt... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/msgfmt checking for perl... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/perl checking for perl >= 5.8.1... 5.14.2 checking for XML::Parser... ok checking whether ln -s works... yes checking for a sed that does not truncate output... (cached) /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/sed checking for grep that handles long lines and -e... (cached) /bin/grep checking for gawk... (cached) gawk checking for /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/armv7-openbricks-linux-gnueabihf-gcc option to accept ISO C99... -std=gnu99 checking for m4... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/m4 checking for xsltproc... /home/thomas/project/openbricks/build/build.cuboxi.eglibc/toolchain/bin/xsltproc

Can you send me your config.log ?

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64134182.

[tomlohave]

Le 23/11/2014 21:54, Rudi Ihle a écrit :

Another problem: Full build breaks when configuring systemd:

|checking for msgmerge... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge checking for msgfmt... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgfmt checking for gmsgfmt... /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgfmt /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by /home/rudi/Projects/openbricks/build/build.raspberrypi.eglibc/toolchain/bin/msgmerge) configure: error: GNU gettext tools not found; required for intltool

can you test this ?

https://gist.github.com/tomlohave/abe7f9e27c205a42fded

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64134182.

[warped-rudi]

I tried a full rebuild, but the host-gcc compile goes crazy. It claims to run out of virtual memory on my 8GB machine. Adding swap makes it allocate about 15GB. After the machine was pretty much unusable for about half an hour I pulled the plug.

[tomlohave]

Le 24/11/2014 18:46, Rudi Ihle a écrit :

I tried a full rebuild, but the host-gcc compile goes crazy. It claims to run out of virtual memory on my 8GB machine. Adding swap makes it allocate about 15GB. After the machine was pretty much unusable for about half an hour I pulled the plug.

??????? try to disable bootstrap but I didnt' test this great , we are in a state where everything is broken, but not for me ...

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64232979.

www.geexbox.org mailto:tomlohave@openbricks.org

[warped-rudi]

Doing a test with MAKEFLAGS=-j1 doesn't show the excessive memory usage. However, besides the fact that it takes very long, it looks like the compiler is being built recursively again and again. If concurrent make is enabled, a lot of child processes are spawned and each of them will consume memory. That's why it ends up with the error I'm seeing.

[warped-rudi]

BTW, is it normal that a directory named 'build/build..' is created?

[tomlohave]

Le 24/11/2014 20:30, Rudi Ihle a écrit :

BTW, is it normal that a directory named 'build/build..' is created? was always here I think

what I don't understand is the infinite loop I'm checking the build script but don't see anything bad, or I m' tired I can provide archive file containing host-gcc build 900 Mo (not stripped)

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64249356.

www.geexbox.org mailto:tomlohave@openbricks.org

[warped-rudi]

I switched back to master and there is no 'build/build..'. I don't know if it got renamed though...

[tomlohave]

Le 24/11/2014 21:04, Rudi Ihle a écrit :

I switched back to master and there is no 'build/build..'. I don't know if it got renamed though... hum don't know what I have done : rm build/build.host -rf rm build/build.. -rf rm build/build.cuboxi* -rf

so starting from here, it's clean

load defconfig then :

make[1]: Leaving directory '/data/project/openbricks/build/build.host/kconfig-frontends-3.12.0.0' scripts/kconfig2options

real 19m2.520s user 48m7.113s sys 10m6.062s

and host-gcc is correctly built

here are my local diffs : diff --git a/packages/host-packages/host-gcc/build b/packages/host-packages/host-gcc/build

index 412c63e..d3171c3 100755 --- a/packages/host-packages/host-gcc/build +++ b/packages/host-packages/host-gcc/build @@ -6,7 +6,7 @@ export BUILD=$BUILD_NOARCH

get_meta $1

-if [ -d $ROOT/$BUILD_NOARCH/hgcc ] ; then +if [ -d $ROOT/$BUILD_NOARCH/hgcc/.install ] ; then echo "Found an already built host-gcc in $ROOT/$BUILD_NOARCH/hgcc" echo " Restoring files ..." cp -r $ROOT/$BUILD_NOARCH/hgcc/.install $ROOT/$PKG_BUILD_DIR @@ -17,10 +17,15 @@ if [ -f $ROOT/$PKG_BUILD_DIR/gcc-ok ] ; then

Nothing to do, gcc is already built

exit 0

else -$SCRIPTS/build internal-m4 -$SCRIPTS/build internal-gmp -$SCRIPTS/build internal-mpfr -$SCRIPTS/build internal-mpc + +for i in m4 gmp mpfr mpc ; do

• $SCRIPTS/clean internal-$i +done + +$SCRIPTS/build internal-m4 --force +$SCRIPTS/build internal-gmp --force +$SCRIPTS/build internal-mpfr --force +$SCRIPTS/build internal-mpc --force

  get_meta internal-gmp dir_internal_gmp=$ROOT/$PKG_BUILD_DIR/.install/usr @@ -46,7 +51,8 @@ CXX=$LOCAL_CXX --with-mpfr=$dir_internal_mpfr \ --with-mpc=$dir_internal_mpc \ --disable-multilib \

• --enable-shared
• --enable-shared \

•       --disable-bootstrap

  make

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64254854.

[tomlohave]

To summarize a little : works on ubuntu 14.10 works on ubuntu 14.04

Will try in the evening on previous version of ubuntu (in vm only)

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64254854.

[warped-rudi]

I'm not at home for the next few days. So I can't try. Maybe on weekend...

[tomlohave]

Le 26/11/2014 21:51, Rudi Ihle a écrit :

I'm not at home for the next few days. So I can't try. Maybe on weekend... If I can find where is the problem with your config (ubuntu ???) I will make optional the use of host-gcc

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-64708759.

www.geexbox.org mailto:tomlohave@openbricks.org

[tomlohave]

it works on 12.04 , default gcc installed and up to date. @warped-rudi , can you confirm you use this version of ubuntu ? version on the bot is this one.

[warped-rudi]

Will test when I find the time. Unfortunately I'm not at home for probably one and a half week.

[tomlohave]

Le 02/12/2014 07:37, Rudi Ihle a écrit :

Will test when I find the time. Unfortunately I'm not at home for probably one and a half week. no problem :) Will see if I can cherry-pick patches from devel that do not force the build of host-gcc

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-65189287.

[warped-rudi]

A quick test gave not change. After a while the Window Manager (!) was killed. Probably due to a low memory situation. It looks like it's running way too many instances of gcc in parallel. If I saw that right, it must have been 50 or so. What version of 'make' do you have on your host?

[tomlohave]

Le 10/12/2014 09:52, Rudi Ihle a écrit :

A quick test gave not change. After a while the Window Manager (!) was killed. Probably due to a low memory situation. It looks like it's running way too many instances of gcc in parallel. If I saw that right, it must have been 50 or so. What version of 'make' do you have on your host?

The same as yours it should be version from our make package I'm away this afternoon but can give you more infos in the evening — Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66420825.

[tomlohave]

Le 10/12/2014 12:45, Thomas Genty a écrit :

Le 10/12/2014 09:52, Rudi Ihle a écrit :

A quick test gave not change. After a while the Window Manager (!) was killed. Probably due to a low memory situation. It looks like it's running way too many instances of gcc in parallel. If I saw that right, it must have been 50 or so. What version of 'make' do you have on your host?

The same as yours it should be version from our make package I'm away this afternoon but can give you more infos in the evening host version is GNU Make 3.81 looking if it really uses our make package (4.0) (could take some time in a vm) — Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66420825.

[tomlohave]

Le 10/12/2014 20:34, Thomas Genty a écrit :

Le 10/12/2014 12:45, Thomas Genty a écrit :

Le 10/12/2014 09:52, Rudi Ihle a écrit :

A quick test gave not change. After a while the Window Manager (!) was killed. Probably due to a low memory situation. It looks like it's running way too many instances of gcc in parallel. If I saw that right, it must have been 50 or so. What version of 'make' do you have on your host?

The same as yours it should be version from our make package I'm away this afternoon but can give you more infos in the evening host version is GNU Make 3.81 looking if it really uses our make package (4.0) seems the case

I have these changes you can test :

setup_toolchain host

+export MAKEFLAGS=-j1 mkdir -p $1 cd $1

@@ -52,13 +54,14 @@ CXX=$LOCAL_CXX --with-mpc=$dir_internal_mpc \ --disable-multilib \ --enable-shared \

• --disable-bootstrap
• --disable-bootstrap \

•       --enable-languages=c,c++

  make

(could take some time in a vm)

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66420825.

[warped-rudi]

O.K., that seems to work. I have to double check what exactly did it, because I experimented with "export MAKEFLAGS=-j1" as well. But I did it after 'configure'...

Now the next problem: cmake fails:

/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk
/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
 (required by /home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk/cmake)
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------

[tomlohave]

Le 12/12/2014 06:50, Rudi Ihle a écrit :

O.K., that seems to work. I have to double check what exactly did it, because I experimented with "export MAKEFLAGS=-j1" as well. But I did it after 'configure'...

Great :p

Now the next problem: cmake fails:

|/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk /cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found

(required by /home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk/cmake)

Error when bootstrapping CMake:

Problem while running initial CMake

installdev host-gcc ?

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66735025.

[tomlohave]

Le 12/12/2014 06:55, Thomas Genty a écrit :

Le 12/12/2014 06:50, Rudi Ihle a écrit :

O.K., that seems to work. I have to double check what exactly did it, because I experimented with "export MAKEFLAGS=-j1" as well. But I did it after 'configure'...

Great :p

Now the next problem: cmake fails:

|/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk

/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by

/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk/cmake)

Error when bootstrapping CMake:

Problem while running initial CMake

installdev host-gcc ? doesn't work .... same problem here looking ...

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66735025.

[tomlohave]

Le 12/12/2014 07:07, Thomas Genty a écrit :

Le 12/12/2014 06:55, Thomas Genty a écrit :

Le 12/12/2014 06:50, Rudi Ihle a écrit :

O.K., that seems to work. I have to double check what exactly did it, because I experimented with "export MAKEFLAGS=-j1" as well. But I did it after 'configure'...

Great :p

Now the next problem: cmake fails:

|/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk

/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by

/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk/cmake)

Error when bootstrapping CMake:

Problem while running initial CMake

installdev host-gcc ? doesn't work .... same problem here looking ...

solved with this minor patch : diff --git a/packages/misc/cmake/build b/packages/misc/cmake/build index 580148a..c1bfee4 100755 --- a/packages/misc/cmake/build +++ b/packages/misc/cmake/build @@ -7,6 +7,8 @@ cd $PKG_BUILD_DIR

setup_toolchain host

+export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH + ./bootstrap --no-qt-gui --prefix=/usr

make

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66735025.

[tomlohave]

Le 12/12/2014 07:20, Thomas Genty a écrit :

Le 12/12/2014 07:07, Thomas Genty a écrit :

Le 12/12/2014 06:55, Thomas Genty a écrit :

Le 12/12/2014 06:50, Rudi Ihle a écrit :

O.K., that seems to work. I have to double check what exactly did it, because I experimented with "export MAKEFLAGS=-j1" as well. But I did it after 'configure'...

Great :p

Now the next problem: cmake fails:

|/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk

/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by

/home/rudi/Projects/openbricks/build/build.cubieboard2.eglibc/cmake-2.8.10.2/Bootstrap.cmk/cmake)

Error when bootstrapping CMake:

Problem while running initial CMake

installdev host-gcc ? doesn't work .... same problem here looking ...

solved with this minor patch : diff --git a/packages/misc/cmake/build b/packages/misc/cmake/build index 580148a..c1bfee4 100755 --- a/packages/misc/cmake/build +++ b/packages/misc/cmake/build @@ -7,6 +7,8 @@ cd $PKG_BUILD_DIR

setup_toolchain host

+export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH + ./bootstrap --no-qt-gui --prefix=/usr

make

a better way is to embed this in config/functions in function setup_toolchain I have done it locally and it works let me knwo what version your prefer

Cheers !

diff --git a/config/functions b/config/functions index 7c1178e..012844e 100644 --- a/config/functions +++ b/config/functions @@ -68,6 +68,7 @@ setup_toolchain() { export PKG_CONFIG_PATH="$ROOT/$TOOLCHAIN/lib/pkgconfig:$ROOT/$TOOLCHAIN/share/pkgconfig" export PKG_PROG_PKG_CONFIG=$PKG_CONFIG export FREETYPE_CONFIG=$ROOT/$TOOLCHAIN/bin/freetype-config

• export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH fi }

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66735025.

[warped-rudi]

Hmm, now the error comes when installing/configuring cmake...

Installing cmake (2.8.10.2-1devarmv7) to root...
Configuring cmake.
eglibc already installed, skipping...
cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by cmake)
make: *** [rootfs] Error 1

BTW, it appears that ' --enable-languages=c,c++' is the thing that solved the host-gcc build... I was able to build without MAKEFLAGS=j1.

[warped-rudi]

I have to take back the last statement: MAKEFLAGS=jX is necessary. However, 'j4' is O.K. for me.

[tomlohave]

Le 12/12/2014 21:33, Rudi Ihle a écrit :

Hmm, now the error comes when installing/configuring cmake...

Installing cmake (2.8.10.2-1devarmv7) to root... Configuring cmake. eglibc already installed, skipping... cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by cmake) make: *\ [rootfs] Error 1

Ok, I think this one is ok : diff --git a/config/functions b/config/functions index 7c1178e..d00b266 100644 --- a/config/functions +++ b/config/functions @@ -49,6 +49,7 @@ setup_toolchain() { export QMAKESPEC=$QT_MKSPECS export QT_PATH_INCLUDES=$LIB_PREFIX/include/qt4 export QT_PATH_LIBS=$LIB_PREFIX/lib

• export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH elif [ "$1" = host ]; then export CC=$HOST_CC export CXX=$HOST_CXX @@ -68,6 +69,7 @@ setup_toolchain() { export PKG_CONFIG_PATH="$ROOT/$TOOLCHAIN/lib/pkgconfig:$ROOT/$TOOLCHAIN/share/pkgconfig" export PKG_PROG_PKG_CONFIG=$PKG_CONFIG export FREETYPE_CONFIG=$ROOT/$TOOLCHAIN/bin/freetype-config
• export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH fi }

BTW, it appears that ' --enable-languages=c,c++' is the thing that solved the host-gcc build... I was able to build without MAKEFLAGS=j1.

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66830920.

www.geexbox.org mailto:tomlohave@openbricks.org

[warped-rudi]

Will try tonight... However, think I've found the root cause for the 'host-gcc' problem: When the build script is invoked the first time, 'build/config/options' does not yet exist. This means that the variable 'CONCURRENCY_MAKE_LEVEL' is not to set causing 'config/path' to emit "MAKEFLAGS=-j". Now guess, what make does in this case... From the docs:

If there is nothing looking like an integer after the ‘-j’ option, there is no limit on the number of job slots.

That might explain the insane number of gcc instances I saw on my system. I'm going to test a patch that will avoid this and maybe limit CONCURRENCY_MAKE_LEVEL to the number of processors. What do you think?

[tomlohave]

Le 13/12/2014 11:10, Rudi Ihle a écrit :

Hello Rudi,

Will try tonight... However, think I've found the root cause for the 'host-gcc' problem: When the build script is invoked the first time, 'build/config/options' does not yet exist. This means that the variable 'CONCURRENCY_MAKE_LEVEL' is not to set causing 'config/path' to emit "MAKEFLAGS=-j". Now guess, what make does in this case... From the docs:

If there is nothing looking like an integer after the ‘-j’ option, there is no limit on the number of job slots.

That might explain the insane number of gcc instances I saw on my system. I'm going to test a patch that will avoid this and maybe limit CONCURRENCY_MAKE_LEVEL to the number of processors. What do you think?

ok, I understand a little better , but that doesn't explain why it works for me how did you "make" the build ? I do it this way :

rm -rf build ./scripts/loadcfg whatever make

Anyway, we must fix it maybe providing a minimal config or ...

note : build.. is still there and that's something that exist from a long time I found an occurrence of this in config/toolchain (2012)

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66871659.

[warped-rudi]

Arggg!!! Now eglibc fails:

checking LD_LIBRARY_PATH variable... contains current directory
configure: error: 
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.
make: *** [rootfs] Error 1

As for build: I do pretty much the same as you. However, I kept the subdirectories for other platforms in ./build. I.e.

rm -rf build/config rm -rf build/build.. rm -rf build/build.host rm -rf build/build.cuboxi.eglibc ./scripts/loadcfg geexbox-xbmc-imx6-cuboxi make

As for the make problem: I have no idea why it doesn't show up on your system. Here is a patch that fixes it. It should allows to set CONFIG_OPT_CONCURRENCY_MAKE_LEVEL=0 in order to use the maximum.

[tomlohave]

Le 13/12/2014 18:09, Rudi Ihle a écrit :

Arggg!!! Now eglibc fails:

grrr ...

Ok I have an idea what to do, unset LD_LIBRARY_PATH for eglibc

My build was ok this morning after the last patch about config/toolchain. (but eglibc was already built)

checking LD_LIBRARY_PATH variable... contains current directory configure: error: * LD_LIBRARY_PATH shouldn't contain the current directory when * building glibc. Please change the environment variable * and run configure again. make: * [rootfs] Error 1

As for build: I do pretty much the same as you. However, I kept the subdirectories for other platforms in ./build. I.e.

rm -rf build/config rm -rf build/build.. rm -rf build/build.host rm -rf build/build.cuboxi.eglibc ./scripts/loadcfg geexbox-xbmc-imx6-cuboxi make hum indeed, same as me.

As for the make problem: I have no idea why it doesn't show up on your system. Here https://gist.github.com/warped-rudi/522d717348faec77a00e is a patch that fixes it. It should allows to set CONFIG_OPT_CONCURRENCY_MAKE_LEVEL=0 in order to use the maximum.

ok, I think it's ok

I didn't push the diff for host-gcc should we build it only for c,c++ languages or ?

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66883242.

[tomlohave]

Le 13/12/2014 19:28, Thomas Genty a écrit :

Le 13/12/2014 18:09, Rudi Ihle a écrit :

Arggg!!! Now eglibc fails:

grrr ...

Ok I have an idea what to do, unset LD_LIBRARY_PATH for eglibc

works with https://gist.github.com/tomlohave/083836ced381acb425c7

My build was ok this morning after the last patch about config/toolchain. (but eglibc was already built)

checking LD_LIBRARY_PATH variable... contains current directory configure: error: * LD_LIBRARY_PATH shouldn't contain the current directory when * building glibc. Please change the environment variable * and run configure again. make: * [rootfs] Error 1

As for build: I do pretty much the same as you. However, I kept the subdirectories for other platforms in ./build. I.e.

rm -rf build/config rm -rf build/build.. rm -rf build/build.host rm -rf build/build.cuboxi.eglibc ./scripts/loadcfg geexbox-xbmc-imx6-cuboxi make hum indeed, same as me.

As for the make problem: I have no idea why it doesn't show up on your system. Here https://gist.github.com/warped-rudi/522d717348faec77a00e is a patch that fixes it. It should allows to set CONFIG_OPT_CONCURRENCY_MAKE_LEVEL=0 in order to use the maximum.

ok, I think it's ok

I didn't push the diff for host-gcc should we build it only for c,c++ languages or ?

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66883242.

[warped-rudi]

O.K., I had a successful build for cubox-i using https://gist.github.com/warped-rudi/2a2cc4f70da19924ceaa on top. Now building cubox...

However, there is one thing I noticed:

export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH

is problematic in so far that since the script is called recursively, we get the same path segment duplicated over and over. I have seen 5 of them...

[warped-rudi]

should we build it only for c,c++ languages or ?

Hmm, I don't know if we need the other languages. Fortran certainly not, but maybe java in case we are building it as well (which AFAIK, we normally do not).

[tomlohave]

Le 14/12/2014 15:55, Rudi Ihle a écrit :

O.K., I had a successful build for cubox-i using https://gist.github.com/warped-rudi/2a2cc4f70da19924ceaa on top. Now building cubox...

However, there is one thing I noticed:

export LD_LIBRARY_PATH=$ROOT/$TOOLCHAIN/local/lib64:$LD_LIBRARY_PATH Great news you have a correct build about LD_LIBRARY_PATH, we can remove the second "path"(at least for ubuntu) this value was not set before

is problematic in so far that since the script is called recursively, we get the same path segment duplicated over and over. I have seen 5 of them...

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66915581.

[tomlohave]

Le 14/12/2014 15:59, Rudi Ihle a écrit :

should we build it only for c,c++ languages or ?

Hmm, I don't know if we need the other languages. Fortran certainly not, but maybe java in case we are building it as well (which AFAIK, we normally do not). ok , so can you push your changes ? and merge devel tree ?

— Reply to this email directly or view it on GitHub https://github.com/OpenBricks/openbricks/pull/32#issuecomment-66915710.

[warped-rudi]

Yes, I think so.

[tomlohave]

closed: host-gcc package is merged