Opened 11 years ago
Closed 10 years ago
#64 closed enhancement (fixed)
spec: gcc4: Updated wlink with a fix to dynamic memory exhaustion
| Reported by: | dmik | Owned by: | |
|---|---|---|---|
| Priority: | Feedback Pending | Milestone: | |
| Component: | rpm | Version: | |
| Severity: | Keywords: | ||
| Cc: | steve53@…, Dave Yeo, Andib, Steven Levine |
Description
Dave Yeo has wl.exe patched by Rich (Walsh?) to solve the following error when linking too big DLLs with HLL debug information:
Error! E3009: dynamic memory exhausted
This fix in particular makes it possible to build XUL.DLL of Firefox 17 with debug symbols included (wl.exe from the current RPM fails on this). Attaching this exe here (taken from one of his Firefox patch ZIPs).
Attachments (1)
Change History (13)
by , 11 years ago
| Attachment: | wl-from-dave-from-rich.zip added |
|---|
comment:1 by , 11 years ago
comment:2 by , 11 years ago
| Cc: | added |
|---|
I wonder if we should take care that this patch finally goes to watcom source direct. As imho this would be the best solution.
comment:3 by , 11 years ago
Here is the original discussion thread btw: https://github.com/bitwiseworks/mozilla-os2/issues/9#issuecomment-24777003.
Steve, well, you know how difficult that could be. And we need the linker now -)
comment:4 by , 11 years ago
Getting working code into the OpenWatcom sources is easy. I have commit access.
Getting Knut's patch integrated into the current sources is a bit more difficult. It suffers from a bit of bit rot and the patch is spread over 37 files as of my last count.
My best guess is that it's going to take 3-5 days of work to get the patch applied and tested.
comment:5 by , 11 years ago
| Cc: | added |
|---|
comment:6 by , 11 years ago
@Steven I still think that applying would be the best choice. At least for long term.
comment:7 by , 11 years ago
there is also a libc ticket for that http://svn.netlabs.org/libc/ticket/156
comment:8 by , 11 years ago
| Cc: | added |
|---|
comment:9 by , 10 years ago
| Priority: | major → Feedback Pending |
|---|
@Steven isn't this done now with your latest WLINK?
comment:10 by , 10 years ago
| Cc: | added |
|---|
It should be. All the code updates have been committed to the OpenWatcom repository. There are documention updates left to do and this will happen in the fullness of time.
comment:12 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
http://trac.netlabs.org/libc/ticket/156 may require some more work to get closed. Steven should know it better.
As for this one, it's totally worth closing. wl_exe-20140527.zip from Steven https://github.com/bitwiseworks/mozilla-os2/issues/64) fixes this issue. The only thing one should know is that you may have to increase your VIRTUALADDRESSLIMIT value to make big DLLs build. For example, in my case I needed to set it to 2560.
The watcom-wlink-hll-2.0beta1-6.oc00 RPM contains the fixed WLINK. gcc-wlink is a virtual package that drags it in.
Note that there is also the watcom-wrc-2.0beta1-6.oc00 RPM (gcc-wrc drags it) that fixes a critical big in WRC that could corrupt big EXEs and DLLs when linking resources to them. See https://github.com/bitwiseworks/mozilla-os2/issues/29#issuecomment-40560125 for more info.
There is also an updated EMXOMF took (see https://github.com/psmedley/gcc/issues/7#issuecomment-40906460 for more info) that fixes the emxomf: Index too large error that might be of interest. An updated RPM for it (libc-devel) will appear soon.
We should obtain Rich's patches and probably host the WLINK sources somewhere on netlabs or github and ask everyone to contribute there to be able to closer follow the progress and not miss such important fixes as this one.