[Top][All Lists]

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

Re: MSW DLLs support in libtool

From: Evgeny Grin
Subject: Re: MSW DLLs support in libtool
Date: Wed, 10 Feb 2016 23:23:36 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Hash: SHA256

On 10.02.2016 18:23, Nick Bowler wrote:
> Libtool will transparently handles this, by not building shared
> libraries when it cannot do so.  The idea is that packages can
> still be useful without shared library support.  In my experience,
> this works very well.
I my experience, this works not really well.
If set of .dlls are prepared for some app then you'll get error only
when compiling main application, not set of libs. This is really
confusing, because all libs were created successfully (not actually,
because libtool built static instead of shared and do not report error).
This is good for some one-shot testing of proof-of-concept, but really
very bad for production.
If package is configured with some (currently not existing) option
"--enable-any-usable-form" it's OK to fallback to static even if it
wasn't requested.
But without it, this behaviour is a bad thing. Currently erroneously
built packages can be published as good packages during automated
rebuild process because even running test suite will not detect any error.
Because of it, I saw advises like: "I don't know why .dll is no created
because make finished without any error. Just go to src/somedir and run
dlltoll with *.o. This will create usable .dll."

> The -no-undefined option is a signal to libtool: "This library is
> compatible with systems that don't support undefined symbols in shared
> libraries".  It affects libtool's decision on whether or not a shared
> library is possible.
We signalled this already by LT_INIT([win32-dll]). Why we need to signal
this second time?

- -- 
Best Wishes,
Evgeny Grin
Version: GnuPG v2


reply via email to

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