On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin: PR> > I have no idea whether -no-undefined is supposed to work like this but in PR> > any case it seems to me that it's perfectly useless right now. It's not PR> > checked at all under normal Unix systems so it can't be used to ensure that PR> > a shared library actually doesn't have any undefined symbols and so could PR> > be created under Windows too. And it must be always specified under PR> > Windows as otherwise DLL are never created at all. PR> PR> If you really are targeting Windows (or some other platform which needs PR> -no-undefined to build libtool libraries) then you really do get a failure PR> if there are undefined symbols. Yes but *only* if you had "-no-undefined" in your Makefile.am. If you do not specify "-no-undefined", you practically silently (not quite as it does output "libtool: link: warning: undefined symbols not allowed in $host shared libraries" but this is very easy to miss) get a static library instead, whether there are any undefined symbols or not. This is even worse than the original problem that I had because at least you had a big fat warning with plenty of asterisks in that case because there was another problem in that case. But if all goes perfectly well you still never get a shared library without "no-undefined". Even if you specified --disable-static as you did in my example (although IMO even without it silently creating static library when a shared one was requested is wrong). Am I the only one to think that this behaviour is singularly unhelpful? PR> Quoting the docs for the libtool -no-undefined option: ... PR> I.e. no mention of any actual check if there were any undefined PR> symbols. I agree that the current behaviour conforms to documentation. I just think it's pretty bad and I dare say that I'm not alone to misunderstand it because of expecting something useful from this option. PR> However, I agree that it is awkward. If this was done today, with PR> no backwards compatibility in mind, I'd say that -no-undefined should PR> be the default and any packages that truly needed undefined symbols PR> should somehow declare that instead, since that is more of a special PR> case (IMHO). But it is as it is. I continue to believe that it's much worse than awkward under Windows. Libtool should try to create DLLs there and fail if it doesn't work. Not even trying is the worst possible solution. For me the ideal behaviour would be to try to link a DLL and stop with an error if it doesn't work but according to the beginning of this thread, this is not acceptable by default. So I can only propose: 1. At least do this when --disable-static is specified. 2. Try to link as DLL in any case (well, unless --disable-shared was used) and only fall back to static linking if it actually failed instead of giving up in advance just because -no-undefined wasn't used. I probably could hack libtool to do (1) but I'm not sure I could do (2) which is, IMHO, even more important. Any comments? VZ
pgpQv8Wb5Takd.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool