Charles Wilson wrote:
> So, here's the revised function (w/o the varname uglification):
> *) func_dirname $tlibdir
> tlibdir=${func_dirname_result}
> if test x$tlibdir = x ; then
># Have to descend all the way to the root!
>func_relative_path_result
Peter Rosin wrote:
> Den 2009-08-11 08:50 skrev Dave Korn:
>> Peter Rosin wrote:
>>
>>> I think the new file tests/win32.at has a too generic name. And what if
>>> some non-win32 platform needs this? I think the test should be named
>>> tests/bindir.at (or inst-bindir.at) since that is what is test
Den 2009-08-11 08:50 skrev Dave Korn:
Peter Rosin wrote:
I think the new file tests/win32.at has a too generic name. And what if
some non-win32 platform needs this? I think the test should be named
tests/bindir.at (or inst-bindir.at) since that is what is tested.
How about pe-dll.at?
That
Peter Rosin wrote:
> I think the new file tests/win32.at has a too generic name. And what if
> some non-win32 platform needs this? I think the test should be named
> tests/bindir.at (or inst-bindir.at) since that is what is tested.
How about pe-dll.at?
> You also enable the code in ltmain for
Den 2009-08-11 07:42 skrev Dave Korn:
Well, I did really want to make it a test of nothing other than the -bindir
functionality, in fact it's more or less just a test of the corner cases for
func_relative_path! Using -rpath seems to work as far as supplying an input
value for $install_libdir a
Dave Korn wrote:
> Well, I did really want to make it a test of nothing other than the -bindir
> functionality, in fact it's more or less just a test of the corner cases for
> func_relative_path! Using -rpath seems to work as far as supplying an input
> value for $install_libdir and that's all I
Charles Wilson wrote:
> [ snip ]
Thanks for all the shell portability advice, it's pretty specialised stuff
that I don't know all about; I'll incorporate your changes into the respin when
I add the docs.
> I'm not sure "-rpath" is the right way to test, here. I know you're
> trying to avoid do
Dave Korn wrote:
> [ Please Cc me on replies, I'm not subbed up to list. ]
> Windows DLLs, unlike Linux DSOs, have to live in the bin directory (or
> elsewhere on $PATH), not the lib dir. Libtool handles this at --link time by
> setting the dlname in the generated .la file to a relative path
> "