Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Embedded (http://www.linux-archive.org/gentoo-embedded/)
-   -   Cross emerging to a given root. (http://www.linux-archive.org/gentoo-embedded/289524-cross-emerging-given-root.html)

Shinkan 12-02-2009 04:46 PM

Cross emerging to a given root.
 
Hi again to all,

I emerged a cross-compiler on my host.
It's not to compile to a different arch than my host, but to compile with given versions of glibc/binutils, to be sure that some bins will run on my target system.



1) Is there any other way to do that without emerging a cross-compiler on my host ?

When I try to cross-emerge bash on my target dir, it fails because it doesn't find curses lib.
I fixed that by cross-emerging ncurses on /usr/$CTARGET, then retrying to cross-emerge bash on my real target.


Is there any conf-based way of telling cross-emerge to look for its libs in my real target and not on /usr/$CTARGET.
I want /usr/$CTARGET to just have the cross-compiler. I wants cros-emerged suff to be somewhere else.



Thanks in advance.
--
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I wonder why we think faster than we speak. Probably so we can think twice." - Bill Watterson

Peter Stuge 12-02-2009 07:04 PM

Cross emerging to a given root.
 
Shinkan wrote:
> to compile with given versions of glibc/binutils, to be sure that
> some bins will run on my target system.
>
> 1) Is there any other way to do that without emerging a
> cross-compiler on my host ?

You could do it for the toolchain, and use eselect to pick which one
should be active. For libc, I don't think it's possible.


> I fixed that by cross-emerging ncurses on /usr/$CTARGET, then
> retrying to cross-emerge bash on my real target.
> Is there any conf-based way of telling cross-emerge to look for its
> libs in my real target and not on /usr/$CTARGET.

No. If you want bash within the empty target directory, you also need
all it's dependencies in there.


> I want /usr/$CTARGET to just have the cross-compiler. I wants
> cros-emerged suff to be somewhere else.

I don't think that's how it works, but I'll be honest and say that I
haven't used this method myself. I've only done "direct" cross
compilation, without emerge.


//Peter

Ryan Tandy 12-02-2009 07:09 PM

Cross emerging to a given root.
 
Shinkan wrote:
> I emerged a cross-compiler on my host.
> It's not to compile to a different arch than my host, but to compile
> with given versions of glibc/binutils, to be sure that some bins will
> run on my target system.

If you aren't cross compiling, you could start a chroot using an
appropriate stage for your target architecture. Then once you had the
appropriate toolchain set up in that chroot you could install packages
in that chroot, build them there and merge them to a different ROOT, or
even just build binary packages. I don't think crossdev is necessary at
all for what you're trying to do.

Thanks,
Ryan

Shinkan 12-03-2009 01:21 PM

Cross emerging to a given root.
 
2009/12/2 Peter Stuge <peter@stuge.se>


Shinkan wrote:

> to compile with given versions of glibc/binutils, to be sure that

> some bins will run on my target system.

>

> 1) Is there any other way to do that without emerging a

> cross-compiler on my host ?



You could do it for the toolchain, and use eselect to pick which one

should be active. For libc, I don't think it's possible.



In fact I noticed I don't really need cross dev.
So I just emerged GCC 3.4 (my host is compiled with 4.3), gcc-config selected it.
Would that be sufficient to build my target (by doing emerge --root=/mytarget --config-root=/myconfig system) en ensure my target will run GCC 3.4 compiled binaries ?



I tested it and emerge failed on some ports because installing them use binaries that complain about not finding required versions of "CXXABI" or so in libstdc++.
What could I do to fix that ?




--
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I wonder why we think faster than we speak. Probably so we can think twice." - Bill Watterson

Ed W 12-03-2009 03:50 PM

Cross emerging to a given root.
 
Ryan Tandy wrote:

Shinkan wrote:


I emerged a cross-compiler on my host.
It's not to compile to a different arch than my host, but to compile
with given versions of glibc/binutils, to be sure that some bins will
run on my target system.



If you aren't cross compiling, you could start a chroot using an
appropriate stage for your target architecture. Then once you had the
appropriate toolchain set up in that chroot you could install packages
in that chroot, build them there and merge them to a different ROOT, or
even just build binary packages. I don't think crossdev is necessary at
all for what you're trying to do.





As stated previously this is the "tiny gentoo" writeup on the gentoo
wiki.* Works very nicely



Ed W

Ed W 12-03-2009 03:52 PM

Cross emerging to a given root.
 
Shinkan wrote:


I tested it and emerge failed on some ports because installing them
use binaries that complain about not finding required versions of
"CXXABI" or so in libstdc++.

What could I do to fix that ?



Are you sure emerge failed or that the binary failed to run on the new
system?


In the later case it's because certain lib files are part of GCC and
hence won't be installed on your target - I find this on a few packages
and I just copy across the relevant libs from the host system


Good luck

Ed W

Shinkan 12-03-2009 05:17 PM

Cross emerging to a given root.
 
2009/12/3 Ed W <lists@wildgooses.com>


Shinkan wrote:




I tested it and emerge failed on some ports because installing them use binaries that complain about not finding required versions of "CXXABI" or so in libstdc++.

What could I do to fix that ?






