* Moving toolchain to other host
@ 2010-01-22 23:57 Rod Nussbaumer
2010-01-23 9:13 ` Joachim Nilsson
2010-01-23 12:47 ` Martin Guy
0 siblings, 2 replies; 6+ messages in thread
From: Rod Nussbaumer @ 2010-01-22 23:57 UTC (permalink / raw)
To: crossgcc
Hi all.
Because I have had no end of problems getting ct-ng to build toolchains
on my normally designated development host (RHEL 4.X clone), I have
created a Debian 5.02 host for the sole purpose of running ct-ng. This
seems to work fabulously, so far, and I've been able to generate i686
targeted and ARM targeted toolchains. Me happy.
Now, the question is, can I move those toolchains over to my RHEL 4.X
&/or RHEL 5.X host(s), in order to compile code to run on embedded
targets? The Redhat boxes are presently running kernels version 2.6.9 &
version 2.68.18. If I build against those kernel versions when I build
the toolchain, does that buy me anything? What IS the upshot of changing
kernel versions when building the toolchains? Can I/should I build a
specific version of the C Library with the toolchains?
Now that I'm thinking about, I guess I would give myself the best chance
by using versions of all compilers, libraries and kernels that match the
versions on the RHEL sort-of target. I suppose that in some sense, I am
making a Canadian cross, bu hoping to cheat and just copy the toolchains
without targeting them to a different host type. Are there general rules
about what object code is runnable on other OS versions?
--- rod.
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Moving toolchain to other host
2010-01-22 23:57 Moving toolchain to other host Rod Nussbaumer
@ 2010-01-23 9:13 ` Joachim Nilsson
2010-01-23 12:47 ` Martin Guy
1 sibling, 0 replies; 6+ messages in thread
From: Joachim Nilsson @ 2010-01-23 9:13 UTC (permalink / raw)
To: Rod Nussbaumer; +Cc: crossgcc
Hi Rod!
The biggest concern isn't the host kernel version, instead it's the host
GLIBC/EGLIBC version. If you build on a system with too new GLIBC the
toolchain won't run on systems with an older GLIBC.
Example: at our R&D company we've standardized on Ubuntu 8.04 LTS, this
was a compromise to get a least common denominator between the IT staff
and the developers. However, most developers run Ubuntu 9.10 and some
don't even use Ubuntu - they use Gentoo, SuSE or Fedora. I have found
it possible to support all the developers by building our toolchains on
an aging Ubuntu 8.04 32-bit installation. It seems (the symbols of) its
GLIBC version is available in all the other distributions used. At
least the ones we've tried.
I hope this helps!
Regards
/Joachim
On 01/23/2010 12:57 AM, Rod Nussbaumer wrote:
> Hi all.
>
> Because I have had no end of problems getting ct-ng to build
> toolchains on my normally designated development host (RHEL 4.X
> clone), I have created a Debian 5.02 host for the sole purpose of
> running ct-ng. This seems to work fabulously, so far, and I've been
> able to generate i686 targeted and ARM targeted toolchains. Me happy.
> Now, the question is, can I move those toolchains over to my RHEL 4.X
> &/or RHEL 5.X host(s), in order to compile code to run on embedded
> targets? The Redhat boxes are presently running kernels version 2.6.9
> & version 2.68.18. If I build against those kernel versions when I
> build the toolchain, does that buy me anything? What IS the upshot of
> changing kernel versions when building the toolchains? Can I/should I
> build a specific version of the C Library with the toolchains?
> Now that I'm thinking about, I guess I would give myself the best
> chance by using versions of all compilers, libraries and kernels that
> match the versions on the RHEL sort-of target. I suppose that in some
> sense, I am making a Canadian cross, bu hoping to cheat and just copy
> the toolchains without targeting them to a different host type. Are
> there general rules about what object code is runnable on other OS
> versions?
>
> --- rod.
>
>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Moving toolchain to other host
2010-01-22 23:57 Moving toolchain to other host Rod Nussbaumer
2010-01-23 9:13 ` Joachim Nilsson
@ 2010-01-23 12:47 ` Martin Guy
2010-01-23 17:40 ` Rod Nussbaumer
1 sibling, 1 reply; 6+ messages in thread
From: Martin Guy @ 2010-01-23 12:47 UTC (permalink / raw)
To: Rod Nussbaumer; +Cc: crossgcc
On 1/22/10, Rod Nussbaumer <bomr@triumf.ca> wrote:
> Because I have had no end of problems getting ct-ng to build toolchains on
> my normally designated development host (RHEL 4.X clone), I have created a
> Debian 5.02 host for the sole purpose of running ct-ng.
Well, a separate question is, what were those problems and can you
hack ct-ng to work round them? If you can do that in a portable way it
would save other people's time in future. However, you may not have
the time to do that.
> Now, the question is, can I move those toolchains over to my RHEL 4.X &/or
> RHEL 5.X host(s), in order to compile code to run on embedded targets? The
> Redhat boxes are presently running kernels version 2.6.9 & version 2.68.18.
Like Joachim says, the kernel version in crosstool refers to the
version of the kernel running on the target ARM host, not the one the
crosstool-builder runs on, and is most likely to affect the building
of the C library for the target.
> Are there general rules
> about what object code is runnable on other OS versions?
As long as they use the same ABI and have the same major version of
the same C library (almost certainly glibc) you will usually be OK.
The kernel is usually careful to keep ABI compatability. If you do
have a mismatch it should become evident pretty soon, like the
binaries refusing to run at all.
M
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Moving toolchain to other host
2010-01-23 12:47 ` Martin Guy
@ 2010-01-23 17:40 ` Rod Nussbaumer
2010-01-23 17:59 ` Yann E. MORIN
2010-01-23 20:13 ` Yann E. MORIN
0 siblings, 2 replies; 6+ messages in thread
From: Rod Nussbaumer @ 2010-01-23 17:40 UTC (permalink / raw)
To: Martin Guy; +Cc: crossgcc
Martin Guy wrote:
> On 1/22/10, Rod Nussbaumer <bomr@triumf.ca> wrote:
>> Because I have had no end of problems getting ct-ng to build toolchains on
>> my normally designated development host (RHEL 4.X clone), I have created a
>> Debian 5.02 host for the sole purpose of running ct-ng.
>
> Well, a separate question is, what were those problems and can you
> hack ct-ng to work round them? If you can do that in a portable way it
> would save other people's time in future. However, you may not have
> the time to do that.
It isn't really so much a matter of time, as the ability to bring all of
the support tools up time version levels required to install and run
ct-ng. I posted a message some time ago, querying whether the stated
versions were required, and Yann replied that indeed they are.
As I become more acquainted with ct-ng and its inner workings, I feel
certain that I will indeed kick back some hacks.
>
>> Now, the question is, can I move those toolchains over to my RHEL 4.X &/or
>> RHEL 5.X host(s), in order to compile code to run on embedded targets? The
>> Redhat boxes are presently running kernels version 2.6.9 & version 2.68.18.
>
> Like Joachim says, the kernel version in crosstool refers to the
> version of the kernel running on the target ARM host, not the one the
> crosstool-builder runs on, and is most likely to affect the building
> of the C library for the target.
Thanks. That makes sense. Can you confirm that the directory structure
that was created by ct-ng on the original build host must be (or need
not be) maintained on the new build host (there should be a name for
that; how about 'refugee host'?).
And speaking of directory structures, I am still struggling with the
nature of such directories. In the documentation, 'overview.txt', I see
the command:
export PATH="${PATH}:/your/toolchain/path/bin"
My toolchain is in the default ${HOME}/x-tools/....
Within that tree, I can find no less than four 'bin' directories:
${HOME}/x-tools/i686-nptl-linux-gnu/bin
${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/bin
${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/sys-root/usr/bin
${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/debug-root/usr/bin
It would be nice if the doc's were a bit more explicit about which of
these bin directories is considered to be '/your/toolchain/path/bin'.
For the record, I've been trying to use
'${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/bin', but I am
unsure whether this is actually correct, and have no idea what pupose is
served by the others. I can guess a little about the sys-root one, but
the rest is a mystery to me.
>
>> Are there general rules
>> about what object code is runnable on other OS versions?
>
> As long as they use the same ABI and have the same major version of
> the same C library (almost certainly glibc) you will usually be OK.
> The kernel is usually careful to keep ABI compatability. If you do
> have a mismatch it should become evident pretty soon, like the
> binaries refusing to run at all.
Thanks for the helpful replies Martin and Joachim.
--- rod.
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Moving toolchain to other host
2010-01-23 17:40 ` Rod Nussbaumer
@ 2010-01-23 17:59 ` Yann E. MORIN
2010-01-23 20:13 ` Yann E. MORIN
1 sibling, 0 replies; 6+ messages in thread
From: Yann E. MORIN @ 2010-01-23 17:59 UTC (permalink / raw)
To: crossgcc; +Cc: Rod Nussbaumer, Martin Guy
Rod, All,
On Saturday 23 January 2010 18:39:54 Rod Nussbaumer wrote:
> I posted a message some time ago, querying whether the stated
> versions were required, and Yann replied that indeed they are.
Yes, I remember.
> >> Now, the question is, can I move those toolchains over to my RHEL 4.X &/or
> >> RHEL 5.X host(s), in order to compile code to run on embedded targets? The
> >> Redhat boxes are presently running kernels version 2.6.9 & version 2.68.18.
[--SNIP--]
> Thanks. That makes sense. Can you confirm that the directory structure
> that was created by ct-ng on the original build host must be (or need
> not be) maintained on the new build host (there should be a name for
> that; how about 'refugee host'?).
The toolchains generated with crosstool-NG are relocatable; that is, paths
are not hardcoded, so you can move them around in the tree.
> And speaking of directory structures, I am still struggling with the
> nature of such directories. In the documentation, 'overview.txt', I see
> the command:
> export PATH="${PATH}:/your/toolchain/path/bin"
> My toolchain is in the default ${HOME}/x-tools/....
Nope, it's in ${HOME}/x-tools/${CT_TARGET}
which for you is: ${HOME}/x-tools/i686-nptl-linux-gnu
> Within that tree, I can find no less than four 'bin' directories:
> ${HOME}/x-tools/i686-nptl-linux-gnu/bin
That one!
> It would be nice if the doc's were a bit more explicit about which of
> these bin directories is considered to be '/your/toolchain/path/bin'.
Given the above explanations, could you come up with a patch to fix
docs, please?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Moving toolchain to other host
2010-01-23 17:40 ` Rod Nussbaumer
2010-01-23 17:59 ` Yann E. MORIN
@ 2010-01-23 20:13 ` Yann E. MORIN
1 sibling, 0 replies; 6+ messages in thread
From: Yann E. MORIN @ 2010-01-23 20:13 UTC (permalink / raw)
To: crossgcc; +Cc: Rod Nussbaumer
Rod, All,
Here are the explanations you asked :
On Saturday 23 January 2010 18:39:54 Rod Nussbaumer wrote:
> And speaking of directory structures, I am still struggling with the
> nature of such directories. In the documentation, 'overview.txt', I see
> the command:
> export PATH="${PATH}:/your/toolchain/path/bin"
> My toolchain is in the default ${HOME}/x-tools/....
> Within that tree, I can find no less than four 'bin' directories:
>
> ${HOME}/x-tools/i686-nptl-linux-gnu/bin
The toolchain is instaleld in CT_PREFIX_DIR, which you can set in the
menuconfig. CT_PREFIX_DIR defaults to: ${HOME}/x-tools/${CT_TARGET} [1]
CT_TARGET is computed, and in your case expands into: i686-nptl-linux-gnu
Which gives the toolchain installation path, which you is what we
give to gcc et al. when calling "./configure --prefix" :
${HOME}/x-tools/i686-nptl-linux-gnu/
The executables are installed in the prefix/bin directory, which is:
${HOME}/x-tools/i686-nptl-linux-gnu/bin
That's what you need to put in the PATH.
> ${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/bin
This is internal to gcc/binutils to but /backends/. You should not
meddle in the affairs of gcc/binutils.
> ${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/sys-root/usr/bin
The sysroot. See: http://gcc.gnu.org/install/configure.html#TOC3
> ${HOME}/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/debug-root/usr/bin
Beside the toolchain proper (which is essentially made of kernel headers /
binutils / gcc / glibc ), crosstool-NG also builds some debug tools, such
as gdb / dmalloc / strace /... While those are not strictly part of the
toolchain, it's always very interesting to have those when doing X-devel.
Because these are not strictly part of the toolchain, they do not belong
to the sys-root, and I choosed (and that was on purpose) to install them
along-side the sys-root, into the debug-root. Get things from in there
and put on your target. Ready to run. Kinda...
HTH...
Regards,
Yann E. MORIN.
[1] This not necessary the best place the user will want to install the
toolchain, but:
- ${HOME} is a place the user can write to, as compared to other common
places (/usr/local, /opt...) where the user may not have write access to;
- using a sub-dir will not clutter the user's home, and it's trivial to
get rid of ( rm -rf ~/x-tools ).
YEM.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'
--
For unsubscribe information see http://sourceware.org/lists.html#faq
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-01-23 20:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-22 23:57 Moving toolchain to other host Rod Nussbaumer
2010-01-23 9:13 ` Joachim Nilsson
2010-01-23 12:47 ` Martin Guy
2010-01-23 17:40 ` Rod Nussbaumer
2010-01-23 17:59 ` Yann E. MORIN
2010-01-23 20:13 ` Yann E. MORIN
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).