CVS commit messages

[Nick Hudson]

Hello,

Since the cvs server has move I no longer seem to get commit messages.
Has something gone wrong or am I supposed to do something different.

Nick
-- 
aka [EMAIL PROTECTED], [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: lib*.so symlink && patches

[Brian May]

> "Brian" == Brian May <[EMAIL PROTECTED]> writes:

Brian>  /usr/lib/libz.so -> libz.so.1.1.3 /usr/lib/libz.la ->
Brian> libz.la.1.1.3 /usr/lib/libz.so.1 -> libz.so.1.1.3
Brian> /usr/lib/libz.so.1.1.3 /usr/lib/libz.la.1.1.3

Me and my big mouth. I went to implement the code for this, but found
it is already done ;-).

Here is the first version of a patch (apply to CVS version of libtool
1.4) which seems to fix the interdependency problem I complained about
earlier. I didn't find it easy to find the correct spot to edit, but
it seems to work fine.

This patch means that libtool relies on Linux to keep track of
interdependencies, instead of trying to manage it itself (with serious
limitations).

This seems to fix all the problems I have bought up recently, except
the *.la issue (which I don't consider as important, yet).

I have labelled a few things with !FIXME! - these are parts which I
think could be done better, but I haven't done either because my
solution would require looking up information from the *.la file, and
I am not really familiar with the best way to do that.

Any questions, please ask.



diff -ruN libtool-1.3c-old/ltmain.in libtool-1.3c/ltmain.in
--- libtool-1.3c-old/ltmain.in  Mon Feb  5 09:51:14 2001
+++ libtool-1.3c/ltmain.in  Mon Feb  5 12:23:26 2001
@@ -1537,6 +1537,30 @@
*) . ./$lib ;;
esac
 
+   relink_dependency_libs="$dependency_libs";
+   case "$version_type" in
+   linux)
+ # Linux already supports dependencies internally, so
+ # we don't have to do it ourselves.
+
+ # we only need to keep track of non-installed dependancies
+ # for link time, this is so the linker can find
+ # the library (!FIXME! we should use probably use rpath instead)
+ tmp_libs=
+ for deplib in $dependency_libs; do
+   case "$deplib" in
+   # !FIXME! Could *.la files refer to installed libraries?
+   -l*) deplib=""
+   esac
+   tmp_libs="$tmp_libs $deplib"
+ done
+ dependency_libs="$tmp_libs"
+
+ # At relink time, all dependancies are done for us.
+ relink_dependency_libs="";
+ ;;
+   esac
+
if test "$linkmode,$pass" = "lib,link" ||
   test "$linkmode,$pass" = "prog,scan" ||
   { test $linkmode != prog && test $linkmode != lib; }; then
@@ -3760,7 +3784,7 @@
output="$output_objdir/$outputname"i
# Replace all uninstalled libtool libraries with the installed ones
newdependency_libs=
-   for deplib in $dependency_libs; do
+   for deplib in $relink_dependency_libs; do
  case "$deplib" in
  *.la)
name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'`


-- 
Brian May <[EMAIL PROTECTED]>

Re: lib*.so symlink

[Brian May]

> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:

Alexandre> If libx is a module, that's unfortunately true: you
Alexandre> really can't have them both installed at the same time.
Alexandre> You can only have one .la file at a time, and that's
Alexandre> all lt_dlopen will look for.  It doesn't support
Alexandre> versioning.  Maybe it should?  `lt_versioned_dlopen
Alexandre> (libname, current, revision, age)' sounds like a good
Alexandre> addition to libltdl.  Then, it would make a lot of
Alexandre> sense to install versioned copies of libx.la modules.
Alexandre> The down side is that we'd have to duplicate the
Alexandre> versioning code in libltdl :-( But this looks promising
Alexandre> to me.  Any takers?

If nobody else wants to look at this, I will, after I am satisfied the
previous problems have been fixed (with regards to interlibrary
dependencies).
-- 
Brian May <[EMAIL PROTECTED]>

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool