[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making shared libraries (DLLs) on Windows: -no-undefined

From: Simon Richter
Subject: Re: Making shared libraries (DLLs) on Windows: -no-undefined
Date: Tue, 01 May 2007 12:38:58 +0200
User-agent: IceDove (X11/20070329)


John Brown wrote:

> I gather that on Linux, you *can* create a shared library with undefined 
> symbols.


> 1) Why would anyone do that intentionally?

To link against another library, or to import a symbol defined by the
main program or a library loaded by the main program before. The latter
is heavily discouraged of course, as it is not portable; still a lot of
people do this in their plugin interfaces.

> 2) Assuming that it was a mistake, could it happen silently?

Yes, unless -no-undefined is in place.

> 3) What are the consequences?

Depending on whether the dynamic linker is in lazy or proactive mode,
the program is terminated when the undefined symbol is first referenced
or when the library is loaded.

Library imports happen quite different on PE platforms, rather than
implicitly through the dynamic linker tables in the objects, there has
to be glue code that explicitly looks up the symbol. Presence of
undefined symbols in a PE object simply means that you forgot to mark a
place where the symbol is referenced as requiring glue code
("__declspec(dllimport)"). Also, IIRC this is only possible for C
functions with stdcall ABI (I believe there to be some kludge in Windows
that adjusts the stack for you, but I'm not sure whether that applies to
WNDPROC functions only).

If you set "-no-undefined", you are basically saying that your library
does not reference any symbols from objects not listed on the linker
command line, on either platform. As ELF does not care, but PE does,
libtool asks you to state that your code is safe for linking into a PE
shared object.

Hope this helps,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]