Re: Issues w/ "relink" and cross-compilation

[Thierry Reding]

* Philip Prindeville wrote:
> On 7/11/10 3:29 AM, Ralf Wildenhues wrote:
> >Hello Philip,
> >
> >thanks for the reports.
> >
> >* Philip Prindeville wrote on Sun, Jul 11, 2010 at 02:38:28AM CEST:
> >>The problem is that a lot of projects that we use in turn use
> >>libtool (and not always terribly up-to-date versions of it),
> >this is something I'm afraid you need to take up with the projects.
> >
> >>and
> >>what seems to happen is that the relink stage uses -L/usr/lib by
> >>default, even when cross-compiling.
> >This is a bug in libtool.  I could argue about calling it a limitation,
> >but that doesn't really matter.
> >
> >>There's probably a really simple trick to getting this not to happen,
> >>but it's not obvious to me.  Also, it would be nice if libtool figured
> >>out the need to do this on its own (i.e. figure out that it's
> >>cross-compiling and that -Lxxx for any host libraries shouldn't be
> >>included).
> >>
> >>Can someone walk me through the workaround?
> >I'm not sure there is a general workaround.  For some setups it helps to
> >(temporarily) remove the .la files of the libraries relinked against.
> >
> >I don't really have the time to look into this right now (and I expect
> >it to be at least a little bigger project), but here's what you (and
> >others) can do to help: post small reproducible examples, ideally as
> >portable as possible, and ideally as XFAILing testsuite additions
> >against tests/destdir.at so that it is clear what it is that is to be
> >fixed.
> >
> >If you are not at ease with Autotest, a small shell script that creates
> >the necessary files and invokes libtool in the way that exposes the
> >bug(s) is fine, too.  It's just that IIRC, there were a lot more than
> >just one detail to get right here, some quite debatable because they
> >don't apply in all situations, and I think we should start by collecting
> >setups that we think ought to work.
> >
> >One complication when writing tests for this is that tests shouldn't
> >mess with system directories like /usr/lib or /usr/local/lib but OTOH
> >libtool treats directories listed in sys_lib_search_path_spec and
> >sys_lib_dlsearch_path_spec special.  It might be necessary to use a
> >munged libtool script (similar to tests/install.at and others) that
> >adds entries to these below the build tree so we can play with them.
> >(Of course the test then needs to ensure that the link editor and/or
> >runtime linker really searches these directories.)
> >
> >These comments of course all hold for the --sysroot stuff as well, which
> >is in a similar category of issues.
> >
> >Please note that nontrivial additions need copyright assignment (ping me
> >and I'll send you the form off-list).
> >
> >If somebody has done the work of searching for proposed patches for
> >these issues (IIRC there are a couple floating around at least in some
> >distros) then posting links would be a good thing.
> >
> >Thanks,
> >Ralf
> 
> I don't think I have the time or the expertise to come up with
> tests, etc. though I can certainly test a patch if anyone has one to
> send me.
> 
> Note that we're also using --sysroot when compiling/linking.

In that case you may be interested in the following patch. I use it to build
net-snmp 5.5 (since you mentioned it). It is basically a backport of the
sysroot support patch I posted earlier to the libtool-patches mailing list.

One thing I haven't tested is actually building against installed .la files.
I usually have a post-build hook that removes those files so depending
packages link against the .so instead. This seems to work better in sysroot
environments, but as Ralf pointed out already is probably not the best way to
go. If time allows I will try to get this to work with installed .la files as
well.

Cheers,
Thierry

signature.asc
Description: Digital signature