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)
