Bug#960469: libtool: for a shared library, -L. -lfoo works but libfoo.so is ignored

2020-05-15 Thread Nicolas Boulenguez
Package: src:libtool
Followup-For: Bug #960469

Hello.

An improved reproducer is attached. The patch just copies other
portions of the code and requires competent review.  On my machine,
* sh reproducer
  fails and demonstrates the problem.
* sh reproducer check_reproducer
  succeeds, so the reproducer seems minimal.
* sh reproducer check_fix
  succeeds, so the attached patch seems basically correct.
* (echo draft960469.diff >> debian/patches/series) && debian/rules build
  passes all non-skipped tests.
Do you see other things that I can check before forwarding it to
upstream as described at [1]?

Thanks.

[1] https://www.gnu.org/software/libtool/manual/libtool.html#Reporting-bugs
Description: allow libfoo.so as argument when linking a shared library
 This already works for programs, and is recommended instead of the
 ambiguous -L...  /-lfoo.
Bug-Debian: https://bugs.debian.org/960469
Author: Nicolas Boulenguez 

--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5517,6 +5517,13 @@
 	continue
 	;;
 
+  *.so)
+	# An explicit path to a shared library.
+	func_append deplibs " $arg"
+	func_append old_deplibs " $arg"
+	continue
+	;;
+
   *.la)
 	# A libtool-controlled library.
 
@@ -5871,6 +5878,16 @@
 	  func_resolve_sysroot "$deplib"
 	  lib=$func_resolve_sysroot_result
 	  ;;
+	*.so)
+	  # FIXME: linkmode=prog copies .so arguments without this stanza. Duplicate code?
+	  if test lib = "$linkmode"; then
+	deplibs="$deplib $deplibs"
+	test lib = "$linkmode" && newdependency_libs="$deplib $newdependency_libs"
+	  elif test prog != "$linkmode"; then
+	func_warning "shared library '$deplib' ignored for archive/object"
+	  fi
+	  continue
+	  ;;
 	*.$libext)
 	  if test conv = "$pass"; then
 	deplibs="$deplib $deplibs"
#!/bin/sh
set -Cefu

cat > hello.c <
void hello (void) {
  printf ("If you are reading this, all probably went OK.\n");
}
EOF

cat > direct.c < main.c < configure.ac < Makefile.am <> Makefile.am
elif test $# = 1 && test $1 = check_reproducer; then
# Check that all the rest of the build system works.
echo 'libdirect_la_LIBADD = -L. -l:libhello.so'  >> Makefile.am
echo 'EXTRA_libdirect_la_DEPENDENCIES = libhello.so' >> Makefile.am
elif test $# = 1 && test $1 = check_fix; then
echo 'libdirect_la_LIBADD = libhello.so' >> Makefile.am
check_fix=1
else
echo 'Wrong arguments'
exit 1
fi

autoreconf -i
./configure
if test $check_fix = 1; then
patch -p2 libtool draft960469.diff
fi
# --no-undefined forces the script to stop at the interesting lines.
# Without it, libtool would fail later when trying to link main.o.
make CFLAGS= DEFS= LDFLAGS=-Wl,--no-undefined
LD_LIBRARY_PATH=. ./main


Bug#960469: libtool: for a shared library, -L. -lfoo works but libfoo.so is ignored

2020-05-12 Thread Nicolas Boulenguez
Source: libtool
Version: 2.4.6-14
Severity: normal

Hello.

When linking a shared library against another uninstalled shared
library missing libtool support,
  -L. -lfoo  -L. -l:libfoo.so  libfoo.so
should be equivalent.

https://www.gnu.org/software/libtool/manual/libtool.html#FOOT2 and
https://www.gnu.org/software/automake/manual/automake.html#Linking
both recommend the third form because it is less ambiguous, but
libtool ignores it.

This results in the library containing undefined symbols, or an
immediate failure with --no-undefined.

A reproducer is attached.
#!/bin/sh
set -Cefu

cat > indirect.c <
void indirect (void) {
  printf ("If you are reading this, all probably went OK.\n");
}
EOF

cat > direct.c < main.c < configure.ac < Makefile.am <