Re: somewhat misleading -no-undefined documentation

[Simon Josefsson]

Ralf Wildenhues  writes:

> I kinda like Simon's patch you referenced (wow, that's old!), so how
> about this patch which takes from both your suggestions?

I like it.  Thanks, this closes a long-standing libtool concern of mine.

Generally, having to use -no-undefined to get things to work on some
platforms (e.g., to get a working DLL) is somewhat obscure and seems
counter to having the default behaviour Just Work.  Is there any reason
-no-undefined cannot be the default?  Is it common for installed
libraries to have unresolved symbols at link time?  Even if it is,
couldn't libtool figure out that there aren't any external symbols, and
create the DLL when it is possible?  I may be missing some details
though.

/Simon

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] w32 and Libtool.

[Simon Josefsson]

First, thanks for working on this.  It is definitely needed in the
manual.  I have re-engineered this a couple of times already, but the
collected wisdom should be in the manual in the first place.

Peter Rosin  writes:

> #if defined _WIN32 && !defined __GNUC__
> # ifdef BUILDING_LIBFOO
> #  ifdef DLL_EXPORT
> #   define LIBFOO_SCOPE extern __declspec (dllexport)
> #  endif
> # elif defined _MSC_VER || defined DLL_EXPORT
> #  define LIBFOO_SCOPE extern __declspec (dllimport)
> # endif
> #endif
> #ifndef LIBFOO_SCOPE
> # define LIBFOO_SCOPE extern
> #endif

I think it would help to namespace clarify this, to make it clear which
CPP symbols are from the system and which are intended to be provided by
the project itself.  How about this:

#if defined _WIN32 && !defined __GNUC__
# ifdef LIBFOO_BUILDING
#  ifdef LIBFOO_DLL_EXPORT
#   define LIBFOO_SCOPE extern __declspec (dllexport)
#  endif
# elif defined _MSC_VER || defined LIBFOO_DLL_EXPORT
#  define LIBFOO_SCOPE extern __declspec (dllimport)
# endif
#endif
#ifndef LIBFOO_SCOPE
# define LIBFOO_SCOPE extern
#endif

However, I suspect people will need to adapt this block for their own
projects.

For comparison, in my projects I'm using a variant of this:

# ifndef GSASL_API
#  if defined GSASL_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
#   define GSASL_API __attribute__((__visibility__("default")))
#  elif defined GSASL_BUILDING && defined _MSC_VER && ! defined GSASL_STATIC
#   define GSASL_API __declspec(dllexport)
#  elif defined _MSC_VER && ! defined GSASL_STATIC
#   define GSASL_API __declspec(dllimport)
#  else
#   define GSASL_API
#  endif
# endif

/Simon

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] w32 and Libtool.

[Simon Josefsson]

Peter Rosin  writes:

> DLL_EXPORT comes from libtool, so it should not be changed to
> LIBFOO_DLL_EXPORT.

Right.

> And while I approve of starting with LIBFOO_ instead of BUILDING_,
> LIBFOO_BUILDING sounds very wrong as BUILDING changes from a verb to a
> noun. LIBFOO_BUILD perhaps?  Other suggestions welcome.

The shorter the better, so LIBFOO_BUILD sounds better.

>> For comparison, in my projects I'm using a variant of this:
>> 
>> # ifndef GSASL_API
>> #  if defined GSASL_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
>> #   define GSASL_API __attribute__((__visibility__("default")))
>> #  elif defined GSASL_BUILDING && defined _MSC_VER && ! defined GSASL_STATIC
>> #   define GSASL_API __declspec(dllexport)
>> #  elif defined _MSC_VER && ! defined GSASL_STATIC
>> #   define GSASL_API __declspec(dllimport)
>> #  else
>> #   define GSASL_API
>> #  endif
>> # endif
>
> I'm desperately trying to get away from having to specify (the
> equivalence of) GSASL_STATIC when consuming libraries.

This was added to permit use of MSC to build static libraries, if I
recall correctly.

Another advantage with my variant is that it is possible to provide
-DGSASL_API=foo during the build if you want to set some other attribute
on the APIs.

The first issue (i.e., MSC static builds) could be handled by the means
in the second point (i.e., project specifying -DGSASL_API="") though.
Then there would be no need for GSASL_STATIC.

Anyway, I think the block will likely need to be adapted by each
project.  I'm not trying to push for my version, just to offer it for
comparison.

/Simon

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: [RFC] w32 and Libtool.

[Simon Josefsson]

Peter Rosin  writes:

