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

Re: help: disabling relinking stupidity in libtool

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
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...

Reply to: