[Top][All Lists]
[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