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: [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 output of:

1) arch
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


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