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: 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





reply via email to

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