There are probably other bad bugs in there, this code is a textbook example
of how NOT to write code if you want it to work.
Between the gnu style that obfuscate the stuff, the various thingies added
"just in case", the misuse of autoconf results, and the really high
abstraction level together with long functions and internal concepts, how
can anyone make sense of this code ? (short answer: it doesn't make actual
sense).
Also, no cookies for the gnu guys who, along with an important bug-fix,
manage *again* to push out 10000+ lines of useless diff thanks to a change
in automake/autoconf itself.
We don't need to make fun of Windows and its security, the GNU project
manages to produce as many problems on its own...
When will they learn secure practices ? I would bet "not this century",
but then I probably won't be around to collect the bet...
This used to be needed but with the current libtool it breaks
the library order in some cases (including xenocara) for static
only archictectures.
ok naddy@.
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
