* Dave Korn wrote on Fri, Aug 14, 2009 at 04:30:27AM CEST:
> Ralf Wildenhues wrote:
>
> > But in this particular case, I would argue that either you look at the
> > libtool variables shlibpath_var and hardcode_action for "PATH" and
> > "unsupported".
>
> On Cygwin, $hardcode_action = "immedia
Ralf Wildenhues wrote:
> But in this particular case, I would argue that either you look at the
> libtool variables shlibpath_var and hardcode_action for "PATH" and
> "unsupported".
On Cygwin, $hardcode_action = "immediate" in the generated libtool script.
Did you perhaps mean $hardcode_shlib
Ralf Wildenhues wrote:
> Seems ok. Thanks for persevering.
NP :)
> OK. Well, can we compromise on _also_ having an executability test?
> There are always so many things that can go wrong for execution, that it
> is nonetheless useful to try that out, and for that, to have an
> executable tha
* Dave Korn wrote on Thu, Aug 13, 2009 at 09:19:49PM CEST:
> Ralf Wildenhues wrote:
>
> >> I can rename it and adjust the tests so they run on all platforms, but
> >> make
> >> sure the library /doesn't/ get installed to bindir on non-PE platforms.
> >> Ok?
> >
> > Why would that additional
Tim Rice wrote:
> On Thu, 13 Aug 2009, Dave Korn wrote:
>
>> Re that, BTW: can I use shell array variables portably? I'm guessing not,
>> but it would simplify the design slightly if there was a way.
>
> No, array variables are not portable.
>
Sheer optimisim on my part. Thanks for the r
On Thu, 13 Aug 2009, Dave Korn wrote:
> Re that, BTW: can I use shell array variables portably? I'm guessing not,
> but it would simplify the design slightly if there was a way.
No, array variables are not portable.
--
Tim RiceMultitalents(707) 887-1469
t.
Dave Korn wrote:
> +# func_relative_path libdir bindir
>
gnulib-tool has a function func_relativize. Can we just reuse that
(and make it fast)?
>
>> Sure. However, if you want something that works with ../, then the
>> gnulib-tool code is worth looking at. Just a suggestion, you
Ralf Wildenhues wrote:
> Yeah, I was merely arguing for the testsuite file name; sorry for the
> confusion.
NP. Renamed to bindir.at.
>> I can rename it and adjust the tests so they run on all platforms, but make
>> sure the library /doesn't/ get installed to bindir on non-PE platforms. Ok
Hi Dave,
* Dave Korn wrote on Thu, Aug 13, 2009 at 04:10:11PM CEST:
> Ralf Wildenhues wrote:
> > * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
> >> Well, the bindir option exists only to support PE DLLs,
> >
> > Bzzt. First error. If libtool provides -bindir, then it should accep
Peter Rosin wrote:
> Missed this before, sorry. But since it is a well known fact that
> exporting variables from libraries are bad and should be avoioded,
> can we please stop adding more of that practice to the test suite?
> There is enough of it already and in case it fails, other failures
> mi
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
Ralf Wildenhues wrote:
> Hello Dave,
>
> * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
>> Well, the bindir option exists only to support PE DLLs,
>
> Bzzt. First error. If libtool provides -bindir, then it should accept
> it on every system, [ ... ] Of course on non-PE
> systems
* 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.@: n
13 matches
Mail list logo