>> The first issue (i.e., MSC static builds) could be handled by the means
>> in the second point (i.e., project specifying -DGSASL_API="") though.
>> Then there would be no need for GSASL_STATIC.
>> 
>> Anyway, I think the block will likely need to be adapted by each
>> project.  I'm not trying to push for my version, just to offer it for
>> comparison.
>
> The only changes that should be needed is visibility attributes (which I
> didn't want to discuss too much in the already complex text) and the
> obvious s/LIBFOO_/LIBBAR_/ change. What other adaptations are needed?

Probably none, but as the visibility attribute change suggests, there
may be other project specific changes.

> BTW, I think it is somewhat ugly to mention HAVE_ defines in installed
> headers, but since they are hidden behind GSASL_BUILDING it's acceptable.

Yes, I agree, but haven't been able to think of a better solution.
Possibly I could add something to config.h when building the project
instead of having this in the public header file...

/Simon

___
http://lists.gnu.org/mailman/listinfo/libtool

modules have a soname?

[Simon Josefsson]

I'm tracking down why I get warnings from dpkg-shlibdeps on a package
that builds dlopen modules with libtool.  For reference, a build log is
available here:

https://buildd.debian.org/status/fetch.php?pkg=jabberd2&arch=amd64&ver=2.3.4-1%2Bb1&stamp=1446749350

According to dpkg-shlibdeps dlopen modules should not have a soname:

   "A private library (like a plugin) should not have a SONAME and
   doesn't need to be versioned."

See http://linux.die.net/man/1/dpkg-shlibdeps for more text.

However when I build the package manually I can see that libtool does
add a soname to the module:

jas@latte:~/src/jabberd2/sm$ /bin/bash ../libtool  --tag=CC   --mode=link gcc  
-g -O2 -funsigned-char -module -export-dynamic  -o mod_amp.la -rpath 
/usr/local/lib/jabberd mod_amp.lo ../subst/libsubst.la -lssl -lcrypto -lgsasl 
-ludns -lidn -lexpat -lresolv -lcrypt  -ldl -lz
libtool: link: rm -fr  .libs/mod_amp.la .libs/mod_amp.lai .libs/mod_amp.so 
.libs/mod_amp.so.0 .libs/mod_amp.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/mod_amp.o  -Wl,--whole-archive 
../subst/.libs/libsubst.a -Wl,--no-whole-archive  -lssl -lcrypto 
/usr/lib/libgsasl.so -ludns -lidn /usr/lib/x86_64-linux-gnu/libexpat.so 
-lresolv -lcrypt -ldl -lz  -O2   -Wl,-soname -Wl,mod_amp.so.0 -o 
.libs/mod_amp.so.0.0.0
libtool: link: (cd ".libs" && rm -f "mod_amp.so.0" && ln -s "mod_amp.so.0.0.0" 
"mod_amp.so.0")
libtool: link: (cd ".libs" && rm -f "mod_amp.so" && ln -s "mod_amp.so.0.0.0" 
"mod_amp.so")
libtool: link: ( cd ".libs" && rm -f "mod_amp.la" && ln -s "../mod_amp.la" 
"mod_amp.la" )
jas@latte:~/src/jabberd2/sm$

What is correct here?  Is libtool is doing the right thing in adding the
soname?

/Simon


signature.asc
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: modules have a soname?

[Simon Josefsson]

Russ Allbery  writes:

> Simon Josefsson  writes:
>
>> I'm tracking down why I get warnings from dpkg-shlibdeps on a package
>> that builds dlopen modules with libtool.  For reference, a build log is
>> available here:
>
>> https://buildd.debian.org/status/fetch.php?pkg=jabberd2&arch=amd64&ver=2.3.4-1%2Bb1&stamp=1446749350
>
>> According to dpkg-shlibdeps dlopen modules should not have a soname:
>
>>"A private library (like a plugin) should not have a SONAME and
>>doesn't need to be versioned."
>
>> See http://linux.die.net/man/1/dpkg-shlibdeps for more text.
>
>> However when I build the package manually I can see that libtool does
>> add a soname to the module:
>
> libtool adds an SONAME unless -avoid-version is passed in the libtool
> arguments.  Unless there's some use for the SONAME, it's generally best
> practice to use -avoid-version when creating plugins.

Thanks.

> In other words, this is probably an upstream Makefile issue rather than a
> problem with either libtool or dpkg-shlibdeps.

Upstream do use -avoid-version in their Makefile.am, but I just noticed
that it might not be used in all places.  I'll double check.

/Simon


signature.asc
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: modules have a soname?

[Simon Josefsson]

Simon Josefsson  writes:

>> In other words, this is probably an upstream Makefile issue rather than a
>> problem with either libtool or dpkg-shlibdeps.
>
> Upstream do use -avoid-version in their Makefile.am, but I just noticed
> that it might not be used in all places.  I'll double check.

It doesn't work even in the cases where upstream's Makefile.am uses
-avoid-version.  Libtool is still adding a -Wl,-soname:

jas@latte:~/src/jabberd2-jas/storage$ /bin/bash ../libtool  --tag=CC   
--mode=link gcc -I../c2s -I.. -g -O2 -funsigned-char -module -avoid-version  -o 
authreg_anon.la -rpath /usr/local/lib/jabberd authreg_anon.lo -lexpat -L../util 
-lssl -lcrypto -lgsasl -ludns -lidn -lexpat -lresolv -lcrypt  -ldl -lz
libtool: link: rm -fr  .libs/authreg_anon.la .libs/authreg_anon.lai 
.libs/authreg_anon.so
libtool: link: gcc -shared  -fPIC -DPIC  .libs/authreg_anon.o   -L../util -lssl 
-lcrypto /usr/lib/libgsasl.so -ludns -lidn 
/usr/lib/x86_64-linux-gnu/libexpat.so -lresolv -lcrypt -ldl -lz  -O2   
-Wl,-soname -Wl,authreg_anon.so -o .libs/authreg_anon.so
libtool: link: ( cd ".libs" && rm -f "authreg_anon.la" && ln -s 
"../authreg_anon.la" "authreg_anon.la" )
jas@latte:~/src/jabberd2-jas/storage$ 

Is this intentional, or should we start to track down how -Wl,-soname
was added and treat that as a bug?  The manual says:

'-avoid-version'
 Tries to avoid versioning (*note Versioning::) for libraries and
 modules, i.e. no version information is stored and no symbolic
 links are created.  If the platform requires versioning, this
 option has no effect.

I don't know whether libtool regards the debian/gnu/linux/elf platform
as requiring versioning or not.

This is libtool 2.4.2 from Debian, if it matters.

/Simon


signature.asc
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Building mingw32 DLLs without -no-undefined?

[Simon Josefsson]

Hi!  I'm able to build a win32 DLL of libidn using libtool and
mingw32, but it didn't work with libgsasl.  The difference was that
libidn specified a -no-undefined where as libgsasl didn't.  libgsasl
depend on libidn, so that is understandable.

`-no-undefined'
 Declare that OUTPUT-FILE does not depend on any other libraries.
 Some platforms cannot create shared libraries that depend on other
 libraries (*note Inter-library dependencies::).

Is it possible to build a DLL that depend on other libraries?

Since gsasl do depend on libidn, it seem incorrect to specify
-no-undefined in libgsasl, however, with parameter, libtool is able to
build a libgsasl DLL.  I haven't tested it though.

In libidn, libtool installed Libidn.dll, libidn.a, and libidn.dll.a.
Maybe this is just a matter of making libtool pick up a better libidn
to link with?  Currently it just use -lidn:

/bin/sh ../libtool --tag=CC --mode=link i586-mingw32msvc-gcc  -g -O2   -o 
libgsasl.la -rpath /home/jas/w32root/lib -version-info 9:8:2 
-export-symbols-regex '^(gsasl|GSASL).*' init.lo done.lo register.lo error.lo 
version.lo callback.lo property.lo supportp.lo suggest.lo listmech.lo xstart.lo 
xstep.lo xfinish.lo xcode.lo base64.lo md5pwd.lo crypto.lo saslprep.lo 
obsolete.lo ../gl/libgl.la  -L/home/jas/w32root/lib -lidn 
../external/libgsasl-external.la ../anonymous/libgsasl-anonymous.la 
../plain/libgsasl-plain.la ../login/libgsasl-login.la 
../cram-md5/libgsasl-cram_md5.la ../digest-md5/libgsasl-digest_md5.la   
../securid/libgsasl-securid.la
...

Thanks for any ideas in getting usable win32 libraries are appreciated.

Thanks,
Simon


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Building mingw32 DLLs without -no-undefined?

[Simon Josefsson]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Hi Simon,
>
> * Simon Josefsson wrote on Tue, Mar 07, 2006 at 03:15:29PM CET:
>> Hi!  I'm able to build a win32 DLL of libidn using libtool and
>> mingw32, but it didn't work with libgsasl.  The difference was that
>> libidn specified a -no-undefined where as libgsasl didn't.  libgsasl
>> depend on libidn, so that is understandable.
>
> Well, if it *specifies* that dependency, then all is well, and it should
> use `-no-undefined'.
>
>> `-no-undefined'
>>  Declare that OUTPUT-FILE does not depend on any other libraries.
>
> `any other' is supposed to mean: any you have not specified on the link
> command line.

Oh, I see.  I read it to mean what it says more literally, i.e., only
use -no-undefined if your library doesn't use any external libraries
at all.  May I suggest changing the wording here?

Thanks!

--- libtool.texi07 Mar 2006 17:18:54 +0100  1.134.2.15
+++ libtool.texi07 Mar 2006 17:43:05 +0100  
@@ -1272,9 +1272,11 @@
 used in the build tree, e.g., for testing or generating other files.
 
 @item -no-undefined
-Declare that @var{output-file} does not depend on any other libraries.
-Some platforms cannot create shared libraries that depend on other
-libraries (@pxref{Inter-library dependencies}).
+Declare that @var{output-file} does not depend on any other libraries,
+i.e., after linking it will not have any unresolved symbols.  Some
+platforms cannot create shared libraries that depend on other
+libraries (@pxref{Inter-library dependencies}), and using this
+parameter (when applicable) helps on these platforms.
 
 @item -o @var{output-file}
 Create @var{output-file} from the specified objects and libraries.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: mingw and dlls

[Simon Josefsson]

Bob Friesenhahn <[EMAIL PROTECTED]> writes:

> On Mon, 19 Feb 2007, Mike Frysinger wrote:
>
>> is it right that i expect libtool to produce .dlls for my library when
>> targetting mingw ?  if so, what sort of information should i post to track
>> down why i'm only getting a static archive ?
>>
>> ive tested libtool 1.5.22 and 1.5.23b ... during configure, the output says
>> that static and shared libs are supported for the mingw32 target and it says
>> that the detected library loading method is Win32 ...
>
> Did you use
>
> AC_LIBTOOL_WIN32_DLL
>
> or
>
> LT_INIT([win32-dll])
>
> In configure.ac to indicate that the package is prepared to build
> win32 DLLs?

Is there any reason AC_LIBTOOL_WIN32_DLL is not called from
AC_LIBTOOL?  This problem comes up rather often.  It seems sub-optimal
for libtool to require special steps for portability to a particular
platform, especially when the macro is this small:

AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
[*-*-cygwin* | *-*-mingw* | *-*-pw32*)
  AC_CHECK_TOOL(DLLTOOL, dlltool, false)
  AC_CHECK_TOOL(AS, as, false)
  AC_CHECK_TOOL(OBJDUMP, objdump, false)
  ;;
  ])
esac

> Also, are you passing '-no-undefined' to libtool via the per-library
> LDFLAGS?  This last step is vitally important.

How about adding this to the documentation:

--- libtool.texi27 Mar 2007 17:08:29 +0200  1.134.2.20
+++ libtool.texi27 Mar 2007 17:08:36 +0200  
@@ -2473,7 +2473,7 @@
 restriction is only necessary to preserve compatibility with static
 library systems and simple dynamic library systems.
 
-Some platforms, such as AIX, do not even allow you this
+Some platforms, such as AIX and Mingw32, do not even allow you this
 flexibility.  In order to build a shared library, it must be entirely
 self-contained (that is, have references only to symbols that are found
 in the @samp{.lo} files or the specified @samp{-l} libraries), and you

/Simon


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool fails to build working binary when -no-install is used

[Simon Josefsson]

On 4 apr 2007, at 00.21, Peter O'Gorman wrote:



On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:



On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:


Do I understand correctly that Darwin has no way to hardcode library
paths (other than the ones given by -install-name)?  OK to apply and
backport?  It fixes the stresstest failure exposed by my last patch.


After some experiments and a lot of man page reading on my  
powerbook, I believe this is correct.  I was rather surprised to  
not find anything like -R or -Wl,-rpath on Mac OS X, so it may be  
that I missed something.  Still, this patch is the best we can do  
without more information from Mac OS X experts.


