[gobolinux-users] BootStrap problem

[Aitor Pérez Iturri]

El Tue, 25 Sep 2007 16:35:19 -0700
"Lucas C. Villa Real" <lucasvr at gobolinux.org> escribió

> Is this happening after or before you applied the patch that I
> supplied in the previous email?

Before, but i also needed to add this modification to
MiniSymlinkProgram (function do_link):

function do_link() {
      echo $root/$1           
      echo $root/$2           
   if [ -d "$root/$1" ]       
   then
      cd $root/$2             
      echo goboPrefix=$root goboPrograms=$root/Programs LinkOrExpandAll
$root/$1 --relative $alwaysexpand goboPrefix=$root
goboPrograms=$root/Programs LinkOrExpandAll $root/$1 --relative
$alwaysexpand cd - &> /dev/null elif [ -d "$root/$crossprefixdir/$1" ]
   then
      cd $root/$2             
      echo goboPrefix=$root goboPrograms=$root/$crossprefixdir/Programs
LinkOrExpandAll $root/$crossprefixdir/$1 --relative $alwaysexpand
gobobash-3.1# gcc -o test  -nostdinc
-I/Depot/System/Epia/C3//System/Links/Headers -I -I
-I/Programs/GCC/4.1.2/lib/gcc/i686-pc-linux-gnu/4.1.2/include -march=c3
-m3dnow -O2 -pipe -fomit-frame-pointer
-L/Depot/System/Epia/C3//System/Links/Libraries
-L/Programs/GCC/Current//lib -L/Programs/GCC/Current//usr/lib test.c
Prefix=$root goboPrograms=$root/$crossprefixdir/Programs
LinkOrExpandAll $root/$crossprefixdir/$1 --relative $alwaysexpand cd -
&> /dev/null fi }

Now i have cross programs symlinked under $crossprefixdir/System/Links.

> 
> This is correct. You don't want to mix cross-platform objects in
> $root/System/Links. If your target platform is compatible with the
> host one it's ok; but you'll run in trouble if your host tools try to
> load objects compiled for other archs (think of an ARM's libpthread.so
> in $root/System/Links -- that wouldn't work).

I think i understood how is supposed to work ChrootCompile now,
thanks :).


> Everything should have been taken into account by the LDFLAGS variable
> already (set in Cross-Common.conf, based on the values specified in
> your Cross-EPIA.conf). Are you sure you're not reseting any *FLAGS
> variable in your recipe?

Ok, i think the problem should be here, in the chroot shell showed
after the Bootstrap process (when it fails) i found this:

	bash-3.1# echo $LDFLAGS

	bash-3.1# echo $CFLAGS
	-O2 -march=i686 -fomit-frame-pointer -pipe
	
If i executed this gcc commands it fails:

	bash-3.1# gcc -o test test.c 
	test.c:1:28: error: alsa/asoundlib.h: No such file or directory

If i used the flags in the Cross-Common.conf, it works nice:

	
	bash-3.1# gcc -o test  -nostdinc
	-I/Depot/System/Epia/C3//System/Links/Headers -I -I
	-I/Programs/GCC/4.1.2/lib/gcc/i686-pc-linux-gnu/4.1.2/include
	-march=c3 -m3dnow -O2 -pipe -fomit-frame-pointer
	-L/Depot/System/Epia/C3//System/Links/Libraries
	-L/Programs/GCC/Current//lib -L/Programs/GCC/Current//usr/lib
	test.c 

Just after calling configure my *FLAGS env variables looks nice
(checked with a pre_build hook in recipe) but just in the bash they
dissapear, i need to know why the configure for ALSA-utils is failing.

Greets.

Aitor


-- 
If the kids are united they will never be divided!

----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com/tag/5