A while ago and far away I sought out the PJGCC site and checked all the options I thought I ought to have. I made the source archive directory for what would come and downloaded all of what it 'put together' for me into that directory. With it came the needed EMX files, but ..

1.) I'd already installed EMX and run the 'update' for it for the 4.5
or whatever the needed revision was for other things ...

2.) I read (at) the docs and didn't catch something about EMX until ..

Well here cometh a complete packaged update install of GCC .. as GCC321 and, obviously, it's a newer and whatever version. Yep, in reading the docs for it here, it PLAINLY states one should not second guess the path for the automated EMX install of whatever ... or .. it will get put in #:\emx\emx directory .. which is *NOT* what we want.

You betcha .. Mikey puppy goes looking in the #\emx directory and LO! There it is from the old install; #:\emx\emx.. gloom. So puppy goes and sniffs in the CONFIG.SYS file and sure enough, here we are all over the place in it #:\emx\emx there too in re what the install for the compiler put there... sigh.

Since this is whole GCC deal is an unopened treasure box in addition to Watcom C++ V11 updated from paid for play, and in addition to VAC++ here, what is the best course of action?

The PATH statement to EMX is not the #:\emx\emx at all. It is of the, I think,
correct form #:\emx with all the \bin and so on under it. All of the GCC parameters for EMX, I think (THINK?), came in a block of stuff in the CONFIG.SYS after it was installed as PJGCC work? Thus, one would suppose that the applications which depend on it are all flat dumb and happy with what was there, no?

So is the smart thing to do is to whomp out the entire #:\emx\emx directory setup, whomp out the entire CONFIG.SYS line segment which has to do with what the compiler put there? Then next go whomp out the entire #:\PJGCC directory which is there? We then run UNIMAINT and maybe CHECKINI and so on and watch for fireworks? Then .. start all over with the new GCC321 install routine?

Ever seen a puppy going round and round a turtle contemplating something? Ever notice the difference in the puppy's demeanor if the turkle is a SNAPPING turkle?

Advice?

;)

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

Mike @ 1:117/3001

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

...

Well here cometh a complete packaged update install of
GCC .. as GCC321 and, obviously, it's a newer and
whatever version. Yep, in reading the docs for it
here, it PLAINLY states one should not second guess the
path for the automated EMX install of whatever ... or
.. it will get put in #:\emx\emx directory .. which is *NOT* what we want.

...

Yup....

Since this is whole GCC deal is an unopened treasure
box in addition to Watcom C++ V11 updated from paid for
play, and in addition to VAC++ here, what is the best
course of action?

Good question. I've got the beta of Open Watcom installed (right before they released 1.0), and need to upgrade that to the 1.0 version. Also, I'm now trying to get the GCC 3.2.1 package fixed up and running here.... I noticed the install script didn't give me the environment setup the way I need it....

The PATH statement to EMX is not the #:\emx\emx at all.
It is of the, I think, correct form #:\emx with all
the \bin and so on under it. All of the GCC parameters
for EMX, I think (THINK?), came in a block of stuff in
the CONFIG.SYS after it was installed as PJGCC work?
Thus, one would suppose that the applications which
depend on it are all flat dumb and happy with what was there, no?

