OK Bob ..

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

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

Based on the above, which is what I hoped you'd reveal ..

          \
           ({at})>         Puppy has jumped in the hole in drive C:.
      |      ~ ~     |

The earlier instance of GCC has gone down the drain.  First went the
directory of all the compiler, followed by UNIMAINT check.  No interaction
except for the directory loss itself.  Next went all the CONFIG.SYS lines
which cited the C:\emx\emx\... blahblah stuff which produced neither
UNIMAINT grousing or reboot grousing.  Following that, I renamed the second
\emx directory tree to \emxx and cleaned the .INI files plus rebooted.
Nothing noted.  Last step was to trash the \emxx directory tree.  Still no
interaction at all.

      |              |  Wholly water here!

           \ /
           ({at})        Puppy has just changed into a rabbit!
           ~ ~
Amazing what can happen when you jump into the OS/2 lake and discover you
have been changed into a whole new ball game without a fuss!  "My
watch tells the month, doesn't your's?" ;)

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

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

 BJ> LIBPATH=C:\NETSCAPE\PROGRAM;C:\IBMLAN\NETLIB;C:\MUGLIB\
 BJ> LL;.;C:\VT\SPCH_BIN;C

 Snipped but not forgotten!

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

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

About to be likewize, but in my case, on drive E: which is where I really
wanted to handle all the C/C++ work.

Now ... that would, as it stands, when you folks over in the MAX mash get
things more organized; be where I could work at learning the backwards game
to video and all for DOS, from working code!  And eventually, for maybe
WIN-ugh in the reverse?   And just MAYBE, it will be in the compiler which
has relevant value in the IBM internal world as well?


Inquiring mind wants to know. ;)



--> Sleep well; OS/2's still awake! ;)

Mike {at} 1:117/3001

--- Maximus/2 3.01