This is the mail archive of the crossgcc@sources.redhat.com 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] |
Hi, folks. I'm looking to add uClibc support to Dan's crosstool.
Great! (And there's already newlib support in the contrib directory [which I haven't tried out yet]; perhaps we can support all three soon.
Prior projects here have used a system called buildroot to make uClibc-enabled toolchains, so I've been looking at how buildroot does it. Much to my dismay, buildroot patches the binutils and gcc sources in ways that break non-uClibc builds. This is unacceptable because I'm trying to keep a clean single source tree from which I can build multiple targets (BTW, Dan,
I've just about got a patch that lets crosstool share a single unpacked source tree across multiple target builds, lemme know if you're interested). So I'm going through the patches and trying to understand them and modify them so that both uClibc and non-uClibc toolchains build correctly from the same source tree.
They seem to fall into three categories: 1) Keeping the tools from using native stuff (headers, libraries, startfiles, etc.) My current take is that this is residue from the less-enlightened process by which buildroot builds the toolchain, and crosstool has already solved this by cleaner means. Barring failures that can't be overcome any other way, I plan to discard these patches entirely.
2) The dynamic linker. uClibc wants a different dynamic linker than other targets. Buildroot patches binutils bfd files and gcc config files to point to uClibc's dynamic linker everywhere. Unfortunately, it does so without conditionalizing anything. More on this one in just a moment; this is the one I'm focusing on right now.
3) There's one miscellaneous patch I haven't looked at much yet, but the comment says "Prevent gcc from using the unwind-dw2-fde-glibc code". I'm ignoring that one for now, but if somebody has some clue what it's about, and cares to enlighten me, I'm eager to listen.
Sounds like uclibc likes to use a different exception handling scheme. Not terribly surprising, I guess, though it'd be nice if it could be switched with an option rather than a patch.
So, dynamic linker. As was brought up in today's thread, the dynamic linker given in binutils bfd is generic, and generally gets overridden by gcc, which knows more specific information for the particular target. So I'm thinking I can just discard the patch that alters the default dynamic linker in binutils.
However, it seems I want gcc to generate a specs file that's aware of the
uClibc dynamic linker, and if configured for a uClibc target, uses it by
default.
Say, is there any reason we can't name the uclibc dynamic linker by the standard name? Then no changes would be required in gcc, right?
intended target is powerpc405-linux-uclibc (which is itself not a valid canonical target specification -- an issue I'll have to attack soon),
looking at gcc/config/rs6000/sysv4.h, which seems to have most of the interesting specs file generation stuff for powerpc targets.
Questions: 1) If I create a new *_SPEC definition and add it to the list defined by SUBTARGET_EXTRA_SPECS, is that all that's required to add a new entry to the specs file? 2) Since it's in the LINK_OS_*_SPEC definitions where the dynamic linker gets defined, would be most elegant solution be to create a LINK_OS_UCLIBC_SPEC define, have that one give ld the option calling out the uClibc dynamic linker, include it as link_os_uclibc: in all applicable builds, call it out in LINK_OS_SPEC such that -mcall-uclibc works as you'd expect, and if a uClibc target is specifically asked for at gcc build time, change link_os_default to point to link_os_uclibc? Anyone see any pitfalls or aesthetic objections to this approach? Alternate suggestions? 3) How would I go about allowing uClibc to be given as part of a target specification, and have that cause the redefinition of link_os_default to point at link_os_uclibc?
I'm kinda hoping none of the above is needed... - Dan
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |