Subject: Bad linker behaviour
From: [email-masked] (Jon Thackray)

6 Oct 1997 09:54:22 -0700
Message-ID: <[email-masked]>
References: <[email-masked]>
To: [email-masked]

Jon Thackray writes:
 > I have to assume the following behaviour is deliberate on the part of
 > the linker. Can it be turned off? What's the purpose of it? It's bad
 > news as far as I'm concerned, as it inhibits me from providing symbols
 > like free from other dlls (I get a message about can't find
 > _imp(double, long float, ...)() which is where I started). Globally
 > exchanging aa for bb in the program below allows a correct no errors
 > link.
 > 
 > 	.text
 > 	.global	__imp__bb
 > _bb:	jmp	*__imp__bb
 > __imp_bb:	ret
 > 
 > bash$ as -o poo.o poo.s
 > bash$ ld -o poo.dll --dll poo.o -e _bb
 > poo.o(.text+0x2):fake: undefined reference to `_imp(bool, bool)'

Ah well, it turns out that this is caused by C++ attempted name
mangling, and only happens in the case where the symbols can't be
matched (which is the case in my example above, although it wasn't
meant to be). So, the end result is that for symbols which get name
mangled like this, the error messages from ld are rubbish. Is there
any way of getting ld to give the real error message, instead of the
message after the name mangling?
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".