[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: |
Ralf Wildenhues |
Subject: |
Re: Making shared libraries (DLLs) on Windows: -no-undefined |
Date: |
Tue, 1 May 2007 10:02:01 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* Christian Biesinger wrote on Mon, Apr 30, 2007 at 10:40:40PM CEST:
> Brian Dessent wrote:
> >So yes, you need to either use -no-undefined unconditionally, or
> >conditionalized on PE targets.
>
> What's the point of doing this only on PE targets? Surely the library
> will either have undefined symbols or not, independent of target... (and
> note that Windows is not the only platform that needs -no-undefined for
> shared libraries)
There are/were systems where libtool would use (the equivalent of)
-Wl,-z -Wl,defs
but where this would hit issues with system libraries. Compare for
example this comment about some SCO systems, from libtool.m4, which
indicates such a situation (before Libtool changed not to use -z defs
there):
# Note: We can NOT use -z defs as we might desire, because we do not
# link with -lc, and that would cause any symbols used from libc to
# always be unresolved, which means just about no library would
# ever link correctly. If we're not using GNU ld we use -z text
# though, which does catch some bad symbols but isn't as heavy-handed
# as -z defs.
Generally I think you should be able to just use it everywhere. The
Libtool testsuite uses it throughout and I cannot remember a test
failure due to it. I'm however not sure whether there was an issue with
C++ code some time ago (so this data point may be FUD; sorry for not
investigating now).
Hope that helps.
Cheers,
Ralf
- Re: Making shared libraries (DLLs) on Windows: -no-undefined,
Ralf Wildenhues <=