This is the mail archive of the
mailing list for the crossgcc project.
See the CrossGCC FAQ for lots
Re: [crosstool-NG] Design discussion
A few things, from the "end" user perspective.
I have *no interest* in a tool that builds a root filesystem for me. I
am perfectly capable of making my own system, from init on up to ..
whatever I need for the target. it may not even require init.
nor do i need a tool that builds a native compiler: my target may be too
small for that.
What i do want is a tool that pulls the latest compiler/library/binutils
and (deterministically) makes me a set of (relocatable) crosscompler
toolchains for the targets i want.
i pick a version of crosstool-ng, check it into a vendor branch, make
whatever changes i need to build the set of toolchains i want, check
those into my own local repository, and presto, i have a system (under
version control) that i can use to build toolchains and do regression
tests on if i choose to change library/binutils/compiler versions.
The other point about dependencies: i never had a single problem
satisfying crosstools requirements. i apt-get what i need, note what
they are, and i am done.
in this case, automake, gawk, libtool (yes, it sucks), texinfo, zip, and
fastjar for the target i am concerned with.
The final point is about "detecting" build.... you ever compare the
2) uname -m
3) getconf LONG_BIT
particularly on various x86_64/i686 userland/kernel combinations? not to
mention whether "arch" exists at all....
For unsubscribe information see http://sourceware.org/lists.html#faq