I have fun, cause I have EMX loaded on my boot partion (normally C:), and I do *not* want the compiler on that partition due to space issues (although it would probably work out.... Yes, I need to re-install the GCC 3.2.1 because I was "testing" and need to place it else where....

So is the smart thing to do is to whomp out the entire
#:\emx\emx directory setup, whomp out the entire
CONFIG.SYS line segment which has to do with what the
compiler put there? Then next go whomp out the entire
#:\PJGCC directory which is there? We then run
UNIMAINT and maybe CHECKINI and so on and watch for
fireworks? Then .. start all over with the new GCC321 install routine?

Good question....

Ever seen a puppy going round and round a turtle
contemplating something? Ever notice the difference in
the puppy's demeanor if the turkle is a SNAPPING turkle?

Advice?

Reload OS and start from sratch?!?!?!? <GDRFC>

When you figure it out, let me know.... Then maybe I can try to get the Maximus / Squish / SqaFix ports that we're (attempting to) compiling using GCC on Linux to see if I can get that version to also compile (and run) under OS/2 using GCC 3.2.1.... That would be nice.... But it could get interesting....

We're close to being able to compile SqaFix under Linux..... Still working out
code clean up so that SqaFix can be GPL'ed. Able to run test compiles of that code using GCC under OS/2 would be nice....

Take care....

Bob Jones, 1:343/41

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

Well Bob .. I can tell this is going to be a long night...

\ /
(?) Puppy contemplating darkness.
@ @

Also, I'm now trying to get the GCC 3.2.1 package fixed
up and running here.... I noticed the install script
didn't give me the environment setup the way I need it....

I have fun, cause I have EMX loaded on my boot partion (normally C:),
and I do *not* want the compiler on that partition due
to space issues (although it would probably work
out....

That's sort of my same wishumz.

Yes, I need to re-install the GCC 3.2.1 because I was
"testing" and need to place it else where....

OH! You got there the same sort of way I did with DJGPP! My assigned home for C/C++ work was planned to be drive E: Watcomm and VAC++ were both stuck there.
I originally did not want the C/C++ dev work on C:, but got sentenced to that with the DJGPP or whatever 'test' install.

Tell you what, I wanna do the same thing you wanna do. When you figure out what has to be modified in the 'install script' would you be so kind as to post
it here?

When you figure it out, let me know.... Then maybe I
can try to get the Maximus / Squish / SqaFix ports
that we're (attempting to) compiling using GCC on
Linux to see if I can get that version to also compile
(and run) under OS/2 using GCC 3.2.1.... That would
be nice.... But it could get interesting....

@ @
(~) So I am guinness puppy?
/ \
. . < -- eyes rolling out here..

Well there may be real reason to go after this. Hold thought a moment.

We're close to being able to compile SqaFix under Linux....
Still working out code clean up so that SqaFix can be
GPL'ed. Able to run test compiles of that code using
GCC under OS/2 would be nice....

Here is my thought and questions.

IBM has given up, per what I read in the MOZ forums, on the VAC++ compiler. They are now actively moving to GCC for version 1.5. Am I correct in my thinking that the latest version 2.0.1 of IBM WEB BROWSER was still compiled, though, with VAC++? And, per the comments in the MOZ forums, there is a good bit of instability, if we can talk that way, about the new work now having been
done on Version 1.4 ... and on into 1.5 as MOZ, right?

So are we saying, in a pointed sort of way, that, perhaps, one of the real reasons that IBM has been investing so much time in MOZ and so on, is to define
its way out of the compiler business with GCC?

Which GCC? This GCC?

More to the point at which I really want to think about! As you probably know this whole issue of OS/2 as we turned the corner toward MCP1/MCP2 with the convergence of all the planets ... was handled with a 'new' compiler. A substantial amount of TestCase work, which is gleanable from the changes in the
TestCase kernel revisions .. has to do, I think, from this compiler shift. It is certainly well known in the Fix Pack comments drifting about.

Which compiler? This compiler?


I personally hold that the only way any operating system ever becomes or stays 'in status', if you will, is via the level of usefulness of one or more COMPILER(s) which can be used with it.

You bet I'm interested in the MAX project to port to Linux with GCC! This is like the dying man who asked for a Priest, a Rabbi, and a Minister! With all due appologies to the real Nurse Ratchett, grin, when the nurse asked, "Why?" He answered, "Well, I'm just hedging my bets!"

Now should I remove DJGPP and install this one? Is that a good bet? Should I put 'im on Drive E:? With your help, of course, no?

If so, I go in and try surgery on C:, I guess..


\
(@)> Puppy contemplating LARGE hole in drive C:.
~ ~ | |


Is this the right compiler for the future of all OS/2?

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

Mike @ 1:117/3001

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

Hello Mike,

Wednesday 30 July 2003 20:30, Mike Luther wrote to All:

So is the smart thing to do is to whomp out the entire #:\emx\emx
directory setup, whomp out the entire CONFIG.SYS line segment which
has to do with what the compiler put there? Then next go whomp out
the entire #:\PJGCC directory which is there? We then run UNIMAINT
and maybe CHECKINI and so on and watch for fireworks? Then .. start
all over with the new GCC321 install routine?

Ever seen a puppy going round and round a turtle contemplating
something? Ever notice the difference in the puppy's demeanor if the
turkle is a SNAPPING turkle?

After installation:

You can also take everything out of config.sys and put all that's to do with a particular software in a separate .cmd file that gets called when that software
is to be run. In that .cmd file you put commands to temp add to the path and libpath the needed directories. Check out BEGINLIBPATH and ENDLIBPATH in the COMMAND REFERENCE.

Here is an example with Virtual Pascal (VP):
------------------------------
@echo off
SETLOCAL
rem SET HELP=%HELP%;C:\VP\;
SET PATH=C:\VP\BIN.OS2;%PATH%;
SET BEGINLIBPATH=C:\VP\BIN.OS2;
VP2 %1
ENDLOCAL
------------------------------

Above is handy for many files which belong together for software that's not used all the time.

Another approach is to stick all files into appriopriate directories which are already in your respective paths (so not use the install routine that comes with that software but instead put all files in the respective directories by hand). I did this with the EMX files. This is handy for not-many files.



Greetings -=Eddy=-

netmail: 2:280/5003.10 1:261/38.3
email: e.thilleman@freeler.nl
e.thilleman@hccnet.nl

... Will someone please explain this conversation to me? -- Bashir
--- GoldED/2 3.0.1
* Origin: ObJoke: Believe me, this code works. I wrote it. (1:261/38.3)

Advice?

Mike:

First, I had to make one change to the install script to load REXXUTIL.DLL. I edited the file name to include the full path of where to find it.

Then I played arround, with multiple runs of install.cmd.

Trying to install to H: causes problems. The install.cmd uses some relative paths that don't work when trying to put emx in H:\EMX.... :(

Final solution....

(a) Ran install.cmd and told it to install in H:\GCC
(b) Allowed install.cmd to make that directory.
(c) Let install.cmd complete.
(d) moved H:\GCC\EMX down to H:\EMX
(e) Edited h:\emx\bin\setgcc.cmd so that H:\GCC becomes H:EMX.
(f) Ran H:\EMX\BIN\EMXREV.EXE to find out current library levels. [Saved a copy by using 'H:\EMX\BIN\EMXREV.EXE 1>EMXREV.OLD'.]
(g) Edited config.sys to change all C:\EMX references to H:\EMX.
(h) Rebooted the system.
(i) Ran H:\EMX\BIN\EMXREV.EXE to see the new library levels. [Also saved a copy.)

I found that I only had the EMX runtime support installed and not the development EMX environment installed. By switching to H:\EMX, I got all of the EMX development (including runtime) support. In my case, the runtime support I had on C: was the same level of code that was installed on H:, so I should be ok.

With this, GCC just works. I don't have to run the setgcc.cmd script to use the compiler. gcc hello.c produced hello.exe, and you know what that prints.... <grin>

[Ok, so hello.c is a file I wrote up, but you know the standard code for this.... <wink>]

I haven't tried anything more complicated yet, but in playing around, I do see that make won't work without adding h:\emx\make to a search path or two. If you do that in config.sys, you will get a number of *nix based commands (make, chmod, cp, etc.), and I don't know if there is any issues with that....

So.... Take care.....

Bob Jones, 1:343/41


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