GNU toolchain working in other directories ?
Sat Jul 24 15:44:00 GMT 1999
I was in a two weeks holiday, so this reply is a little late...
Franklin Hooker wrote:
> >> > GCC_EXEC_PREFIX
> Conflicts arise when the various GNU distributions are installed into
> DIFFERENT hierarchies. Thus their GCC_EXEC_PREFIX settings must be
I didn't first understand that the question was about pre-built binaries,
and not using several self-made toolsets in a single system... Ok, I understand
the mess in this...
All we have some kind of NIH-attitude sometimes, and inventing some
'creative' install paths will make us proud of ourselves ;-) So all kind of
default ('/usr/local') or recommended ('/opt/...' in SVR4) install hierachies
are forgotten when we build our toolsets...
My first released GCC-binaries (m68k-coff target for DOS) had not the Cygnus
'relative path' addition -- it was invented later or I just wasn't aware of it,
and used the prefix '/gcc'. Neither had my later Cygwin-b19-hosted toolsets
the 'relative-path' addition...there was the 'mount' command and I thought that
using it was enough... They used the default prefix '/usr/local', however...
But currently I always use the default '/usr/local' for every host and use
the relative-path fixes for DOS-like hosts like DJGPP2, emx, mingw32 and
Cygwin. Using the relative-path addition under Linux hasn't seemed to be
necessary yet (there are more rigid recommendations about using '/usr/local'
or '/opt' under Unix'es).
A strong reason for using the '/usr/local' could be the GNU documentation. A
clip from 'Using and Porting GNU CC' from RMS:
------------ clip ------------------------
Tools and Libraries for a Cross-Compiler
If you have a cross-assembler and cross-linker available, you should install
them now. Put them in the directory /usr/local/target/bin. Here is a table of
the tools you should put in this directory:
------------ clip ------------------------
The word 'target' is emphasized (in italics) in the docs, not showing here...
To get novice users not confused with the clashing docs and the reality, using
just the same hierarchy as the docs say could be just the best, unless there is
some strong reason to not use it, like the SVR4 '/opt' recommendation...
Once I downloaded (for pure curiosity) a prebuilt embedded-sparc toolset
(Win32/Cygwin-b19 hosted) from somewhere and found it to use the SVR4 '/opt'
recommendation, but not the '/opt/gcc' as the prefix (and not using the
relative path additions to the search paths):
Reading specs from \opt\xgc\lib\gcc-lib\erc-coff\2.8.1\specs
gcc version 2.8.1
I think Mumit Khan using just the same hierarchy/prefix in his 'updated GCC'-
releases for Cygwin, as the original Cygwin-release (quite logical) but the
crosscompiler releases for Win32 seem all to use some new prefix of their
own... Another example, an old Motorola M.CORE-toolset binary release for
Win32/Cygwin (perhaps the current release has changed this) :
Perhaps someone has downloaded any of the m68k-coff toolsets from David
Fiddes.. What install prefix they are using? Is the relative-path addition in
use in them?
If one doesn't need to be dependent on the available pre-built toolsets
and can build his/her tools him/herself, there aren't much troubles... But I
really don't envy those who try to use a Cygwin, a XGC, a M.CORE and some of
those of my b19-based releases without the relative-path addition in a single
Win32 system... Sigh...
I haven't tracked the binary releases for Linux, but I would expect them using
the default prefix '/usr/local' (gcc-2.8.x stupidly defaulted to '/usr' for a
Linux host). Or toolsets for any other *nix. Perhaps there is just the same
kind of 'creativity' in use on all of them...
There is the default but not much warnings about not using it in public
releases or recommendations to use it (if one just ignores what RMS has written
in GCC manual for the 'prefix'). The Cygnus relative-path addition is a nice
thing, but unfortunately not used much yet -- I'm quite sure that the current?
M.CORE (MTCgnu4.5) sources (egcs-1.1.1 - based) didn't have the fixes added...
BTW, I built my own 'mcore-elf' for Win32/mingw32 host with the relative-path
and with the 'plain vanilla' prefix (having always a NIH-attitude;-):
Reading specs from E:/usr/local/lib/gcc-lib/mcore-elf/egcs-1.11/specs
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release, MTC-4.5)
Ok, lets hope that this long story gets us cross-GCC builders to think a while
before using that '--prefix=my-own-beautiful-dir' while configuring and not
using the relative-path additions for the search paths (using GCC_EXEC_PREFIX
could salvage the situation of different hard-coded prefixes)...
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
To remove yourself from the crossgcc list, send
mail to firstname.lastname@example.org with the
text 'unsubscribe' (without the quotes) in the
body of the message.
More information about the crossgcc