libtool-patches
[Top][All Lists]
Advanced

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

RE: hppa-hpux DESTDIR support.


From: Duft Markus
Subject: RE: hppa-hpux DESTDIR support.
Date: Tue, 26 Aug 2008 08:08:41 +0200

> 
> Markus Duft wrote:
> > Hi
> >
> > I'm working (together with haubi) on getting DESTDIR support for our
> > hppa-hpux boxes into libtool. I now have it working, and a first
> patch
> > (which of course breaks some other things - I know that :( ), and
> wanted to
> > ask what you think about this.
> >
> > I'm adding +s to every link line. But because I add it through the
> rpath
> > spec thing, it is only there if a runpath is encoded. I tried with a
> dummy
> > runpath, added in ltmain.sh (which works ok) but that's just way too
> ugly :)
> >
> > Any ideas how I could get this a little better? Maybe another
> location to
> > add the +s?
> 
> archive_cmds?
> 
> But as far as I am aware, +s does not actually stop the -L paths from
> being encoded into the output, so you still end up with, for example:
> % chatr libfoo.sl
> libfoo.sl:
>          shared library
>          shared library dynamic path search:
>              SHLIB_PATH     enabled   first
>              embedded path  enabled   second  /opt/tmp
>          internal name:
>              libfoo.sl
>          shared library list:
>              dynamic   ../tmp/libbar.sl
>          shared vtable support disabled
> [snip]
> 
> Although a quick test running with tusc shows that the dynamic linker
> does search for libbar at ../tmp/libbar.sl last.

Yeah, right, -L is still hardcoded, so the hardcode_minusL _should_ be
yes as it was, but I can't get DESTDIR installs working with this
situation. So I cheated, and set this to yes, since the hardcoded -L is
just kind of the default path, the last resort. I ran all the test, and
get the same results as without my patch, _except_ - of course - for the
hardcode.test, which reports the hardcode_minusL setting wrong... (as
far as I remember I had to set hardcode_minusL to false to allow for
immediate hardcoding and thus fast_install=yes which in turn was somehow
relevant to DESTDIR installs... phew...)

But anyway, for me right now small side effects or very special
special-cases would not matter that much. It would be much more
important to get DESTDIR to work. However it would still be more than
cool to get DESTDIR support in upstream libtool, without having to apply
patches, that the authors don't like :)

Any suggestions on how to make it differently would be appreciated.

Cheers, Markus

> 
> Peter
> --
> Peter O'Gorman
> http://pogma.com
> 





reply via email to

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