libtool
[Top][All Lists]
Advanced

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

Re: mingw install directory for shared lib


From: Bob Rossi
Subject: Re: mingw install directory for shared lib
Date: Wed, 09 Jan 2008 11:54:33 -0500
User-agent: Mutt/1.5.15+20070412 (2007-04-11)

On Wed, Jan 09, 2008 at 10:41:17AM -0600, Bob Friesenhahn wrote:
> On Wed, 9 Jan 2008, Duft Markus wrote:
>
>> Bob Friesenhahn <> wrote:
>>> On Tue, 8 Jan 2008, Ralf Wildenhues wrote:
>>>>
>>>> General question before fixing this: on w32, should even plugins have
>>>> their DLLs go to $bindir?
>>
>> Yes, i'd agree to this... ;o) If you try to load a library by yourself,
>> you will have to know what you're doing. If the DLL is linked to the
>> executable, you have no (easy) way to influence what is done by the
>> loader...
>
> Modules should not be linked with an executable.  That would surely be bad 
> design and should not be supported.  There should be no need to load a 
> module by yourself since libtool offers libltdl which does it for you by 
> requesting to load the associated .la file. Regardless, loading modules 
> directly is trivially easy under Windows.

Aggreed.

>> Of course there may still be problems if there are dependencies between
>> plugins, that are installed in different directories, since loading one
>> plugin will load all libraries this dll is linked to. If those are
>> plugins themselves, they will have to be in PATH to be found (or in the
>> same directory, etc.). The easiest solution is using parity ;) but thats
>> self-advertisement again, sorry...
>
> There should be no dependencies between plugins.  

I don't know. That sentence goes a little to far really. When pcre is
built on windows, it creates two dlls. The first is the regex dll which
supports the POSIX regex functionality. The second is a C++ interface
to the first library. Therefore, the C++ interface depends on the regex
library. Do you think that's bad?

> That would surely be bad 
> design and should not be supported.  Libtool should be supporting portable 
> behavior.  If the user does not desire to implement portable behavior, then 
> there is little value to using libtool or libltdl.
>
> The portable definition for windows should be:
>
> library - Executables (usually) link directly with libraries and when the 
> library is a DLL it should be installed in the executable search path, and 
> (ideally) be in the same 'bin' directory as the dependent executables.
>
> module - Modules are only loaded via an explicit loading mechanism (e.g. 
> Windows LoadLibrary() or libltdl.  Modules may depend on libraries (see 
> above) but should not depend on other modules.  Since modules are 
> explicitly loaded, they may be installed in an application-specific lib 
> directory (just like for Unix).

Where did you get this definition? I don't know, maybe I'm wrong, I
don't have a lot of experience in this area. The pcre behavior comes
naturally out of the automake/libtool setup. On linux, this is the
natural behavior you want. When you port to windows, you get the
behavior I described above automatically.

Bob Rossi




reply via email to

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