BJ> My test install of GCC 3.2.1 (from the GCC321.zip 
 BJ> file) did *not* modify config.sys.....  :|  .  So, EMX 
 BJ> still works, but the paths aren't in there to allow 
 BJ> GCC (and related utilities) to run....  

 ML> But where did it put the required items for GCC?  Did 
 ML> it put them in the #:\emx diretory?   That's what I 
 ML> sort of gleaned from reading the readme1st text file 
 ML> was going to happen.

GCC and EMX are all in the H:\emx directory tree.  Binaries in \emx\bin,
dlls in \emx\dll, etc.  So, yes, GCC and EMX are bound together.  Since my
EMX stuff on the boot partition was only a runtime environment, I switched
over to using the \emx tree on the H: partition with out problems.  To use
the EMX port of GCC you have to have the full development EMX stuff
installed....  So, it may not be possible to seperate the EMX runtime code
from the compiler in this setup -- at least not easily....

 ML> OK, that being so, I suppose it would modify-overwrite-
 ML> update whatever was in the EMX directory to the latest 
 ML> and greatest, together with adding whatever down-drill 
 ML> it needed for the GCC321 variant to work.

Please remember, once you load the EMX DLL's in memory, it becomes
"interesting" to replace them on a running system.  I
"replaced" them by changing my pointers in CONFIG.SYS to point to
the new location and the re-booted the system.  Otherwise, you need to make
sure the EMX DLL's aren't loaded (or are properly unloaded) before
replacing them....

 ML> That being so, does what I posted also still have to be 
 ML> in the CONFIG.SYS file in order to get things going?  
 ML> Or, conversely, in this implementation of GCC, does the 
 ML> application suite teach itself where the EMX stuff is, 
 ML> and .. in your case and mine ... if we install GCC in 
 ML> other than C:, we will get a non-functional operation 
 ML> related to EMX?

Let's seee....  Grep'ing my config.sys produces the following related to
EMX stuff:  [Warning: MAJOR line wrapping in following three lines!]

LIBPATH=C:\NETSCAPE\PROGRAM;C:\IBMLAN\NETLIB;C:\MUGLIB\DLL;.;C:\VT\SPCH_BIN;C
:\opendoc\BIN;C:\OS2\DLL;C:\MPTN\DLL;C:\IBMCOM\DLL;C:\IBMI18N\DLL;C:\OS2\MDOS
;C:\;C:\OS2\APPS\DLL;C:\BonusPak\ibmworks;C:\BonusPak\rs231b;C:\JAVA11\DLL;C:
\javaos2\dll;C:\MMOS2\DLL;C:\IBMINST;C:\NSC\DLL;c:\tcpip\dll;c:\tcpip\pcomos2
;C:\TCPIP\UMAIL;H:\EMX\DLL;H:\EMX\MAKE;C:\JAVA11\ICATJAVA\DLL;C:\JAVA11\ICATJ
AVA\DAEMON;c:\rfj\dll;C:\Office51
SET PATH=C:\MPTN\BIN;C:\IBMCOM;C:\NETSCAPE\PROGRAM;C:\IBMLAN\NETPROG;C:\MUGLI
B;C:\OS2;C:\VT\SPCH_BIN;C:\opendoc\BIN;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS
2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\BonusPak\ibmworks;C:\Java11\rmi-iiop
\bin;C:\JAVA11\BIN;C:\javaos2\bin;C:\MMOS2;C:\NSC;c:\tcpip\bin;c:\tcpip\pcomo
s2;C:\TCPIP\UMAIL;H:\EMX\BIN;H:\EMX\MAKE;C:\JAVA11\ICATJAVA\BIN;C:\SIO;C:\RFJ
\BIN32;C:\Office51
SET BOOKSHELF=C:\IBMLAN\BOOK;C:\OS2\BOOK;C:\BonusPak\askpsp\books;C:\MMOS2;c:
\tcpip\help;H:\EMX\BOOK;C:\rfj\book;

So, to get this compiler to work, you need LIBPATH, PATH and BOOKSHELF (for
.inf files), updated.  And I think you listed some additional items that
are also needed to have the compiled code work properly.  If you use
curses, and some other stuff, the TZ, TERM and some other variables are
looked at (at run time)....  I've added in the H:\EMX\MAKE path to the
above LIBPATH and PATH to allow Make and some unix like utilities to
run....


 ML> If that's true, we are right back to your original 
 ML> question about how do we move this off C:, yet keep 
 ML> C:\emx, so as to not mung everything else that depends 
 ML> on it, no?

Because I'm actually running off one large drive, I'll live with the EMX
stuff moved to H:.  If I want to back out the compiler, I still have
C:\EMX, so I can just re-point stuff in config.sys....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01