Subj : EMX / GCC configuration issues
To : Bob Jones
From : Mike Luther
Date : Fri Aug 01 2003 12:28 am
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 ..
\
(@)> 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!
\ /
(@) 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> 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 @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
