[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mingw install directory for shared lib
From: |
Duft Markus |
Subject: |
RE: mingw install directory for shared lib |
Date: |
Thu, 10 Jan 2008 08:07:29 +0100 |
Bob Friesenhahn <mailto:address@hidden> 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.
Ok, i agree here.
>
>> 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. 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.
I wrote some routines to support runpaths on windows, so i install all
my libs in the lib directory ;) Also all my executables and libraries
built with parity are LD_LIBRARY_PATH aware... So i can use full UNIX
like semantics on windows, without any costs (except writing parity
before, which of corse costed lots of nerves...)
>
> 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).
When thinking of the default windows behaviour, i agree here too.
Markus
>
> Bob
> ======================================
> Bob Friesenhahn
> address@hidden,
> http://www.simplesystems.org/users/bfriesen/ GraphicsMagick
> Maintainer, http://www.GraphicsMagick.org/
--
19. - 21. Februar 2008
Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland
Halle 6, Stand 527
23. - 27. Februar 2008
MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland
Halle 6, Stand C50
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz