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.
>>>
>>> +...@item -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
