GCC + WLINK
Ruediger Ihle
Hi,
which version of WLINK can be used with GCC ? There is a "patched"
version on Netlabs. What's the deal with this one ? It identifies
itself as:
"** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 1.6beta1"
It looks like it has been modified to support IBM-style debugging
information. Is that all that has been changed ? Is it possible
to use a more recent version of the Open Watcom linker (without
IBM debug info support) together with GCC ?
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Dave Yeo
>
> Hi,
>
> which version of WLINK can be used with GCC ? There is a "patched"
> version on Netlabs. What's the deal with this one ? It identifies
> itself as:
>
> "** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 1.6beta1"
>
> It looks like it has been modified to support IBM-style debugging
> information. Is that all that has been changed ? Is it possible
> to use a more recent version of the Open Watcom linker (without
> IBM debug info support) together with GCC ?
I think only wl.exe on Netlabs works with GCC. As far as I know the main
change is the debugging support.
You can always test by setting EMXOMFLD_LINKER to wlink.exe.
We've been using wl.exe to build Firefox etc. Seems to work and can
handle larger DLLs then ilink.
Dave
Ruediger Ihle
> I think only wl.exe on Netlabs works with GCC. As far as I
> know the main change is the debugging support.
> You can always test by setting EMXOMFLD_LINKER to wlink.exe.
I just did that. It looks like in principle a different version of
WLINK can be used. Except GCC is instructed to build a debug version.
In this case it emits a directive to select the format of the
debugging info. A "plain vanilla" WLINK doesn't understand the
"HLL" format introduced in the Netlabs version and will bail out
with an error message.
Question: Is there an environment variable to tell GCC not to issue
the "HLL" directive or - better - to specify an alternate debug info
format ? Given that WLINK supports DWARF, it might be possible that
a refreshed port of GDB would be able to make use of that.
> We've been using wl.exe to build Firefox etc. Seems to work and can
> handle larger DLLs then ilink.
Looking at the README in the JAVA project it seems that none of the
linkers is really working correctly and the programmer has to find
out by trial an error which one might be able to produce working
executables.
Dave Yeo
> On Sat, 25 Jun 2011 16:37:24 UTC, Dave Yeo<dave....@gmail.com> wrote:
>
>> I think only wl.exe on Netlabs works with GCC. As far as I
>> know the main change is the debugging support.
>> You can always test by setting EMXOMFLD_LINKER to wlink.exe.
>
> I just did that. It looks like in principle a different version of
> WLINK can be used. Except GCC is instructed to build a debug version.
> In this case it emits a directive to select the format of the
> debugging info. A "plain vanilla" WLINK doesn't understand the
> "HLL" format introduced in the Netlabs version and will bail out
> with an error message.
OK, that's good to know.
>
> Question: Is there an environment variable to tell GCC not to issue
> the "HLL" directive or - better - to specify an alternate debug info
> format ? Given that WLINK supports DWARF, it might be possible that
> a refreshed port of GDB would be able to make use of that.
As I understand it, GCC just outputs stabs
(http://sourceware.org/gdb/current/onlinedocs/stabs/index.html) attached
to a.out and emxomf converts it to HLL. See
http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/emxomf/stabshll.c
I think that GDB can handle stabs directly so a refreshed GDB port could
handle executable built without -Zomf. At least it worked with GCC 2.8.1
and the old GDB.
The EMX GDB port is ancient along with some other parts of the toolchain
so a port would really have to be done from scratch as far as I can see.
Another possibility is for GCC to output ELF with DWARF attached. Some
work has been done in this direction with libc07 emxomfar and emxomfld
having some support for mixed object formats and wlink being able to
link ELF and possibly link mixed ELF and OMF. Need to test that one day.
>> We've been using wl.exe to build Firefox etc. Seems to work and can
>> handle larger DLLs then ilink.
>
> Looking at the README in the JAVA project it seems that none of the
> linkers is really working correctly and the programmer has to find
> out by trial an error which one might be able to produce working
> executables.
Yea, I've hit limits with both linkers. Last night I also was trying to
build a debug version of Firefox and couldn't build gklayout.lib as
emxomfar kept running out of memory. Seems 1.5 GB process space was too
small and as I only have 768 MBs the swapping was very excessive :)
Windows has also been having similar problems with their linker with
workarounds consisting of using the /3GB flag which can lead to
instabilities due to bad device drivers or using the 64 bit version
which seems to be able to allocate close to a full 4 GBs in a 32 bit
process.
Depressingly we're hitting hard limits with our designed in 1990
operating system.
Dave