libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed


From: Dave Korn
Subject: Re: [PATCH, take 3][cygwin|mingw] Control where win32 DLLs get installed.
Date: Thu, 13 Aug 2009 15:13:17 +0100
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Thu, Aug 13, 2009 at 08:23:22AM CEST:
>> * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
>>> --- a/doc/libtool.texi
>>> +++ b/doc/libtool.texi
>>> @@ -1376,6 +1376,15 @@ Tries to avoid versioning (@pxref{Versioning}) for 
>>> libraries and modules,
>>>  i.e.@: no version information is stored and no symbolic links are created.
>>>  If the platform requires versioning, this option has no effect.
>>>  
>>> address@hidden -bindir
>>> +When linking a DLL for Windows or another PE platform, this option tells
>> What does this have to do with PE?  All this is about is that there is
>> no real, independent $shlibpath_var beside PATH.
> 
> Erm, what I meant was that: this system provides no way to hard-code
> library paths into executables, and also has no $shlibpath_var
> independent of the PATH variable.  Sorry about that.

  Ah, see what you mean now; any other system with those properties would need
to have the libraries installed into a bindir where they could be found.  Do
you know of any such systems off the top of your head?

> You don't test paths with a '../' component in it.  I thus assume they
> won't work with your implementation (they work with gnulib-tool's).
> These components often occur within GCC (haven't checked whether for
> your particular situation, but I'd wonder why they shouldn't).

  Good point.  I'll add some and see what happens and fix any bugs arising
before I post the respin.  I'd better check for './' components too.

    cheers,
      DaveK




reply via email to

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