Pentium GCC patches/binaries for OS/2
------------------------------------------
Last updated on Sunday June 20, 1999 at
6:07
Note that update 1.1.3 was ready a long time ago... in fact, it was ready at
the begining of May. But for different reasons I wasn't able to upload it
'till today... well, enjoy it.
I've ported PGCC 1.1.3. The version 1.1.1 was so incredible full of bugs
that I was forced to do it... I've tried to use 1.1.1 in my projects and
almost everywhere failed - either because compiler ended with an ICE
(internal compiler error) or generated incorrect output. To see what's new
in 1.1.3, refer to the Changes section below.
Sidenote for programmers
You can visit the CrystalSpace homepage for a free (LGPLed)
6-degrees-of-freedom 3D engine. It is currently my main free-time project
(I've made the OS/2 port and working hard on many other aspects). BUT!
Please do not expect to find a ready-to-use product, its still in
developement stage.
Contents
News
This section contains the latest information about what happened to the
compiler
Changes
Here you will find an (almost) complete log of most notable changes
made to latest pgcc for OS/2 versions.
Tips
A number of tips for optimal PGCC usage.
Differences
The differences between PGCC and GCC included with EMX (2.8.0)
Bugs
Known bugs in latest PGCC version
Build
How to build PGCC/2 from scratch
Patches
Patches required to bring "mainstream" PGCC 1.1.3 to PGCC/2 1.1.3
Binaries
The download section
Contact
Contact information
News
The patch below is dated 1.1.3. You will need also (at least) EMX runtime
installed and set-up properly (I presume you already did it if you're
reading this :-) since the compiler binaries requires EMX runtime DLLs, but
if you want to do anything serious with it, I recommend installing entire
EMX (esp. counting that its not so big). The versions 1.1.1 and above of
pgcc/2 requires emx 0.9d; it WONT work with emx 0.9c (at least I did not
tried, but its almost certain).
----------------------------------------------------------------------
PGCC 1.1.3 and multithreaded exceptions! :-) However, I didn't thoroughly
tested it (I'm leaving this as a exercise to the reader :-); this is just
the first release.
I've ported almost all binutils 2.9.1 to OS/2 including GAS! It is not
strictly required if you just need a high-level language compiler such as C
or C++, but you should consider downloading it if you:
* Use assembler inlines frequently - GAS 2.9.1 has a more strict syntax
check than bundled with EMX/GCC GAS 2.6 - for example "movl $5, %cl" is
a valid instruction for GAS 2.6 and is not a valid instruction for GAS
2.9.1.
* GAS 2.9.1 supports new P6 and P5 instructions including MMX. This is
the main reason why I've ported it.
* In general, binutils 2.9.1 has much more options and features than 2.6.
If you use often nm, ar, objdump and so on, you also will appreciate
the new binutils.
I'm waiting for your comments and bug reports (related to the OS/2 port
only, of course).
Changes between several latest versions
pgcc-1.1.3 for OS/2
* Upgraded to egcs 1.1.2/pgcc 1.1.3
* Multithreaded exceptions! LIBGCC is now canned in two separate
versions: multithreaded and single-threaded (and goes from now on into
lib/st and lib/mt directories). Also there is a separate LIBGCC (called
gpp.a) for C++ with exception handling enabled (this has a small
overhead even on programs that do not use exceptions, see tips section
below).
* Applied patch from Marc Leeuwen that fixes incorrect output (program
crashes) on following testcase:
#define LUARRAYROWS 101L
#define LUARRAYCOLS 101L
static void build_problem (double a[][LUARRAYCOLS], int n,
double b[LUARRAYROWS])
{
long i, j, k, k1;
for (i = 0; i < 8 * n; i++)
{
k = 1;
k1 = 2;
for (j = 0; j < n; j++)
a[k][j] += 1;
}
return;
}
Thanks to Vadim Yegorov for pointing this bug to me.
* Applied patch that fixes internal compiler error when using alias
typedefs on classes. Here is a testcase:
class A
{
public:
};
class B
{
public:
};
class C : public A, public B
{
public:
int zz;
};
typedef C ccc;
int a = int (&((ccc *)0)->zz);
Note that because of above two patches the compiler is not quite
"version 1.1.3", it is rather "version 1.1.3 plus two patches". Don't
forget to mention this whenever this could matter.
* I've recompiled all non-compiler files to not use libgcc runtime DLL
anymore. This will remove the need to download new binutils if you
don't want to keep old gcc runtime DLL anymore. The only DLLs required
are those included with emx.
pgcc-1.1.1 for OS/2 release 2
* Ported almost all binutils 2.9.1 instead of just GAS.
* Added libopcodes.a and libbfd.a into binutils distribution - both in
static and dynamic form.
* Recompiled all executables to use only pgcc 1.1.1 runtime DLL. Previous
release contained several executables that requires runtime DLL from
pgcc 1.0.2.
* Added dllar.cmd to base distribution - someone could find it useful. It
is similar to "ar" except that it creates .dll instead of .a libraries.
Also it can be used to convert .a archives into .dll.
* Added book on gprof into docs archive.
* Moved all .h files from include.new/gnu into include.new.
* Changed naming convention for archives. Now [libname].a is an import
library (i.e. for dynamically linking in a .dll) and [libname]_s.a is
the static library.
pgcc-1.1.1 for OS/2
* Upgraded to egcs/pgcc 1.1.1
* Upgraded to emx 0.9d: PGCC will not work anymore with emx 0.9c.
* Now command-line help works without termcap; this is better since it
achieves consistent results across different termcap files (the one
that comes with emx works not too well with CLH). The CLH_TERM variable
can be assigned three different values: "-" for non-colored output,
"mono" for monochrome output and anything other (or unset) for colored
output.
* Exceptions will work from now ONLY if you will link with g++ and ONLY
if you did not used -fno-exceptions during linking. Otherwise a
different version of libgcc is used that has smaller size overhead
(~10K) by the cost of exception handling.
pgcc-1.0.2 release 2 - minor bugfixes
* Re-compiled ld.exe and emxomfld.exe to not use gcc290.dll from
pgcc-1.0.0
* Changed front-end to pre-define __OS2__ symbol when using -Zomf
* Fixed an inconsistency between ld and emxomfld: ld used ldstub.bin when
run with -Zexe while emxomfld searched for nullstub.exe. Now the
"launcher" stub is always called ldstub.bin.
* minor bug in emxfix.cmd: lib/st and lib/mt already exists, so there is
no need to create them.
* New libraries: gpp*.a (which have almost the same functionality as
their gcc*.a counterparts). I was forced to split g++ runtime from gcc
runtime since g++ when used with frame-unwind exceptions required a
slightly longer initialization sequence which pulls a lot of unused
code into executables, even for plain C and F77 not speaking of C++
code without exceptions. So I suggest now linking with gcc even C++
code without exceptions - this will produce slightly smaller
executables (5-10K).
* Fixed the bug with creating a ".exe" file when feeding only linker
files to frontent (ex: gcc -s a.o b.o c.o will produce ".exe"). Now it
takes the basename of first object file and appends .exe or .dll.
pgcc-1.0.2 for OS/2
* Upgraded to egcs-1.0.2.
* Ooops! Due to a bug in my makefiles, libgcc previously used C versions
of some functions instead of optimized versions I wrote in
config/i386/emx-libgcc1.asm. 64-bit division should be slightly faster
now.
* Renamed dynamically-loaded libgcc from gcc290.dll to gcc29027.dll. This
happened because libgcc in pgcc-1.0.2 has been changed, to avoid
conflicts with previous versions of gcc*.dll.
* Added include/cpp/new, include/cpp/exception, include/cpp/typeinfo
files. I don't really know what they are for :-) I don't use libstdc++.
* Included GNU -liberty library into base PGCC/2 binary distribution. The
files added were:
o libiberty.h - mostly interface for string functions in libiberty
o objalloc.h - obstack management
o obstack.h - same
o getopt.h - GNU getopt (getopt_long included too). Replaces EMX's
getopt.h
o demangle.h - C++/Java name demangling functions
o fnmatch.h - Wildcard filename match function Replaces EMX's
fnmatch.h
o ansidecl.h - auxiliary file
o iberty_s.a - static library
o iberty.a - import library
o iberty.dll - dynamic library
To link against static version of GNU -liberty library use:
gcc [...] -liberty_s
To link against dynamic version of GNU -liberty library use:
gcc [...] -liberty
iberty.dll should be on your LIBPATH (and distributed with your
programs, if used). It should be distributed under GNU Library Public
License (LGPL) which can be found in file COPYING.LIB.
2nd release of PGCC-1.0
* multi-threaded and single-threaded libstdc++ library! multi-threaded
libstdc++ uses emx's fast mutex semaphores (fmutex) for synchronising
access to streams, so it is now REALLY multithreaded :-) The files
stdcpp.a and stdcpp.lib have been moved into /emx/lib/st/ and
/emx/lib/mt/ directories.
* fixed a bug with _IO_flockfile and _IO_funlockfile in libstdc++
* fixed a number of minor bugs in supplied header files
o removed limits.h - emx's is good enough
o removed float.h - emx's is good enough
o removed sysinclude.h which is garbage
o removed proto.h which is garbage
o fixed a definition conflict with emx headers in varargs.h and
stdarg.h
* changed behaviour of command-line help. Now by default "gcc -h" will
list a digest of most used GCC options. To see the full help index use
gcc -h* or gcc --help=*
1st release of PGCC-1.0
* My Command-Line help patch is now included! Try gcc -h or gcc --help
and tell me what you think :-)
* libstdc++ (AKA stdcpp.a) is now included into gpp archive.
* IOstream and GNU Fortran manuals are included into the doc archive (in
INF format).
* Caught a bug! in old ld included with EMX. It does not importing
properly symbols from dynamically-linked libraries into the data
segment. I.e: { static FILE *f = stdio; } won't work with -Zcrtdll
since stdio is exported from C runtime DLLs, and f is placed into .data
section. Now it works properly (ugh).
* G++ exceptions now works (although I didn't have time to check it
deeply). I've had to add the support for exceptions into EMX libraries,
so you will need a separate lib/ directory for the new PGCC containing
the modified versions of EMX' libraries. The libraries themself are
partly contained in pgcc-os2-1.1.3-gcc.zip archive, partly made with
the emxfix.cmd file included in same archive. You should run it right
after unpacking the archive.
The dark side is that exceptions are for now single threaded. That is,
you must be sure that no two (no three, no four etc :-) exceptions will
be triggered at same time in two threads of your program, otherwise
most likely you will crash. The cause is that GCC uses for exception
handling some global variables. However, I hope next release of PGCC
will be multithreaded, there is already a patch for this, but it
requires some work.
* EGCS-1.0 has a optional new sheduler called `haifa'. The precompiled
binaries were made with --enable-haifa, so it is enabled now. This
should (could?) give some performance gain with optimization levels
below PGCC's (i.e -O1 through -O3). PGCC optimizes better, as always
:-)
Tips and tricks
1. By default PGCC for OS/2 uses frame-unwind-info exceptions. This mean
that with -fexceptions (which is on by default) gcc will partially
generate debug info which is used then for frame unwinding during
exceptions. Due to this fact files become larger (sometimes up to
~50%!) but this exception mechanism has the advantage of having almost
no overhead at code execution time. That is, try {...} catch () {...}
generates almost no code at all, so the programs runs as fast as
before. The disadvantage of this is executable size, of course. Nothing
comes from nothing. So, if you DO NOT use exceptions, you SHOULD turn
them off (by using -fno-exceptions switch) - this will greatly reduce
your code size.
2. There is also a alternative method for handling exceptions. It is
called setjump/longjump method, and as you understand it uses
setjmp/longjmp instructions. When try {} is encountered, a setjmp() is
executed, and when a exception is thrown it longjumps to the last
setjmp(). This method generates LOTS of messy code (most other PC C
compilers uses same method - I've took a look at Watcom and BCPP) which
decreases execution time but occupies less space than
frame-unwind-info. To use this exception handling method you should use
the -fsjlj-exceptions switch.
3. Please do not mix code compiled with sjlj-exceptions and with
frame-unwind-info exceptions! Exception won't cross the boundary
between different-style exception handling code, so most likely you
will got a 'unhandled exception'. Actually this includes inability to
use pre-compiled libstdc++ with -fsjlj-exceptions (it was compiled with
frame-unwind-info exception handling).
4. In general, my opinion is that you better don't use exceptions at all -
the mechanism is neat but it costs too much; without hardware support
for exceptions it doesn't work good. If you like speed and code size,
forget exceptions; use good old return codes.
5. If you do not use exceptions, you better do the link pass either with
gcc instead of g++, or use -fno-exceptions switch *even on linking*.
The reason for this is that the front-end links your program either
against gcc.a or against gpp.a; second is same as gcc.a but with
frame-unwind info, so resulting executable will be (typically by ~10K)
bigger.
6. If you use frame-unwind-info exceptions, you should not use
-fomit-frame-pointer since stack unwinding functions rely on frame
pointer. Keep in mind that -O5 and -O6 automatically enables frame
pointer ommision, so if you use -O6 you should also use
-fno-omit-frame-pointer.
7. If you don't want to depend on dynamic version of libgcc (gccXXXXX.dll)
and still want to use -Zcrtdll, you can avoid making your executables
dependent on dynamic version of libgcc by using "-lgcc" option on
command line. This will link your program against "gcc.(a|lib)" rather
than against "gcc29*.(a|lib)". Your executables will become a bit
larger, but this is a better choice if you have a small number of
executables compiled with current version of pgcc.
If you installed pgcc on temporary basis (i.e. in /emx/bin.new,
/emx/lib.new and so on) you should consider the following: since by
default gcc always looks first for libraries in "/emx/lib" it will find
the old libgcc as "/emx/lib/gcc.a". To avoid this you should copy
/emx/lib/gcc.a and /emx/lib/gcc_p.a into /emx/lib/st and /emx/lib/mt,
and then remove them from /emx/lib.
------------------------------------------------------------------------
WARNING:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Differences between PGCC and GCC/EMX 2.8.0
Here are the differences between PGCC-1.0 and GCC 2.8.0 The PGCC OS/2 port
is based on Eberhard Mattes's GCC/EMX patches (note that I took his name
into ... brackets... guess why ;-), but were (already) heavily
modified, so not everything should work as in GCC/EMX 2.7.2.1. There are
some small differences which I will list below:
1. PGCC has NO bound checking.
2. The symbol __OS2__ is defined if -Zomf is used.
3. I've removed some of Eberhard Mattes' patches that were related to 8.3
naming convention. FAT is ugly, besides you mostly won't have any
problems with 8.3 names even without these patches. They were related
mostly to GCC-developer related things, like .cse2, .flow, .combine,
.sched and other file name extensions. If you need these files, you
should use a normal filesystem :-) (or use EMXOPT=-t)
4. The -ZC++-comments switch is gone now (hopefully forever) since the
preprocessor (CPP) always enable C++-style comments (unless
-traditional or -lang-c89 is specified -- and of course unless language
itself does not use C preprocessor (CPP)).
5. The -Zexe switch now works correctly (before it worked only in couple
with -o switch). ld and emxomfld were patched too for this (although it
is not required). They are as well a part of pgcc-os2-1.1.3-gcc.zip
archive. Also now the -Zexe option not only creates a fresh file
without extension to keep "make" happy; the behaviour has been changed
to copy a file called ldstub.bin that should be located in same
directory where ld or emxomfld is into the file with same name as
executable but without extension: this avoids two problems at once:
first, many "configure" scripts expects after compiling a test program
to obtain a *non-empty* file; and second, they expect the file to be
runnable, otherwise C compiler is considered a cross-compiler. ldstub
determines the name under which it has been launched and launches in
turn the executable that has same name but with ".exe" appended. So,
for example, if you copy ldstub.bin into "sh" then when you do from,
say, bash:
[c:/] ./sh
you will launch "sh" which in turn will look for "sh.exe" (located in
same directory as "sh" itself) and will run it.
6. All compilers were compiled with -Zcrtdll, so you will need an
installed EMX runtime to run them. Can't imagine why you need GCC if
you don't have EMX :-)
7. The -mprobe switch is retained for backward compatibility, however it
is highly recommended that you use -mstack-arg-probe and
-mno-stack-arg-probe instead since these options are new from
mainstream GCC version, and maybe someday -mprobe will disappear.
Another switch that has to do with stack probing is -f{no-}stack-check.
These switches have same functionality as -m{no-}stack-arg-probe but
uses inline instructions instead of alloca call, so they're faster.
Here is how alloca(20000) is compiled with different switches:
without any switches:
subl $20000,%esp
with -mstack-arg-probe:
movl $20000,%eax
call __alloca
with -fstack-check options:
movl $0,-4392(%esp)
movl $0,-8488(%esp)
movl $0,-12584(%esp)
movl $0,-16680(%esp)
movl $0,-24392(%esp)
addl $-20000,%esp
8. Now alloca() is stack-probe safe, i.e. if you`re compiling with
-mstack-arg-probe switch, alloca() will do stack probes for you.
However, the previous limitation still applies, i.e. if you will do
alloca(4095) twice, this can lead to a crash. The best workaround for
this is to not use threads with non-commited stack at all :-)
9. The provided binaries of GCC will not work in DOS (with EMX or RSX
extenders) since they were packed with LXLITE (no OS/2 2.x too). If you
need either to run GCC in DOS (note that you still can produce
executables that run in DOS), you can try to recompile it yourself. If
you want to run it under OS/2 2.x you should unpack executables (lxLite
-x -r *). If you can't do the listed above yourself, mail me - possibly
if I'll receive enough requests, I'll do a unpacked version. But
personally me for DOS am using DJGPP - it is better suited for DOS.
10. 64-bit ([unsigned] long long) division is now FAST! :-) Its written in
assembly now, and I`ve optimized it by hand. It looks almost ~ten times
faster as before. Signed division is somewhat slower than unsigned, so
if you need speed, use unsigned when possible.
I should say that same routine, coded in plain C (take a look into
libgcc2.c) and compiled with PGCC -O6 is only 10-20% slower (!!!). This
makes me think this routine was the last in my life which I've
assembled manually ;-)
11. -mepilogue did not worked in C++ and possibly other languages which
mangles names. Now fixed.
12. _set_new_handler now is called set_new_handler. However,
_set_new_handler will work too as an alias.
13. PGCC has command-line help. Try: gcc --help gcc --help=* gcc --help=-c
gcc -h-m gcc -h13.15 There is a new optional environment variable:
CLH_TERM. If it is "mono", the help will use only black/white colors;
if it is "-", the help won't use highlighting at all; if it is anything
other (or is not set) the help text will default to colored syntax.
14. Libgcc has been put in a separate DLL. I did this since libgcc changes
often - with each new major gcc release, sometimes even in minor
releases. To avoid conflicts with future/previous libgcc versions,
libgcc will have a name consisting of 'gcc' and gcc's internal version
number without dots. For example, gcc version 2.90.27 will have its
runtime in gcc29027.dll. Do not forget to include this dll with your
programs compiled with runtime dlls. If you want to use -Zcrtdll and
not depend on gccXXXXX.dll you should link with libgcc by using -lgcc
(or -lgpp for C++ programs with exceptions). See also section Tips and
tricks.
15. PGCC has multithreaded support for exceptions. GCC has not.
16. PGCC has multithreaded libstdc++. GCC has not.
If you remember, some old versions of pgcc had the 'char' variable by
default unsigned. I've discontinued this since
1. This was in contradiction with older versions of gcc/emx
2. I've realized that not all DOS/OS2 C compilers have the char by default
unsigned, how I've thought at beginning.
3. Many parts of GCC when compiling emits warnings about such things as
'comparison is always X due to argument range limit' etc when char is
unsigned. This is not too important, but is somewhat discouraging.
4. This is a logical continuation of the line 'long
long/long/int/short/char'.
---------------------------------------------------------------------
Known bugs and limitations
1. emxomf now traps (sometimes?) when compiling with -g (debug) switch.
This is due to new format of debugging info (DWARF2). I do not know how
to fix this. Use A.OUT format (no -Zomf) for debugging and pmgdb.
Solution: This happens because pgcc uses new stabs format (-gstabs+)
while emxomf understands only the standard stabs debugging info. I've
partialy fixed this by adding a tiny command-line preprocessor to gcc.
It scans argv[] and looks for both -Zomf and -g# where # is a number.
If it finds one, it replaces -g# by -gstabs#. This doesn't always help,
however.
2. f77 compiler does not incorporate the changes made for the `main'
ported version for OS/2. I do not know whenever there are other changes
other than those needed `just to make it work'.
3. pgcc/c++ complains on superfluous "__asm__ __volatile__ (...)"
operators. For example (taken from /emx/include/386/builtin.h):
static __inline__ void __enable (void)
{
__asm__ __volatile__ ("sti");
}
Solution: remove __volatile__'s from enable() and disable() functions
in include/386/builtin.h; they're not needed since no registers are
changed inside __asm__ so there is no need to declare it __volatile__:
a better solution for EM imho would be to declare in __asm__ instead of
volatile the list of registers that gets changed).
---------------------------------------------------------------------
Build instructions
If you want to build PGCC/OS2 from scratch (if you're mad enough :-) here
are the instructions how to do it. Note that you either should be current
with Unix-style utilites (I mean the contents of
ftp.leo.org/pub/comp/os/os2/leo/unix/..., for example) or you should have
enough time to learn them (its easy, believe me... despite what m$
propaganda says ;-)
However, if I've succeeded to scare you (;-) you can just download the
binaries (skip this entire paragraph to next separator line) and enjoy.
[Image] To configure PGCC sourcecode to compile for OS/2 you should have:
* GNU Bash (proud to present... my own port ;-). I've also tried with ash
(a excelent port btw) almost successfully; there were only several
minor problems.
* GNU Make (I didn`t tested with DMAKE... don't like it)
* GNU file utils (ls, rm, mv etc)
* GNU text utils (cat)
* GNU sed
* GNU grep (maybe others will work too...)
* GNU bison
* GNU C/EMX 2.7.2.1 (didn`t tested with earlier versions)
* GNU perf (not required)
* GNU flex (AFAIR not required)
* Don't forget to put sh into /bin subdirectory... although theoretically
EGCS' Configure supports ${CONFIG_SHELL} variable, it often ignores it
and runs /bin/sh directly... shame on cygnus :-)
* dllar.cmd. This is a REXX script I wrote which can convert an .a
library into a .dll. It can be found in main archive in bin.new/
directory. It should be placed somewhere along your PATH.
* hmmm... maybe I forgot something ;-) As soon as you'll get a 'command
not found' message, ftp to ftp.leo.org and grab the appropiate tool.
Every Unix tool I use I've downloaded from there.
When you have everything listed above, you should:
1. Get the entire egcs-1.1.2 distribution archive and unpack it to some
directory $(EGCS)
2. Get the PGCC patches and apply them.
3. Copy the contents of the diff.new/egcs/ subdirectory into the $(EGCS)
subdirectory (recursively with all subdirectories).
4. Apply the diff file found in diff.new/egcs/ directory.
The slow (but complete) way :-)
1. Launch $(EGCS)/Configure with bash. This takes lots of time (up to
some minutes!) since it have to recursively walk through all
subdirs and launch Configure there too.
2. Now launch "make" in $(EGCS) directory. You should be prepared to
wait for a LONG time :-)
3. First will be made GNU -liberty library and some other things,
then it will launch the make process for GCC. Here at some point
it can fail. If it does so, proceed as below.
The quick way (if you need only
gcc/gpp/objc/f77/libgcc/libf2c/libobjc)
1. Launch $(EGCS)/gcc/Configure with bash (with optional
--enable-haifa command-line parameter). Also if you want
command-line help don't forget to add --enable-clh command-line
parameter. This won't take so long as the root Configure, and
besides you at least have what to look at during the process :-)
2. Launch "make" in same directory.
If make tries to run 'autoconf' (which you most likely don't have), run
'touch configure', then re-run make. If make tries to launch 'autoheader'
(which is a part of autoconf package too), touch cstamp-h.in then re-run
make. These problems can show up because of inconsistency between time/date
stamp of these files after applying patches.
When GCC compilation will be done, you should build a stage2 compiler.
Stage1 compiler contains debug info so it is usable only for debugging
purposes. A stage2 compiler is built using stage1 compiler (i.e. the
compiler you already have -- with debugging info)
To build stage2 compiler using stage1 compiler (also a stage(n+1) compiler
using stage(n) compiler) you should launch:
bash emx-nextstage
in the $(EGCS)/gcc/ directory.
You can run emx-nextstage up to three times to make stage2 through stage4
compilers. Each successful stage tells you have a compiler that at least can
build itself from scratch.
If you still have problems you should read the file $(EGCS)/INSTALL - it
contains some general instructions on building egcs. Keep in mind that they
are for Unix, not for OS/2.
When you're done playing with stageN compilers, you should take the compiler
from the $(EGCS)/gcc/stageN/ subdirectory (where N is the latest stage you
built) and copy it where you want it. The usual for Unix 'install' process
is not supported, I don't see why I should do it. OS/2's directory structure
is not hardcoded as Unix's, besides each user have its own preferences where
to keep the compiler and the libraries. I'll only list the files that are
part of the final product:
cc1.exe
The C compiler
cc1plus.exe
The C++ compiler
cc1obj.exe
The ObjectiveC compiler
f771.exe
The Fortran77 compiler
cpp.exe
This is the C Preprocessor
xgcc.exe
The GCC driver. Rename it to gcc.exe
g++.exe
The G++ compilation driver. See the comment about g77.exe
g77.exe
The Fortran77 compilation driver. Same as gcc.exe, the difference is
that you can get a gcc.exe without f77 support (if the f/ subdirectory
was missing during configure process), but you'll never get a g77
without that. Besides this, this driver will add the required -lXXX
switches for given language (-lstdc++ for C++, -lf2c for Fortran).
gcov.exe
This is a 'coverage test program'. What it really means I don't know
since I didn't have time to figure it out. I think it should do
something, it's even documented in the GCC documentation :-)
c++filt.exe
This program will take a g++-mangled name and display how it looked
before mangling. Usually gcc/ld/etc will display themself demangled
names, so you won't need them. However, if you will have to dig through
a C++-generated .S file, you'll need it, I bet. Example usage:
c++filt.exe __6classAipcc
will display
classA::classA(int, char *, char)
More complex usage example:
[1|home|d:/emx/_tmp_]nm z.o
0000000c T __$_1A
00000000 T ___1AiPc
[1|home|d:/emx/_tmp_]nm z.o|c++filt.exe
0000000c T A::~A(void)
00000000 T A::A(int, char *)
gcc.a, gcc_p.a, gcc29*.a and gcc29*.dll
This is the GCC runtime library. The makefile will build two versions
of libgcc: one for profiling (gcc_p.a) and the usual gcc runtime
(gcc.a). Besides this, make will build a dynamically-linked version of
libgcc called gcc29*.dll and the import library gcc29*.a. I've decided
to split libgcc from EMX runtime DLLs since they changes with each
version of gcc, and this makes EMX DLLs a mess.
objc.a
This is the ObjectiveC runtime. I don't know really what I should do
with it, so I've just included it into the ObjectiveC distribution :-)
include/*/*
The gcc/include subdirectory will contain a version of system-dependent
include files built right for the version of GCC you just made. You
should grab almost everything you'll find there, except that you'll
need to put 'new.h', 'new', 'exception' and 'typeinfo' files into the
cpp/ subdirectory. You also should delete the 'fixed' and 'README'
files as they are of no use.
After this you can go to egcs/i386-ibm-os2/liberty,libio,libstdc++
directories and build stdc++ and libiberty libraries. Also if you want to
build Fortran runtime libraries you should do it in egcs/libf2c. I won't
include detailed instructions since most likely you won't need to do it -
its a whole mess.
---------------------------------------------------------------------
The patches
The patches can be found in a separate archive pgcc-os2-1.1.3-diff.zip in
the diff.new/ subdirectory. This directory also contains a number of patches
to some emx tools (ld, emxomfld etc). Most notable patch to ld is its
ability to handle both 'something.a' and 'libsomething.a' library naming
scheme. This comes in very handy when using Unix makefiles without
modifications.
Also it was modified to allow exporting not only code-segment entries, but
data and bss segment entries too. I'm not sure, but I think you will need
this new ld to build libgcc.
---------------------------------------------------------------------
The binaries
Filename Size Description
GNU compiler front-door (GCC), C
pgcc-os2-1.1.3-gcc.zip 1509644 PreProcessor (CPP), GNU C
bytes compiler (CC1), ld, emxomfld,
libraries and some short docs
pgcc-os2-1.1.3-gpp.zip 1705611 GNU C++ compiler (needs previous
bytes archive).
GNU Objective C compiler plus
pgcc-os2-1.1.3-goc.zip 1010485 Objective C runtime library &
bytes
headers
pgcc-os2-1.1.3-docs.zip 818605 GCC documentation converted from
bytes .texi into OS/2 .INF book format
pgcc-os2-1.1.3-g77.zip 1247580 GNU Fortran77 compiler.
bytes
The patches (AKA diffs) that
pgcc-os2-1.1.3-diff.zip should be applied to pgcc 1.1.3
to make it work under OS/2.
binutils-os2-2.9.1-bin.zip GNU binary utilites version 2.9.1
(precompiled binaries).
GNU binary utilites version 2.9.1
(precompiled binaries) that will
work in plain DOS as well... note
that you need an updated RSX
binutils-dos-2.9.1-bin.zip otherwise they will complain "emx
0.9d or later required". This can
be disabled somehow via EMXOPT
but I don't remember now... and
don't care anyway. This archive
is here due to a requests I got.
binutils-os2-2.9.1-docs.zip GNU binary utilites version 2.9.1
documentation converted to .INF
GNU binary utilites version 2.9.1
binutils-os2-2.9.1-diff.zip differences from released
sources.
If you have problems downloading above files (broken links etc) you can
inspect the ftp directory directly: ftp://goof.com/pub/pcg/os2
---------------------------------------------------------------------
Whom to contact in case of problems
* If you have problems with the installation or configuration, please try
to solve them yourself. If you want to recompile GCC you should be
skilled with EMX and have basical knowledge of Unix tools.
* If you have problems with the generated code, i.e. the compiler does
produce wrong output, consider asking your question on the beastium
mailing list. Refer to the FAQ on how to subscribe.
* If you have problems regarding the OS/2 port itself, you can contact me
by e-mail
------------------------------------------------------------------------
Problems? Look at this page, to see how we can solve them.
------------------------------------------------------------------------
This page is maintained by Andrew Zabolotny,