Re: GNU toolchain working in other directories ?

["Kai Ruottu" <karuottu@freenet.hut.fi>]

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

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

 D:\opt\xgc\erc-coff\bin>gcc -v
 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) :

 D:\usr\local\bin>gcc-rce-elf -print-search-dirs
 install: //c/usr/local/M.CORE/MTCgnu4.0/lib/gcc-lib/rce-elf\egcs-2.91.60\
 <snip>

 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;-):

 D:\usr\local\bin>gcc-mcore-elf-o -v
 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)... 

Cheers, Kai
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.