This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wanting to verify that a toolchain should be entirely self-contained


* Ralf Corsepius <ralf.corsepius@rtems.org> wrote:

> >   $ make CC=arm-...-gcc LD=arm-...-ld
> >
> >which is pretty standard.
> 
> Well, though this is pretty common, it's not "standard" by any means
> 
> Actually, it often is "simply plain wrong" ;)

ACK. That relies on a lot of assumptions, eg. 

* the toolchain commands have to be named like this
* they have to be reachable via $PATH
* assumes that there's only one toolchain for that target type

In my setups, I build all toolchains via crosstool-ng, installing
each one under its own prefix (eg. /opt/x-tools/$targetname/)
and add proper symlinks that they're all reachable by a canonical
name (eg. $toolchain_prefix/bin/gcc, ...), so the only parameter
is the $targetname (thats just a name w/o further meanings ;-o),
everything else is found via a canonical fs structure.

(crosstool-ng does almost everything for you - just a few canonical
symlinks are yet missing: the installed toolchain commands still
have the target-tuple in their names ... but that's fixable ...)

If you don't have special reasons for using that particular 
toolchain (you've already downloaded), I'd suggest building your
own using crosstool-ng.
 
> >   the software compiles fine natively on my ubuntu 10.04 system,
> >because i have all the curses-related packages installed.  but if i'm
> >trying to cross-compile, is it not the responsibility of the
> >*toolchain* to supply all necessary standard header files?
> Define "standard" ;)
> 
> AFAICT, curses.h is not part of POSIX or similar.

Nope. (n)curses is an additional package, which just happens to be
installed on most *nix systems.

You'll have to build it for your cross-target (using your toolchain)
and install it into the toolchain's sysroot directory.

> >   someone else claimed that what i really needed to do was install the
> >toolchain at /opt rather than elsewhere because the README claimed
> >that the toolchain wasn't relocatable.  but i can't see how that's
> >relevant.
> Correct, this remark is likely nonsense and is almost for sure not 
> related to your "curses.h" issue.

It would be related if the toolchain already had a bundled (n)curses
(which in the other hand doesnt make much sense to do that ;-o)
 
> >   if i'm trying to cross-compile, and a C file includes a header file,
> >and the toolchain doesn't supply that header file, shouldn't i expect
> >the build to fail?
> Letting building a package fail if it doesn't find a requirement (e.g. 
> header, library, ...) is common practice - You'd have to talk to your 
> package's upstream. 

Actually, that should be a primary constraint, assuming a proper QE ;-)

> Likely they are not aware about curses not being part of many toolchains.

Most likely, they don't care at all, but simply expect it to be 
installed at a proper place where the toolchain will find it.
Those things are simply out-of-scope for individual packages. All
they'll have to do is a clean import (eg. pkg-config or even hack up
a trivial compile-test).

> > i certainly don't expect the cross compiler to
> >wander off, looking for header files elsewhere
> This would certainly fail somewhere and is likely not helpful.

A clean toolchain wouldn't do that, it would simply use sysroot.
 
> >so my position is that
> >that toolchain simply isn't capable of compiling anything that
> >requires curses capability because it doesn't provide a curses.h file.
> Not quite. Likely you are facing a missing package dependency/missing 
> requirement.

Right. Every package might have dependencies. And of course they 
have to be installed in a proper place first (as it also would be
the case for non-cross environments).

What you probably want is a cross-capable package management system,
which sets up the sysroot w/ the necessary dependencies.
Maybe you'd like to try my Briegel buildsystem ... ;-p


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]