Date: Sun, 18 Jan 1998 03:42:50 -0500 From: "Kaleb S. KEITHLEY" <k.#nojunk#keithley@opengroup.org> To: freebsd-hackers@FreeBSD.ORG Subject: ld falls down linking wine980104 Message-ID: <34C1C08A.59E2B600@opengroup.org>
next in thread | raw e-mail | index | archive | help
(I've (re)subscribed to this list, but I haven't received an acknowledgement yet, so would appreciate it if you'd cc me at kaleb@opengroup.org if you reply.) Subject sort of says it all. I've got 100+ meg of swap and ld grows (watched with top) to ~30 meg before it exits with an "unable to allocate memory" error. This is a long-standing problem actually -- in the past whenever I try to link a fully-debuggable X server or statically link an X program with a fully debuggable Xlib I encounter the same problem; although it's not uncommon in this case for ld to grow to 80+ meg (all available memory) before encountering the error. (Dunno why the wine link craps out at 30 meg, unless it tries to allocate something really huge and exits more quickly than top updates.) I don't suppose anyone would be surprised that the idea of debugging a linkedit of a huge program to find this bug is, shall we say, daunting. That not withstanding I have tried some semi-obvious things: - I've built a debuggable ld and run it in gdb with a breakpoint set in xmalloc where it spits out the "uhable to allocate memory" message. A `where` show that the stack is scrambled. (Why it's scrambled is probably the answer to the question.) - I've changed all the alloca() calls to xmalloc+free to try to move the problem or at least reduce the likelihood of scrambling the stack with an inadvertant buffer overflow. That didn't change anything. - I've added extra padding to all the mallocs. That didn't change anything. - I've looked at the 2.2.5 and 3.0-SNAP ld sources, which are all unchanged from my system's 2.2.2R sources. - In a desperation move of sorts, even knowing beforehand that it wasn't going to work, I still tried the GNU binutils 2.8.1 ld built for i386-*-aout, just to see what it would do (which is nothing.) I was also hoping that there might be enough latent similarity in the sources that I might be able to find something by looking at source diffs, but that was a hopeless idea too. The default wine build uses -g in its CFLAGS by default. I'm rebuilding now to see if it'll link when built without -g. Naturally things like the X servers link okay when they're not built fully debuggable, and they link okay too when a few modules are compiled with debugging, so I sort of expect wine will link too without -g. Possibly somebody who's intimately familiar with ld internals might be able to solve this in a twinkling of an eye? The rebuild has just completed and it links fine when built without -g. -- Kaleb S. KEITHLEY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34C1C08A.59E2B600>