Re: help: disabling relinking stupidity in libtool

[Ari Pollak <ari@debian.org>]

I suppose I could add that to the following in debian/rules which makes 
libtool not use -rpath:

  sed < libtool > libtool-2 \
    -e 's/^hardcode_libdir_flag_spec.*$$/hardcode_libdir_flag_spec=" 
-D__LIBTOOL_IS_A_FOOL__ "/' \
    -e '/^archive_cmds="/s/"$$/ \\$$deplibs"/'
    mv libtool-2 libtool
    chmod 755 libtool

Thanks, I'll try it out.

Matthew Garrett wrote:
> Ari Pollack wrote:
>
>
> > So anyway, my question is this - is it at all possible to simply get 
> > libtool not to relink when installing, or else solve the problem some 
> > other way? The only alternative would be to copy the originally built 
> > shared libries manually, but that's really ugly.
>
>
> I have the following in the configure.in for one of my projects - it
> needs to be able to cross-compile, and libtool kept trying to link x86
> libraries into my ARM code because there happened to be a library of
> that name in /usr/lib. Sigh. (I actually gave up on libtool in the end
> because it refuses to support linking .a files into dynamic libraries as
> it's not portable, despite me only ever needing this part of the build
> to work on Linux. I /could/ rewrite my entire build system to do things
> the libtool way, but instead I decided to just do stuff by hand :) )
>
> AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE)
> test -f libtool.old || (mv libtool libtool.old && cp libtool.old
> libtool)
> sed -e s/^hardcode_direct.*$/hardcode_direct=yes/g libtool | \
> sed -e s/^hardcode_minus_L.*$/hardcode_minus_L=yes/g | \
> sed -e s/^hardcode_shlibpath_var.*$/hardcode_shlibpath_var=no/g >libtool.new    
> mv libtool.new libtool
>
> Doubtless this breaks stuff somewhere else, but it seems to have the
> desired effect...