There is no -rpath on Mac OS X 10.4 and earlier, it is, or at least  
was, I believe, a planned feature for 10.5, but plans and reality  
don't always intersect...


Right.

FWIW, I did find -dylib_file which seems relevant:

   -dylib_file install_name:file_name(32-bitonly)
  Specifies  that a dynamic shared library is in a  
different loca-
  tion than its standard location. Use this option when   
you  link
  with  a  library that is dependent on a dynamic  
library, and the
  dynamic library is in a location other than  its   
default  loca-
  tion.   install_name  specifies  the path where the  
library nor-
  mally resides.  file_name specifies the path of the  
library  you
  want to use instead.  For example, if you link to a  
library that
  depends upon the dynamic library  libsys  and  you   
have  libsys
  installed  in  a nondefault location, you would use  
this option:
  -dylib_file /lib/libsys_s.A.dylib:/me/lib/ 
libsys_s.A.dylib.


However, I cannot get it to do anything at all on my machine.  The  
hard coded path to the library seems to be the one stored inside the  
library, no matter what I supply as -dylib_file parameter when  
linking the binary.


However, after seeing this thread:

http://www.cocoabuilder.com/archive/message/cocoa/2003/12/3/868

I discovered the install_name_tool command, and it do seem to solve  
the problem:


espresso:~ jas$ cd p
espresso:~/p jas$ cat foo.c
void test (void) { puts("test"); }
espresso:~/p jas$ gcc -dynamiclib -o libfoo.dylib -install_name / 
Users/jas/libfoo.dylib foo.c

espresso:~/p jas$ cd ..
espresso:~ jas$ ls *foo*
ls: *foo*: No such file or directory
espresso:~ jas$ cd t
espresso:~/t jas$ cat main.c
int main() { test(); }
espresso:~/t jas$ gcc -o main main.c -L/Users/jas/p -lfoo - 
headerpad_max_install_name

sespresso:~/t jas$ otool -L main
main:
/Users/jas/libfoo.dylib (compatibility version 0.0.0,  
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.8)

espresso:~/t jas$ ./main
dyld: Library not loaded: /Users/jas/libfoo.dylib
  Referenced from: /Users/jas/t/./main
  Reason: image not found
Trace/BPT trap
espresso:~/t jas$ install_name_tool -change /Users/jas/libfoo.dylib / 
Users/jas/p/libfoo.dylib main

espresso:~/t jas$ otool -L mainmain:
/Users/jas/p/libfoo.dylib (compatibility version 0.0.0,  
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.8)

espresso:~/t jas$ ./main test
espresso:~/t jas$

So if you want to solve this without a wrapper, you should link the - 
no-install programs with -headerpad_max_install_name and run  
install_name_tool translating the installed name of libraries into  
whatever is the non-installed name for each shared library.
Presumably, that has to be done recursively for all shared library  
(in case there are multiple non-installed shared libraries that  
depend on each other).  And it only works for 32-bit hosts:


   -headerpad_max_install_names (32-bit only)
  Add  to  the  header  padding enough space to allow  
changing all
  dynamic shared library paths recorded in the output  
file  to  be

  changed to MAXPATHLEN in length.

/Simon



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: relinking makes libtool link to the wrong library

[Simon Josefsson]

FWIW, I have a theory that this may be caused by having -L/-l in LIBADD
variables rather than in LDFLAGS variables.  Since there are many
instances of this in various nested levels in gnutls, it will take some
time to see if this is indeed the problem.  Do you think fixing this
will solve the problem?

/Simon


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: relinking makes libtool link to the wrong library

[Simon Josefsson]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Hello Simon,
>
> * Simon Josefsson wrote on Fri, Jan 11, 2008 at 03:20:44PM CET:
>> Hi!  We have received a bug report about some parts of recent gnutls
>> (libgnutls-extra.so.26) incorrectly links to the libgnutls.so in
>> /usr/lib/ rather than in $prefix, see original report:
>
> To be able to analyze it, we need the output of
>   ../libtool --config
>
> as well as the complete output of the `libtool --mode=relink' command,
> with --debug added as first argument.  Since this output will be large,
> please gzip it before sending it to the list.

Hi Ralf!  Files attached.  Thanks for quick response.

/Simon


libtool-debug.txt.gz
Description: Binary data

# Libtool was configured on host mocca:

# Shell to use when invoking shell scripts.
SHELL="/bin/sh"

# Whether or not to build shared libraries.
build_libtool_libs=yes

# Whether or not to build static libraries.
build_old_libs=yes

# Whether or not to add -lc for building shared libraries.
build_libtool_need_lc=no

# Whether or not to disallow shared libs when runtime libs are static
allow_libtool_libs_with_static_runtimes=no

# Whether or not to optimize for fast installation.
fast_install=yes

# The host system.
host_alias=
host=i686-pc-linux-gnu
host_os=linux-gnu

# The build system.
build_alias=
build=i686-pc-linux-gnu
build_os=linux-gnu

# An echo program that does not interpret backslashes.
echo="echo"

# The archiver.
AR="ar"
AR_FLAGS="cru"

# A C compiler.
LTCC="gcc -std=gnu99"

# LTCC compiler flags.
LTCFLAGS="-g -O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign"

# A language-specific compiler.
CC="gcc -std=gnu99"

# Is the compiler the GNU C compiler?
with_gcc=yes

# An ERE matcher.
EGREP="/bin/grep -E"

# The linker used to build libraries.
LD="/usr/bin/ld"

# Whether we need hard or soft links.
LN_S="ln -s"

# A BSD-compatible nm program.
NM="/usr/bin/nm -B"

# A symbol stripping program
STRIP="strip"

# Used to examine libraries when file_magic_cmd begins "file"
MAGIC_CMD=file

# Used on cygwin: DLL creation program.
DLLTOOL="dlltool"

# Used on cygwin: object dumper.
OBJDUMP="objdump"

# Used on cygwin: assembler.
AS="as"

# The name of the directory that contains temporary libtool files.
objdir=.libs

# How to create reloadable object files.
reload_flag=" -r"
reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"

# How to pass a linker flag through the compiler.
wl="-Wl,"

# Object file suffix (normally "o").
objext="o"

# Old archive suffix (normally "a").
libext="a"

# Shared library suffix (normally ".so").
shrext_cmds='.so'

# Executable file suffix (normally "").
exeext=""

# Additional compiler flags for building library objects.
pic_flag=" -fPIC -DPIC"
pic_mode=default

# What is the maximum length of a command?
max_cmd_len=98304

# Does compiler simultaneously support -c and -o options?
compiler_c_o="yes"

# Must we lock files when doing compilation?
need_locks="no"

# Do we need the lib prefix for modules?
need_lib_prefix=no

# Do we need a version for libraries?
need_version=no

# Whether dlopen is supported.
dlopen_support=unknown

# Whether dlopen of programs is supported.
dlopen_self=unknown

# Whether dlopen of statically linked programs is supported.
dlopen_self_static=unknown

# Compiler flag to prevent dynamic linking.
link_static_flag="-static"

# Compiler flag to turn off builtin functions.
no_builtin_flag=" -fno-builtin"

# Compiler flag to allow reflexive dlopens.
export_dynamic_flag_spec="\${wl}--export-dynamic"

# Compiler flag to generate shared objects directly from archives.
whole_archive_flag_spec="\${wl}--whole-archive\$convenience 
\${wl}--no-whole-archive"

# Compiler flag to generate thread-safe objects.
thread_safe_flag_spec=""

# Library versioning type.
version_type=linux

# Format of library name prefix.
libname_spec="lib\$name"

# List of archive names.  First name is the real one, the rest are links.
# The last name is the one that the linker finds with -lNAME.
library_names_spec="\${libname}\${release}\${shared_ext}\$versuffix 
\${libname}\${release}\${shared_ext}\$major \$libname\${shared_ext}"

# The coded name of the library, if different from the real name.
soname_spec="\${libname}\${release}\${shared_ext}\$major"

# Commands used to build and install an old-style archive.
RANLIB="ranlib"
old_archive_cmds="\$AR \$AR_FLAGS \$oldlib\$oldobjs~\$RANLIB \$oldlib"
old_postinstall_cmds="chmod 644 \$oldlib~\$RANLIB \$oldlib"
old_postuninstall_cmds=""

# Create an old-style archive fr

Re: relinking makes libtool link to the wrong library

[Simon Josefsson]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Hi Simon,
>
> 0) I forgot to ask: is this libtool 1.5.24?

Yes.  From debian testing.

> 1) ../lib/libgnutls.la has dependency_libs entry that contains -L/usr/lib
> and -L/usr/local/lib, both wrongly I think.  Why is that?  To find out,
> please send `libtool --debug --mode=link' output (not relink) for the
> creation of ../lib/libgnutls.la.
>
> (I assume that your libz is in /usr/lib not /usr/local/lib.
> If that's a false assumption, then the -L/usr/local/lib would have a
> reason to be there.)

