[gentoo-embedded] Cross emerging to a given root.

[gentoo-embedded] Cross emerging to a given root.

[Shinkan]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1036 bytes --]

Re: [gentoo-embedded] Cross emerging to a given root.

[Peter Stuge]

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

Re: [gentoo-embedded] Cross emerging to a given root.

[Shinkan]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1539 bytes --]

Re: [gentoo-embedded] Cross emerging to a given root.

[Ed W]

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

Re: [gentoo-embedded] Cross emerging to a given root.

[Shinkan]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2518 bytes --]

Re: [gentoo-embedded] Cross emerging to a given root.

[Peter Stuge]

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

Re: [gentoo-embedded] Cross emerging to a given root.

[Ed W]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3773 bytes --]

Re: [gentoo-embedded] Cross emerging to a given root.

[Peter Stuge]

Ed W wrote:
> Fundamentally this is the game catalyst seems to be playing, ie
> build one build environment to build the final build

My point exactly.


//Peter

Re: [gentoo-embedded] Cross emerging to a given root.

[Peter Stuge]

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

Re: [gentoo-embedded] Cross emerging to a given root.

[Ryan Tandy]

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

Re: [gentoo-embedded] Cross emerging to a given root.

[Ed W]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1190 bytes --]