Are you sure emerge failed or that the binary failed to run on the new system?



In the later case it's because certain lib files are part of GCC and hence won't be installed on your target - I find this on a few packages and I just copy across the relevant libs from the host system



lzma failed to run because of something it didn't like in libstdc++ from /usr/lib/gcc/my-other-gcc-version/ or something like that.

It seems that retrying a gcc-config + env-update + source /etc/profile made it pass.



I'm not exactly on the TinyGentoo case because I would prefer host to serves as a build env instead of untaring another stage3.
As I have many various targets to build and maintain, it would be hard to also maintain their respective build chroots.



Playing with different compilers on the host seems to do the trick.
For now I play with gcc-config on host every time I work with a target which needs a different gcc, but that's much pain (what if I forget to gcc-config back to my actual host gcc version ??! I'll lscrew my host I guess.)


I would really like if there was an option on make.conf to specify default compiler. As each of my targets have its own make.conf and profile link, it would be very comfortable if I could tell emerge to use the compiler specified in make.conf, so that each time I'd cross-emerge, the good compiler for my target would be selected.



Thanks a lot for your directions, TinyGentoo wiki page is really useful.
--
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I wonder why we think faster than we speak. Probably so we can think twice." - Bill Watterson

Peter Stuge 12-03-2009 10:19 PM

Cross emerging to a given root.
 
Shinkan wrote:
> So I just emerged GCC 3.4 (my host is compiled with 4.3),
> gcc-config selected it.
> Would that be sufficient to build my target (by doing emerge
> --root=/mytarget --config-root=/myconfig system) en ensure my
> target will run GCC 3.4 compiled binaries ?

Yeah.


> I tested it and emerge failed on some ports because installing them
> use binaries that complain about not finding required versions of
> "CXXABI" or so in libstdc++.
> What could I do to fix that ?

In a later email you write "something" twice instead of providing a
complete and full error message. Please always show the exact errors
that you encounter, or people will not be able to answer you what to
do.

I find that libstdc++.so.6 from gcc sometimes needs to be included in
the target, in order to run some (usually third-party) binaries.


//Peter

Peter Stuge 12-03-2009 10:23 PM

Cross emerging to a given root.
 
Shinkan wrote:
> For now I play with gcc-config on host every time I work with a
> target which needs a different gcc, but that's much pain (what if I
> forget to gcc-config back to my actual host gcc version ??!
> I'll lscrew my host I guess.)

I would be more worried about always remembering to set the correct
compiler for each target. This is something that I think you must
automate yourself.


> it would be very comfortable if I could tell emerge to use the
> compiler specified in make.conf,

I doubt this will happen - but you could of course patch emerge to do
it.

I suggest that you write a small wrapper script instead, and create a
new configuration file where you store the required gcc version for
each target. Make sure to put the full tuple with version number in
there and not the gcc-config index, which changes whenever you add or
remove a compiler version on the host.


//Peter

Ed W 12-04-2009 08:55 AM

Cross emerging to a given root.
 
Hi





lzma failed to run because of something it didn't like in
libstdc++ from /usr/lib/gcc/my-other-gcc-version/ or something like
that.






My point exactly, your problem report was completely about the wrong
thing - you were reporting a problem on the host when you meant to
report a problem on the target....



Lots of stuff just assumes that GCC is installed and fails to specify
it in the RDEPENDS.* Just copy across the relevant library manually if
you don't want the whole of the package installed







I'm not exactly on the TinyGentoo case because I would prefer host to
serves as a build env instead of untaring another stage3.




?? The extra stage is just a clean way to have a known build
environment?* Nothing wrong with using your normal host OS, but using a
chroot means you can version/backup/lockdown the build environment.*



In case you misunderstand the idea is not to just pull down a stage3 or
whatever each time?* You can just make a copy of your normal OS if you
wish instead?* The point was just to have a minimal chroot with largely
only the stuff you need to build your targets



As I have many various targets to build and maintain, it
would be hard to also maintain their respective build chroots.




Why?* Can't be any harder to maintain one (optionally more) locked
down, backed up chroots than your whole main OS that could change at
any time...* If you upgrade glibc on your host then the targets could
all become bolloxed



Remember you have all kinds of tricks to use to simplify maintenance of
your one or more chroots, eg binary packages, hardlinks, scripts, etc



Fundamentally this is the game catalyst seems to be playing, ie build
one build environment to build the final build



For now I play with gcc-config on host every time I work
with a target which needs a different gcc, but that's much pain (what
if I forget to gcc-config back to my actual host gcc version ??! I'll
lscrew my host I guess.)




Chroots and some wrapper scripts...



I would really like if there was an option on make.conf to
specify default compiler. As each of my targets have its own make.conf
and profile link, it would be very comfortable if I could tell emerge
to use the compiler specified in make.conf, so that each time I'd
cross-emerge, the good compiler for my target would be selected.




Read the docs for portage.* The make.conf/portage dirs used are all
configurable using environment variables - hence you can have multiple
profiles for different targets.* It nearly works as advertised...
Couple of quirks



Note it won't switch compilers, but this seems very easily scripted
(./setup_build_environment myquirkybuilds_2)



Ed


All times are GMT. The time now is 10:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.