Bob ..

Here is a list of the issues I *THINK* are in my CONFIG.SYS file as a result of
the auto-installation of the BJGPP suite:

REM ** These are required for EMX development for compilation other than C:
SET C_INCLUDE_PATH=c:/emx/emx/include
SET LIBRARY_PATH=c:/emx/emx/lib;D:\JAVA131\LIB;
REM ** To compile C++ programs set CPLUS_INCLUDE_PATH as well
SET CPLUS_INCLUDE_PATH=c:/emx/emx/include/cpp;c:/emx/include
REM ** The genclass utility needs the following environment variable
SET PROTODIR=c:/emx/emx/include/cpp/gen
REM ** To compile programs written in the Objective C language
REM ** set OBJC_INCLUDE_PATH as well
SET OBJC_INCLUDE_PATH=c:/emx/emx/include
REM ** To keep GCC in memory for 5 minutes use
REM ** SET GCCLOAD=5
REM ** To make GCC use pipes instead of temporary files under OS/2 use
REM ** SET GCCOPT=-pipe
REM ** To use The GNU debugger and GNU info browser set TERM and TERMCAP
SET TERM=mono
SET TERMCAP=c:/emx/etc/termcap.dat
REM ** Set the INFOPATH environment variable for info
SET INFOPATH=c:/emx/emx/info

I do not know, but I suspect that the issue of the:

SET LIBRARY_PATH=c:/emx/emx/lib;D:\JAVA131\LIB;

was altered by the installation of the IBM Java 1.3.1 product components and would have to be backed down to:

SET LIBRARY_PATH=D:\JAVA131\LIB;

That for keeping the Java Development product component focused correctly?

I wonder on how this compares or contrasts to your 'test' install?

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

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

I wonder on how this compares or contrasts to your 'test' install?

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

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

OK .. Bob ..

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

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

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

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

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

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

Mike @ 1:117/3001




--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

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

But where did it put the required items for GCC? Did
it put them in the #:\emx diretory? That's what I
sort of gleaned from reading the readme1st text file
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....

OK, that being so, I suppose it would modify-overwrite-
update whatever was in the EMX directory to the latest
and greatest, together with adding whatever down-drill
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....

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

If that's true, we are right back to your original
question about how do we move this off C:, yet keep
C:\emx, so as to not mung everything else that depends
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)

REM ** These are required for EMX development for
compilation other than C:

Ok, if you say so....

SET C_INCLUDE_PATH=c:/emx/emx/include
SET LIBRARY_PATH=c:/emx/emx/lib;D:\JAVA131\LIB;
REM ** To compile C++ programs set CPLUS_INCLUDE_PATH as well
SET CPLUS_INCLUDE_PATH=c:/emx/emx/include/cpp;c:/emx/include

These three set's are in the \emx\bin\setgcc.cmd command file, I think with the
proper location set by the script that made the file. [See my previous edits for this file.] Location of things within \emx tree are different...

REM ** The genclass utility needs the following environment variable
SET PROTODIR=c:/emx/emx/include/cpp/gen

I don't see PROTODIR defined in either config.sys or setgcc.cmd.

REM ** To compile programs written in the Objective C language
REM ** set OBJC_INCLUDE_PATH as well
SET OBJC_INCLUDE_PATH=c:/emx/emx/include

I don't see OBJC_INCLUDE_PATH defined in either config.sys or setgcc.cmd. Probably not tested by most folks. [I might test it due to my background / experience with NeXTStep....]

REM ** To keep GCC in memory for 5 minutes use
REM ** SET GCCLOAD=5
REM ** To make GCC use pipes instead of temporary files under OS/2 use
REM ** SET GCCOPT=-pipe

These two are set as above in \emx\bin\setgcc.cmd.

REM ** To use The GNU debugger and GNU info browser set TERM and TERMCAP
SET TERM=mono

The default TERM set in \emx\bin\setgcc.cmd is different....

SET TERMCAP=c:/emx/etc/termcap.dat

This is set in \emx\bin\setgcc.cmd.

REM ** Set the INFOPATH environment variable for info
SET INFOPATH=c:/emx/emx/info

INFOPATH is set in \emx\bin\setgcc.cmd.


Enjoy.....

Bob Jones, 1:343/41


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

OK Bob ..

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

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

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?" ;)

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

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\ LL;.;C:\VT\SPCH_BIN;C

Snipped but not forgotten!

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

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

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)

OK Bob ..

[Major cut....]

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

Did you find anything in .INI files that needed cleaning out at any place in the system related to this? I haven't played that game....

...

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?

Video? The Max/Linux port is terminal based and using curses (or ncurses)....
This pre-dates Windows and OS/2.... This is dumb terminal, 80x24 character control.... <grin> Which should be fine for a BBS that expects to talk to just "vt-100" or ANSI "dumb" terminals.... <grin>

Ok, maybe in back-porting the Linux to compile using the GNU EMX C compiler under OS/2 I might get some of the older (original) OS/2 code working....

Now, where's sh for OS/2? [The configure script needs it...] Guess I could manually figure out each of the items that script tests and hand edit vars.mk.

And OS/2 TEDIT does nasty things to <TAB>s in text files.... And make that came in GCC321.ZIP does differenciate between <TAB> and eight spaces. :(

Ok, where did I hide that copy of a VI clone for OS/2?

Inquiring mind wants to know. ;)

Come join the fun / insanity on working on the code.... ;)

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)