weird limitation on the system's binutils
Chuck Swiger
cswiger at mac.com
Sat Jul 1 16:05:08 UTC 2006
Kostik Belousov wrote:
> On Sat, Jul 01, 2006 at 10:08:03AM -0400, Chuck Swiger wrote:
[ ... ]
>> Note that the GNU tools themselves include a certain search path where they
>> look for cross-compilation tools using long pathnames involving a tuple
>> somewhat like the autoconf target specifier, something like:
>> "toolname-vendor-arch-version"
> Exactly, I have the impression that arch-vendor-system-<toolname>
> is the way to go if several crosstools are needed simultaneously.
> And this is how GNU toolchain installs itself by default if
> cross-compiling.
Agreed. The work isn't so much in the GNU tools-- they've been cross-compile
aware for a long, long time to their credit, although the filename conventions
and path lookups are becoming more ornate than functional as time passes.
I start to worry a bit about the extra overhead that lurks behind replacing a
real, compiled compiler executable with a shell script that globs hither and
yon through the filesystem in a quest to find yet more shell-script wrappers
or other forms of indirection. [1]
>> That much would still work on FreeBSD, but big issue comes in creating,
>> importing, and updating the cross-platform shared resources in an organized
>> fashion so that the GNU tools can find it, and there is a ton of glue work
>> that goes into things like ld, ldd, ld.so.1, ar, and the Makefile
>> infrastructure to fully support multi-architecture development.
> Another issue is that, again AFAIK, interface between bfd and rest of binutils
> code is highly fragile and changes in subtle ways between versions.
> It is not supported and definitely causes bugs to mix bfd and the rest
> from different version of binutils.
Yeah, NeXT/Apple has to sit on or be very careful updating changes to the
tools once they'd pushed out a release and needed to maintain backward binary
compatibility.
FreeBSD seems to do OK with this, except for C++-- where changing the symbol
mangling or some such with each point release seems to be common.
>> I'd be happy to help where I can with regard to this, but it's not a minor
>> task-- there's a lot of moving pieces and work involved.
> Completely agree. From my experience with cross-tools, I had to
> carefully select version of binutils and gcc for given target. And,
> sometimes, augment chosen version with patch found somewhere.
> As I see it, having specific ports for each arch, that is maintained
> individually, gives much less maintainance work.
>
> BTW, are there plans for updating binutils in the base system ?
<an interesting question, but not one I can answer....>
--
-Chuck
[1]: For example, no doubt there exists broken compilers somewhere, for which
wrapping every build line in an "if cc $MUMBLE >/dev/null 2>&1; then exit 1"
wrapper would be beneficial rather than counterproductive. Doing it by
default on a Unix system with a working toolchain is silly, and obviously,
hides any useful warnings or errors from being displayed if there was a problem.
And then there's autoconf playing Sorcerer's Apprentice by testing for stuff
that has no bearing on the program being built (ie, looking for a Fortran
compiler or trying to find sizeof() random Windows datatypes when building C99
code that uses int32_t or whatnot)...
More information about the freebsd-current
mailing list