contain the correct revision of patch-ltmain_in (thanks to CVS tag and
yours truly's stupidity)
gnome-applets,gstreamer-0.8 and gdm should be able to build correctly now
thanks to kurt@ for discovering my brain damage...
do not need it.
After discussion with matthieu, theo, naddy, and a lot of tests, that
caught up the fact that sometimes, libtool uses cp, so we let it use cp
(for now).
SHARED_LIBS+= <openbsd_version> # <original libtool version>
Those lines you can put into a port's Makefile... and so notice more
easily what the software people upstream change.
- if DESTDIR is defined, avoid relinking (relinking doesn't make sense
with the fake framework anyways).
okay brad@, `as long as it doesn't break anything'.
--tag CXX works for relink now.
--tag=disable-static/disable-shared is now independent from language tags,
thus libtool --tag=disable-static --tag CXX works.
Almost allows KDE from using libtool. Still one issue to hunt down and fix.
Okay brad@, who reminded me about updating both ltmain.in and ltmain.sh...
With `-static', only link statically against uninstalled libtool
libraries. Fixes 1.5.x regression to match documented (and actual
1.4.x) behavior.
From libtool CVS
When a library is installed, dependent on a convenience library, and it
involves relinking, the object files extracted from the convenience
library are not removed after the relink. This is a problem if you build
as non-root, install as root, then try to remove the build directory as
non-root; Clean up properly if relink fails; Change"$realname"U to
${realname}T to be consistent.
Missing backport of 2004-03-24 patch reported against MirLibtool
by Marc Matteo <marcm@lectroid.net>.
Add fully-qualified paths to temp_rpath rather than unqualified paths in order
to avoid possible errors when computing the fully-qualified path later.
rev 1.334.2.70
Do not add installed static litool libraries to convenience, they are not
convenience libraries.
From libtool CVS
Propagate a convenience library's dependency libs correctly when
it is being linked into a libtool library. Deplibs are now
propagated whether libdir is set or not.
rev 1.27
The dlpreopen pass over libraries reverses the elements in the
$deplibs list. This causes problems when the link pass tries to
find libraries when they are located in non-standard places
denoted by -L options. Due to the reversed order these -L options
occur after the libraries that need them, and they are not found:
(Un)Reverse $deplibs list at the start of the link pass in lib mode.
From libtool CVS
using -lfoo we need to find the library in the search paths
and add it's dependency_libs to the link in the conv pass so
that any libtool libs listed are correctly expanded in the
link pass.
From libtool CVS
