Mail Archives: cygwin/1999/01/22/03:44:32
On Thu, 21 Jan 1999, Tom Uban wrote:
> (C:\CYGNUS\B19\H-I386-CYGWIN32\BIN\LD.EXE 1000) commit_and_inc:
> VirtualAlloc fai
> led
> \pin2000/xina/graphics/libgraph.a: could not read symbols: Memory exhausted
I used to run into this circa B19, but B20.x fixed a lot of that. Of
course, you may still run into it if you're using up all your available
VM!
> I am running on Windows95 with the following:
Ah, in that case, you may still be stuck even if you use the newer release
of the Cygwin runtime. The VM stinks on W95. I've run the same build job
on the same machine, and it dies with ``no more memory'' on W95, while
runs fine while running NT 4.0SP3/128M.
> Is there anything I can do to fix this problem? I am running what I believe
> to be the latest cygwinb19.dll. Can I do some sort of multi-stage link to
> limit the amount of memory needed by the linker?
Upgrade the memory ?-)
My first suggestion of course is to upgrade to Cygwin b20.x, which handles
memory a lot better. Remember the heap_chunks or what not back in those
days?
Failing that, here's what I can suggest:
- first of all, dump egcs-1.0.3 and upgrade to egcs-1.1 for cygb19
which has a much improved binary utilities.
- try incremental linking (use `ld -r', don't use `gcc -Wl,-r'). I don't
know if the linker you have is buggy when it comes to incremental
linking or not, but the newer versions do work. BTW, if you have C++
code with static/global constructors/destructors, you should use `-Ur'
instead of `-r'
Here's an example:
$ ld -r incr1.o foo1.o foo2.o foo3.o lib1.a lib2.a
$ ld -r incr2.o incr1.o foo4.o foo5.o
$ gcc -o prog incr2.o
Chances are you'll still run into the problem simply because the number
of symbols is essentially the same, but worth a shot.
Regards,
Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -