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] |
* 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] |