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

[Enrico Weigelt <weigelt at metux dot de>]

* Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
> Robert, All,
> 
> On Wednesday 28 July 2010 16:35:37 Robert P. J. Day wrote:
> >   here's a question for which i'm pretty sure i know the answer, but i
> > need to be absolutely sure.
> >   i'm trying to cross-compile a downloaded tarball (the toolchain was
> > downloaded from a vendor), and the instructions for cross-compiling
> > were simply to
> >   $ make CC=arm-...-gcc LD=arm-...-ld
> > which is pretty standard.  but the cross compile failed almost
> > immediately, complaining about a missing "curses.h" file.
> 
> As Ralf stated, the curses headers (and libs!) are not part of the
> toolchain. What I do consider to be are:
> - sanitised kernel headers (if targetting Linux)
> - C library headers
> - optionally, some internal headers from gcc, such as libstdc++ et al.
> 
> The same goes for libraries:
> - the C library .so and .a files, plus any so-called start-files, namely
>   crt{i,n,1].o et al.
> - the internal gcc libraries: libgcc_s.so, libmudflap.so, et al.

ACK. 
Crosstool-NG builds all that for you (many thanks to Yann + contributors :))

BTW: even ct-ng's sysroots still contains a lot of stuff that's not 
needed at build time (but might be required runtime), so there's 
still room for trimdowns ;-p

> >   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?
> 
> Well, standard is by no mean meaningful here. On a desktop PC, then
> one can quite safely say that curses is standard, while on an embedded
> device it is not.

Actually, there is no standard at all. Common desktop and server systems
just happen to have (n)curses already installed (but not neccessarily
the build-time stuff) - depending on your distro.
 
> What I can say is that ncurses is not a standard part of a _toolchain_.

ACK. It's an completely separate package, which has nothing to do
with toolchains at all.
 
> Irrelevant, indeed. But non-sysrooted toolchains are a PITA, and you
> should definitely shake your distributor off to give you a sysrooted
> toolchain. And the code with that, so you can build your better own.

ACK. I'd never waste a single minuted w/ an non-sysroot'ed toolchain.
Build environments get very complex, and you'll most likely have to
touch each single package to make it work. 

Actually, my Briegel buildsystem (which could even build whole distros,
including all dependencies) has sysroot as _primary constraint_.
Each build starts with creating a fresh sysroot tree (from a precompiled
archive - trimmed-down version of the one built by ct-ng on toolchain
creation) and installs the required (precompiled) dependencies there 
(if they're yet missing, they're built first, recursively). So on each
build, the sysroot contains only that individual package's dependencies
(and theirs), nothing else. That helps *a lot* for finding broken packages.

> The compiler should find standard toolchain includes from wherever it
> was configured to find them. For the other headers, there's the -I flag
> to the preprocessor. Ditto for the linker and libraries, there's -L.

Oh, BTW: packages should _never_ add absolute include/library pathes
(outside their own build tree) and imports should run via appropriate
tools like pkg-config which properly support sysroot.
Insane ideas like adding standard pathes or other absolute ones will
simply frack up your build (sometimes it *migh* compile fine, but the
result will be crap). To clean up that kind of certain upstream's 
mess is scope of the oss-qm project ...


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