See libtool-debug2.txt.bz2 below.

I suspect /usr/lib is from libtasn1, and -L/usr/local/lib is from
libgcrypt.  Exactly how they are propagated I'm not sure.

> 2) ../lgl/liblgnu.la has dependency_libs entry that contains
> -L/usr/local/lib.  That doesn't look right either:
>
> | ++ dlname=
> | ++ library_names=
> | ++ old_library=liblgnu.a
> | ++ dependency_libs=' -L/usr/local/lib /usr/local/lib/libgcrypt.la 
> /usr/lib/libgpg-error.la'

This is from libgcrypt.la, lgl/Makefile.am:

if GL_COND_LIBTOOL
liblgnu_la_LDFLAGS += $(LTLIBGCRYPT)
endif

And from lgl/Makefile:

LTLIBGCRYPT = -L/usr/local/lib -lgcrypt -lgpg-error

Is this a gnulib bug?  I.e., should that be LIBADD?

> 3) /usr/local/lib/libgcrypt.la also contains a -L/usr/local/lib which I
> don't understand.  For now, you could try just removing it from the file.
> (That's probably where that one in ../lgl/liblgnu.la came from.)

Right.  I've removed it.  This libgcrypt is built locally from SVN.
However, I recall that I was able to reproduce this problem using the
system libgcrypt too earlier.

> 4) "-lopencdk -llzo2" don't belong in LDFLAGS, they belong in
> *_LIBADD/*_LDADD.  Put them after the ../lib-just-built-lib.la args
> for good measure.

Hm.  Where does -L belong?  Also LDFLAGS?  The -lopencdk comes
'pkg-config --libs opencdk' which output '-L/usr/local/lib -lopencdk'.
I could use pkg-config --libs-only-l and --libs-only-L but would prefer
not to.

> Quite possible that we have to play this game a bit longer still,
> so if after the above issues are fixed, libgnutls_extra still has
> -L/usr/lib early, please just send a debug output of the relink again.

Given your hints, I'll try to debug things a bit more.

Thanks,
/Simon


libtool-debug2.txt.bz2
Description: Binary data
___
http://lists.gnu.org/mailman/listinfo/libtool

relinking makes libtool link to the wrong library

[Simon Josefsson]

Hi!  We have received a bug report about some parts of recent gnutls
(libgnutls-extra.so.26) incorrectly links to the libgnutls.so in
/usr/lib/ rather than in $prefix, see original report:

http://lists.gnu.org/archive/html/gnutls-devel/2007-12/msg00038.html

To understand how this works, GnuTLS contains one core library
libgnutls.so (in lib/) and another library libgnutls-extra.so (in
libextra/).  The second library links to the former.

libextra/Makefile.am contains:

libgnutls_extra_la_LIBADD += ../lgl/liblgnu.la ../lib/libgnutls.la

The problem is easy to reproduce -- just build gnutls-2.2.0 locally on a
machine that has libgnutls.so.13 in /usr/lib -- but I don't know how to
solve it.  I'm posting some details here and hope someone can help me.

Make install in lib/ works fine, the core library is installed properly.
Libtool does not relink the libgnutls.so library.

Make install in libextra/ causes relinking to happen.  I think this is
expected, right?  The output is:

make[2]: Entering directory `/home/jas/gnutls-2.2.0/libextra'
test -z "/home/jas/gnutls-2.2.0/xxx/bin" || /bin/mkdir -p 
"/home/jas/gnutls-2.2.0/xxx/bin"
 /usr/bin/install -c 'libgnutls-extra-config' 
'/home/jas/gnutls-2.2.0/xxx/bin/libgnutls-extra-config'
test -z "/home/jas/gnutls-2.2.0/xxx/bin" || /bin/mkdir -p 
"/home/jas/gnutls-2.2.0/xxx/bin"
test -z "/home/jas/gnutls-2.2.0/xxx/lib" || /bin/mkdir -p 
"/home/jas/gnutls-2.2.0/xxx/lib"
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'libgnutls-extra.la' 
'/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.la'
libtool: install: warning: relinking `libgnutls-extra.la'
(cd /home/jas/gnutls-2.2.0/libextra; /bin/sh ../libtool  --tag=CC --mode=relink 
gcc -std=gnu99 -g -O2 -D_REENTRANT -D_THREAD_SAFE -pipe -I/usr/local/include -g 
-O2 -D_REENTRANT -D_THREAD_SAFE -Wno-pointer-sign -no-undefined -lopencdk 
-version-info 27:1:1 -llzo2 -Wl,--version-script=./libgnutls-extra.vers -o 
libgnutls-extra.la -rpath /home/jas/gnutls-2.2.0/xxx/lib gnutls_extra.lo 
gnutls_openpgp.lo gnutls_ia.lo openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la 
../lib/libgnutls.la )  
gcc -std=gnu99 -shared  .libs/gnutls_extra.o .libs/gnutls_openpgp.o 
.libs/gnutls_ia.o -Wl,--whole-archive openpgp/.libs/libgnutls_openpgp.a 
../lgl/.libs/liblgnu.a -Wl,--no-whole-archive  -Wl,--rpath 
-Wl,/home/jas/gnutls-2.2.0/xxx/lib -L/usr/lib -lopencdk -llzo2 -L/usr/local/lib 
-lgcrypt -lgpg-error -L/home/jas/gnutls-2.2.0/xxx/lib -lgnutls  
-Wl,--version-script=./libgnutls-extra.vers -Wl,-soname 
-Wl,libgnutls-extra.so.26 -o .libs/libgnutls-extra.so.26.1.1
/usr/bin/install -c .libs/libgnutls-extra.so.26.1.1T 
/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.so.26.1.1
(cd /home/jas/gnutls-2.2.0/xxx/lib && { ln -s -f libgnutls-extra.so.26.1.1 
libgnutls-extra.so.26 || { rm -f libgnutls-extra.so.26 && ln -s 
libgnutls-extra.so.26.1.1 libgnutls-extra.so.26; }; })
(cd /home/jas/gnutls-2.2.0/xxx/lib && { ln -s -f libgnutls-extra.so.26.1.1 
libgnutls-extra.so || { rm -f libgnutls-extra.so && ln -s 
libgnutls-extra.so.26.1.1 libgnutls-extra.so; }; })
/usr/bin/install -c .libs/libgnutls-extra.lai 
/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.la
/usr/bin/install -c .libs/libgnutls-extra.a 
/home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.a
chmod 644 /home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.a
ranlib /home/jas/gnutls-2.2.0/xxx/lib/libgnutls-extra.a
PATH="$PATH:/sbin" ldconfig -n /home/jas/gnutls-2.2.0/xxx/lib
--
Libraries have been installed in:
   /home/jas/gnutls-2.2.0/xxx/lib
...

The libtool command is:

/bin/sh ../libtool  --tag=CC --mode=relink gcc -std=gnu99 -g -O2 -D_REENTRANT 
-D_THREAD_SAFE -pipe -I/usr/local/include -g -O2 -D_REENTRANT -D_THREAD_SAFE 
-Wno-pointer-sign -no-undefined -lopencdk -version-info 27:1:1 -llzo2 
-Wl,--version-script=./libgnutls-extra.vers -o libgnutls-extra.la -rpath 
/home/jas/gnutls-2.2.0/xxx/lib gnutls_extra.lo gnutls_openpgp.lo gnutls_ia.lo 
openpgp/libgnutls_openpgp.la ../lgl/liblgnu.la ../lib/libgnutls.la

That looks correct to me.

The gcc output is:

gcc -std=gnu99 -shared  .libs/gnutls_extra.o .libs/gnutls_openpgp.o 
.libs/gnutls_ia.o -Wl,--whole-archive openpgp/.libs/libgnutls_openpgp.a 
../lgl/.libs/liblgnu.a -Wl,--no-whole-archive  -Wl,--rpath 
-Wl,/home/jas/gnutls-2.2.0/xxx/lib -L/usr/lib -lopencdk -llzo2 -L/usr/local/lib 
-lgcrypt -lgpg-error -L/home/jas/gnutls-2.2.0/xxx/lib -lgnutls  
-Wl,--version-script=./libgnutls-extra.vers -Wl,-soname 
-Wl,libgnutls-extra.so.26 -o .libs/libgnutls-extra.so.26.1.1

This looks wrong to me, it contains:

   -Wl,--rpath -Wl,/home/jas/gnutls-2.2.0/xxx/lib ... \
   -L/usr/lib ... \
   -L/usr/local/lib ... \
   -L/home/jas/gnutls-2.2.0/xxx/lib -lgnutls

So the final -lgnutls will pick it up from /usr/lib instead.  I think
that the -L/usr/lib is bogus, that is the default library path anyway,
so it shouldn't be needed.  But I don't think fixing that will take care
of this issue -- the command li

Re: GNU Libtool 2.1b released (alpha release)

[Simon Josefsson]

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:

> On 1 Feb 2008, at 01:06, Gary V. Vaughan wrote:
>> The Libtool Team is pleased to announce alpha release 2.1b of GNU
>> Libtool.
>
>
> With only one bug reported and fixed since Feb 1, either this is the
> most spectacularly well engineered release in the history of libtool,
> or else it is the least well tested release ever...
>
> Either way, if there are no more bugs found before Feb 10th, I plan
> to roll up 2.2 final.  If you have any projects that you're thinking
> of moving to libtool-2, please test them now so that we can fix any
> problems you encounter before the final release!!

FWIW, I re-build my stack of libraries (libidn, libtasn1, shishi, gss,
gnutls, and gsasl) and it worked smoothly.

Looking forward to the release,
/Simon


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: shared library symbol exports and versioning

[Simon Josefsson]

Bruno Haible  writes:

> Simon Josefsson wrote:
>> I won't dispute that ELF version symbol scripts are overrated because
>> they aren't portable.  But they do provide some features, and together
>> with a scheme like you suggest you get more complete cross-platform
>> versioning.
>
> ... at the cost of maintaining the same information twice. In the doc
> patch where you propose
>
> if HAVE_LD_VERSION_SCRIPT
> libfoo_la_LDFLAGS += -Wl,--version-script=$(srcdir)/libfoo.map
> else
> libfoo_la_LDFLAGS += -export-symbols $(srcdir)/libfoo.sym
> endif
>
> the maintainer has to keep both libfoo.map and libfoo.sym up-to-date,
> and similarly for doing the versioning through libfoo.map or #defines.
>
> .., except if you had a tool that generates libfoo.map from the #defines
> in the header files, and a tool that generates the libfoo.sym from libfoo.map.
>
> This rises a question regarding libtool: Could libtool also accept
> GNU ld style .map files as input for the -export-symbols option, and
> if the linker is not GNU ld, process the .map file itself, like it would
> normally process a .sym file?

Good question, something like that seems useful.

However, do you object to installing the original module to gnulib?

I think we can improve the documentation and other tools as appropriate
later on.  The need to share M4 tests of the ld version script feature
exists in several of my projects today, and I'd like to push the patch
and unify my projects in this regard as soon as possible.

>> One feature that LD version script provides, that your approach doesn't
>> provide, is that Debian's packaging tools to resolve dependencies and/or
>> facilitate future upgrades apparently works better.
>
> Indeed, it appears that they have a program 'dpkg-shlibdeps' that, after
> a package has been built, determines the minimal required version of each
> dependency (by looking at the symbol lists) and stuffs this information into
> the Debian specific packaging files. But such a tool should also work when
> the versioning is done by appending _v2, _v3, etc. to the symbol names.

Except that nobody has implemented that yet.. ;)

/Simon


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: running libtool from emacs gud mode

[Simon Josefsson]

"Justin Randall" <[EMAIL PROTECTED]> writes:

> I know this was asked once before, but I couldn't find any answers to the question. 
> Sorry if this is a FAQ.
>
> I can usually run gdb from emacs using
> M-x gdb
> Run gdb (like this): gdb 
>
> Of course, to run gdb on a libtool output file that has not yet been installed, from 
> the command line I use
>
> $ libtool gdb 
>
> But, in emacs
> M-x gdb
> Run gdb (like this): libtool gdb 
>
> produces :
> libtool: unrecognized option `-cd'
> Try `libtool --help' for more information.
>
> Debugger exited abnormally with code 1
>
> Is this something that needs to be fixed in libtool or in emacs gud mode?

This has been fixed in gud in Emacs HEAD.



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

Re: Introducing a new maintainer of libtool

[Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool]

Welcome Ileana!

Mike Frysinger  writes:

> On 13 Jan 2024 14:49, Ileana Dumitrescu wrote:
>> My short term plans are to review the numerous mailing list patches and 
>> get them merged in. This will be an easy and productive first step for 
>> me and libtool. I will also look at the various distro patches and see 
>> if any of them are fit to be upstreamed as I have noticed some of the 
>> distros have been accruing a lot of patches as well.
>
> i think we should aim to kick out something new sooner rather than later.

+1

If what's on git master passes self checks, I would package it and
prepare an alpha release and announce that to pretesters mailing list.
Assuming there is nothing in git master that really upsets you and needs
to be backed out.  Don't look at more patches until a first pretest
release is out, IMHO, as I'm sure one can go mad pondering implications
of a libtool patch forever...

/Simon


signature.asc
Description: PGP signature

Re: Introducing a new maintainer of libtool

[Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool]

Ileana Dumitrescu  writes:

>> On 16/01/2024 22:59, Simon Josefsson wrote:
>> If what's on git master passes self checks, I would package it and
>> prepare an alpha release and announce that to pretesters mailing list.
>> Assuming there is nothing in git master that really upsets you and needs
>> to be backed out.  Don't look at more patches until a first pretest
>> release is out, IMHO, as I'm sure one can go mad pondering implications
>> of a libtool patch forever...
>
> Thanks, it seems like the general consensus is to get a release out
> soon. I went through older emails on the mailing list when Alex Ameen 
> was named as maintainer, and there were similar opinions on getting a
> release out quickly.
>
> I'll need some time figuring out the release process, but otherwise I
> should be able to get an alpha release out soon. Mike has been helpful 
> and has merged in many patches over the past few days.

Looking at that, it seems the bootstrap and bootstrap.conf scripts are
really old.  Can we switch to latest gnulib tools for release and
package management?  I am doing that for many projects already, with
several different ways of using gnulib, so I can assist with that if you
want.  Do we have any GitLab CI/CD testing for libtool?  I can assist
with setting that up too, otherwise I won't have a lot of confidence in
modifying bootstrap scripts.  I suggest not putting .gitlab-ci.yml into
libtool itself, but maintain that outside of libtool, to avoid
contaminating libtool with gitlab-specific stuff.

/Simon


signature.asc
Description: PGP signature