Re: weird limitation on the system's binutils

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)...