Subj : EMX / GCC configuration issues
To   : Mike Luther
From : Bob Jones
Date : Thu Jul 31 2003 07:34 pm

 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
 * Origin: Top Hat 2 BBS (1:343/41)

.