use of libtool for linking executables - rpath problem

[Bruno Haible]

Dear libtool gurus,

More and more GNU packages start using shared libraries. One example is
libintl (from the GNU gettext package), which installs itself as a shared
library by default now. It is used by many other packages, like textutils,
gcc, hello, and others, which don't use libtool.

For users of Linux distributions, there is no problem, because the libraries
get installed in /usr/lib, which is in the dynamic linker's search path.
But for all other users, who use --prefix - and this includes most non-Linux
users - the created executables don't run because they refer to a library
located in $(prefix)/lib but $(prefix)/lib is not in the dynamic linker's
search path.

Example: First configure and install gettext-0.10.40 with --prefix=${prefix}.
Set CFLAGS="-I${prefix}/include", LDFLAGS="-L${prefix}/lib", then
configure and install hello-1.3.33 or tar-1.3.25 or textutils-2.0.16 or ...

(The CFLAGS and LDFLAGS settings are set by hand here, but could also
come from a configure argument --with-libintl-prefix=${prefix} or from
'libintl-config' shell script.)

I can see six possible approaches:

1) We don't change our packages. We only tell the user that he should have
   used LDFLAGS="-L${prefix}/lib -rpath ${prefix}/lib".

2) Introduce a --with-libintl-prefix that sets LDFLAGS to include the
   -rpath option.

3) Introduce a libintl-config script that sets outputs the right -L and
   -rpath option.

4) Create a stripped-down minilibtool.sh and minilibtool.m4 which serve
   the purpose of linking an executable will all kinds of libraries
   (static libraries, shared libraries, installed libtool libraries).
   Add it to each package that needs to link against a shared library
   (starting with GNU hello, textutils etc.)

5) Add ltmain.sh and libtool.m4 to each package that needs to link against
   a shared library (starting with GNU hello, textutils etc.)

6) Let each package search for 'libtool' in $PATH and use it if found,
   and fall back to 1) if not found.


Evaluation of the approaches:

1) This pushes the problem back to the user. It leads the "configure"
   philosophy ad absurdum: the user has to know/guess in advance which
   libraries the package will need, and set the CFLAGS and LDFLAGS
   accordingly. He also has to have platform dependent knowledge about
   -rpath, "-Wl,-rpath", -R and similar.
   Furthermore, all created executables will get the -rpath, even those
   that don't need it (not only those that depend on a library in that
   particular directory).

2),3) First, would this work at all? I can see in ltmain.sh some code
   to remove duplicate occurrences from the -rpath element list, and
   (for HP-UX, OSF/1 and AIX) code to merge multiple -rpath values
   into a single one, colon-separated. Is this a requirement or only
   an optimization?
   Assuming it is only an optimization, this could work, but the autoconf
   macro for setting LDFLAGS, or - in case 3 - the code which generates
   the libintl-config script - would have to include all the platform
   dependent knowledge about -rpath handling, approx. 20 KB or 30 KB
   of code.
   Who is going to maintain this code, given that is has large overlap
   with libtool?

3) In this case, moreover, the libintl-config script must cope with the
   possibility that the C compiler it is invoked for is different from
   the one which was used to compile the libintl package. Care with ${wl}...

4) The size of minilibtool.sh is ca. 35 KB (= 25% of ltmain.sh), and the
   size of minilibtool.m4 is ca. 64 KB (= 50% of libtool.m4). This is
   definitely smaller than libtool. But who is going to maintain this?
   And is it worth it at all, given that more package will start using
   the -dlopen and other features, which precisely make libtool so big?

5) This is the most easy solution, but increases the package's size by
   470 KB: 3 x 110 KB (libtool.m4, aclocal.m4, configure), 140 KB
   (ltmain.sh). Also, it runs counter to the Libtool manual, which says:

"If you choose at this point to "install" the library (put it in a
 permanent location) before linking executables against it, then you
 don't need to use libtool to do the linking.  Simply use the
 appropriate `-L' and `-l' flags to specify the library's location."

6) This works only when the same C compiler is used to build the package
   as was used to configure libtool.


Which approach would you libtool guys recommend?

Can you make and maintain a smaller version of libtool.m4 and ltmain.sh
that creates only executables and assumes none of the needed libraries uses
-dlopen or -dlpreopen?

Bruno

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

Re: use of libtool for linking executables - rpath problem

[Bruno Haible]

Paul Davis writes:

> The 7th is to have the shared library use pkg-config, allowing other
> tools to find out about it without relying on the linker configuration.
> Its much cleaner than any of the other choices you mention, and
> thankfully, has nothing to do with libtool (phew!)

Can you please elaborate more: How is this going to provide the
platform and compiler specific rpath option?

Bruno

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

Re: use of libtool for linking executables - rpath problem

[Bruno Haible]

Paul Eggert writes:

> > 6) Let each package search for 'libtool' in $PATH and use it if found,
> >and fall back to 1) if not found
> > 
> >This works only when the same C compiler is used to build the package
> >as was used to configure libtool.
> 
> Can you please explain why (6) has this limitation?

The following depend on the C compiler:

  - the flag used to pass -rpath to the linker. Sometimes it's
"-Wl,", sometimes it's "-Qoption,ld,", sometimes it's empty.

  - on AIX, also the way shared libraries are supported.

> Is this something that can easily be fixed by modifying libtool?

Yes, if one is willing to copy some pieces of libtool.m4 to ltmain.sh,
so that the configured libtool has information about all compilers
that run on the particular platform.

Bruno

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

Re: use of libtool for linking executables - rpath problem

[Bruno Haible]

Paul Eggert writes:

> By the way, thanks for your analysis.  This is a real problem that
> seems to me to be getting worse with time.

The problem is now solved if you take the gettext.m4 and iconv.m4
autoconf macros from
ftp://alpha.gnu.org/gnu/gettext/gettext-0.11-pre3.tar.gz.
You also need to copy the files

   config.rpath
   m4/lib-ld.m4
   m4/lib-link.m4
   m4/lib-prefix.m4

The effect of these macros is to change the value of LIBICONV from

   "-L/some/prefix/lib -liconv"
to
   "/some/prefix/lib/iconv.so -R/some/prefix/lib"

or whatever platform dependent flags are needed to ensure proper
linking. Similarly for the value of LIBINTL that gets substituted in
the Makefiles.

Bruno


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

Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

[Bruno Haible]

Paul Eggert wrote:
> Given the other problems that ensue on Solaris when one compiles and
> links to different standards, the simplest answer may be just "don't
> do that".  It's not just the __xpg4 and __xpg6 stuff; it's also the
> _lib_version stuff: scanf behaves differently depending on which
> flavor of the -X option one passes to cc.  It's quite a mess.

Your proposed answer "don't do that" would imply that every library
is distributed in different variants, one for each standards compliance.
Not only /usr/lib and /usr/lib/64, but
  /usr/lib
  /usr/lib/xpg4
  /usr/lib/xpg6
  /usr/lib/64
  /usr/lib/64/xpg4
  /usr/lib/64/xpg6

This is not realistic: People are not distributing libraries in this
way, and are not even aware for which standard a library was built
and tested for. ("file libfoo.so" does not tell. You need
"nm libfoo.so | grep values".)

Bruno

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

libtool-next-version: new program

[Bruno Haible]

Bumping the libtool version of a shared library according to
<https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>
seems to be harder than expected: Both the gettext-0.19.8 and gettext-0.20
release suffer from a wrongly computed triple (mistakes done by different
maintainers!).

Let me try to make this procedure less prone to mistakes, through a wizard
program.

I'm committing this in gnulib for now, since libtool currently has a low
release frequency. But please include this script in the next libtool release
as an installable program.


2019-05-12  Bruno Haible  

libtool-next-version: New program.
* build-aux/libtool-next-version: New file.

 build-aux/libtool-next-version 
#! /bin/sh
#
# Copyright (C) 2019 Free Software Foundation, Inc.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <https://www.gnu.org/licenses/>.
#

# This program is a wizard that helps a maintainer update the libtool
# version of a shared library, according to the documentation section
# 'Updating version info'
# 
<https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>.
#
# Let's call the three parts of the version
#   LTV_CURRENT
#   LTV_REVISION
#   LTV_AGE
#
# The list of steps given in this documentation section
#   - If the library source code has changed at all since the last update,
# then increment LTV_REVISION.
#   - If any interfaces have been added, removed, or changed since the last
# update, increment LTV_CURRENT and set LTV_REVISION to 0.
#   - If any interfaces have been added since the last public release, then
# increment LTV_AGE.
#   - If any interfaces have been removed or changed since the last public
# release, then set LTV_AGE to 0.
# leads to mistakes, because
#   - It does not say what "interfaces" are.
#   - It does not enforce that applying the second, third, or fourth rule
# is only possible after applying the first rule.
#   - It does not enforce that applying the third or fourth rule is only
# possible after applying the second rule.

# func_usage
# outputs to stdout the --help usage message.
func_usage ()
{
  echo "\
Usage: libtool-next-version [OPTION]... PREVIOUS-LIBRARY CURRENT-LIBRARY

Determines the next version to use for a libtool library.

PREVIOUS-LIBRARY is the installed library (in .a or .so format) of the
previous release.

CURRENT-LIBRARY is the installed library (in .a or .so format) of the current
release candidate.

Options:
  --help   print this help and exit
  --versionprint version information and exit

Report bugs to ."
}

# func_version
# outputs to stdout the --version message.
func_version ()
{
  echo "libtool-next-version (GNU gnulib)"
  echo "Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law."
  echo "Written by" "Bruno Haible"
}

# func_fatal_error message
# outputs to stderr a fatal error message, and terminates the program.
func_fatal_error ()
{
  echo "declared.sh: *** $1" 1>&2
  echo "declared.sh: *** Stop." 1>&2
  exit 1
}

# func_tmpdir
# creates a temporary directory.
# Sets variable
# - tmp pathname of freshly created temporary directory
func_tmpdir ()
{
  # Use the environment variable TMPDIR, falling back to /tmp. This allows
  # users to specify a different temporary directory, for example, if their
  # /tmp is filled up or too small.
  : ${TMPDIR=/tmp}
  {
# Use the mktemp program if available. If not available, hide the error
# message.
tmp=`(umask 077 && mktemp -d -q "$TMPDIR/gtXX") 2>/dev/null` &&
test -n "$tmp" && test -d "$tmp"
  } ||
  {
# Use a simple mkdir command. It is guaranteed to fail if the directory
# already exists.  $RANDOM is bash specific and expands to empty in shells
# other than bash, ksh and zsh.  Its use does not increase security;
# rather, it minimizes the probability of failure in a very cluttered /tmp
# directory.
tmp=$TMPDIR/gt$$-$RANDOM
(umask 077 && mkdir "$tm

[sr #110674] Option --with-pic is a misnomer

[Bruno Haible]

URL:
  <https://savannah.gnu.org/support/?110674>

 Summary: Option --with-pic is a misnomer
 Project: GNU Libtool
   Submitter: haible
   Submitted: Thu 23 Jun 2022 06:29:37 AM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux


___

Follow-up Comments:


---
Date: Thu 23 Jun 2022 06:29:37 AM CEST By: Bruno Haible 
A configure script that is built with libtool 2.4.7 has the options
('configure --help' output):

  --with-pic[=PKGS]   try to use only PIC/non-PIC objects [default=use
  both]
  --with-aix-soname=aix|svr4|both
  shared library versioning (aka "SONAME") variant to
  provide on AIX, [default=aix].


Per the GNU Coding Standards,
https://www.gnu.org/prep/standards/html_node/Configuration.html, these options
ought to be called --enable-something, not --with-something.

Probably you'll need to continue to support the --with-* spelling for a while,
though, for backward compatibility.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110674>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110674] Option --with-pic is a misnomer

[Bruno Haible]

Follow-up Comment #2, sr#110674 (group libtool):


> old versions that have --with-pic & not --enable-pic will stick around
basically forever.

Yes, we can't make old versions disappear. E.g. a search on
codesearch.debian.net shows that 6% of all Debian sources still integration
with libtool version 1.x.

But that's not the point. The point of this bug report is that the
'./configure --help' output (and the libtool documentation) should not spread
confusion about what --enable-... and --with-... options mean.

The support for the old spelling does not need to be documented; it can be
supported silently.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110674] Option --with-pic is a misnomer

[Bruno Haible]

Follow-up Comment #4, sr#110674 (group libtool):

Spreading confusion about what --enable-... and --with-... options mean is one
of the problems. Another one is that, in the './configure --help' output,
these options appear in the section "Optional Packages", whereas they belong
in the section "Optional Features".


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110674] Option --with-pic is a misnomer

[Bruno Haible]

Follow-up Comment #5, sr#110674 (group libtool):

Find attached two patches that fix the problem. I have verified them by

* running libtool's "make check",

* applying them to GNU gettext and verifying that (on FreeBSD) the generated
libintl.a is compiled as PIC when --enable-pic or --with-pic is specified and
as non-PIC by default.

* applying them to GNU gettext and verifying that (on AIX 7.1, in 32-bit mode)
the options --enable-aix-soname=both and --with-aix-soname=both have the same
effect (of creating a file libintl.so.8 and a symlink libintl.so).


(file #55641, file #55642)

___

Additional Item Attachment:

File name: 0001-Rename-option-with-pic-to-enable-pic.patch Size:9 KB
   


File name: 0002-Rename-option-with-aix-soname-to-enable-aix-soname.patch
Size:6 KB
   



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-ed08f156ef35c024317b67f6255b1489079e6747.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110674] Option --with-pic is a misnomer

[Bruno Haible]

Follow-up Comment #6, sr#110674 (group libtool):

I have also verified, of course, that with the two patches the output of
'./configure --help' is as desired.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: How to force libtool to use CXX mode?

[Bruno Haible]

Bob Friesenhahn wrote:
> Automake does have a critical bug in that for a target which only optionally 
> has C++ sources, that target is always linked using C++. Without this issue, 
> the trick of including an empty optional C++ source file in the build would 
> work. But I do not want GraphicsMagick to require a C++ compiler.

For a target 'foo', Automake uses a foo_LINK variable, for which it provides a
default definition. Since you are not satisfied with this default definition,
you can and should provide your own definition of this variable. You can then
decide yourself whether it uses
  --tag=CC  or  --tag=CXX
and
  $(CCLD) $(AM_CFLAGS) $(CFLAGS)  or  $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS).

See e.g. in gettext/gettext-tools/src/Makefile.am the 'msgmerge' target and
the msgmerge_LINK variable. This definition has been in use for ca. 20 years.

Bruno

Re: libtool-2.5.1 released [beta]

[Bruno Haible]

Hi Ileana,

I tested a GNU gettext tarball, built with libtool-2.5.1, on several platforms,
including on Solaris 11.3 (where libtool-2.4.7 had a problem). No issues found;
everything is fine.

Bruno

[sr #111011] restore shared library support on Android

[Bruno Haible]

Follow-up Comment #3, sr #111011 (group libtool):


> One recent commit broke Android build.

Nope. This commit of mine was explained in
https://lists.gnu.org/archive/html/libtool-patches/2023-09/msg0.html

There are different environments on Android, as explained in
https://lists.gnu.org/archive/html/bug-gnulib/2022-12/msg00100.html .

A statement like "Note that on Android and MIcrosoft Windows must not hard
code any paths." is not helpful.

In the Android environment I am using, translating -rpath options to RUNPATH
properties is mandatory.

If you are in an Android environment where RUNPATH options are not adequate,
either pass '--disable-rpath' to the configure program, or find a way to
reliably distinguish the two kinds of environments.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[sr #111011] restore shared library support on Android

[Bruno Haible]

Follow-up Comment #5, sr #111011 (group libtool):


> Applications(programs) could be installed in any location(path)!

You seem to assume that programs are always meant to be installed on a
different machine than on the one it was built.

This is not the case. The GNU project strives to make software modifiable and
installable by individual users. Such users often build a package in order to
use it only on that machine. In this situation, it does make sense to use
hardcoded paths. (Both on Windows and on Android.)



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[sr #111011] restore shared library support on Android

[Bruno Haible]

Follow-up Comment #7, sr #111011 (group libtool):


> Goal of build tools is to help package manager(build engineer) to prepare
installation.

No, that is not the only goal. Installation by individual users, on their own
machines, is a goal of the GNU projects too. See:

* In https://www.gnu.org/prep/standards/html_node/DESTDIR.html, it is allowed
to not specify DESTDIR on the 'make install' command line.

* In https://www.gnu.org/prep/standards/html_node/Standard-Targets.html, the
'uninstall' target would not be specified if package managers were the only
audience.

> "Make sense" in this context is just a lie.

You should not drift into personal offense.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

Re: libtool 1.5.14 on mingw: DLLs must be installed executable

[Bruno Haible]

Ralf Wildenhues wrote:
> Erm, the fix is fine, but what caused the breakage in the first place?
> Surely this hasn't been broken all the time?

For me, it has been broken all the time: It's the first time I've succeeded
building a working DLL with mingw and libtool 1.5.x.

Maybe something about my setup is particular: it's Windows XP, NTFS, with
"security" permission settings that have been modified by someone else. In
other words, it may be not the default config, but it's a config you can
easily end up with, without seeing other obvious breakage.

Bruno



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

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

[Bruno Haible]

Ralf Wildenhues wrote:
> It's a bit tricky to reproduce: You
> need a system which has no argz.h, then configure, then `make check'
> without prior make.  If you had ever run `make' before in this build
> tree, even after `make clean' the dependency information is stored in
> libltdl/.deps/*.Plo, and thus hides this bug.
>
> Now the gnulib snippet in libltdl/Makefile.am leaves us with the
> possibility of using the lib_OBJECTS variable to fix this(?).
>
> Several questions (thus the crosspost to all of these lists):
> - Is it ok/supposed by gnulib to use lib_OBJECTS for this?
> - Is it ok by Automake to use the *_OBJECTS variables it created,
>   i.e., may they be treates as exported interface?

The modules in gnulib are normally used in a directory that creates a
single library, say libfoo.la, and in this case a line like

  all-local $(lib_OBJECTS): $(ARGZ_H)

is meant to be changed to

  all-local $(libfoo_la_OBJECTS): $(ARGZ_H)

If, in the case of libltdl, the directory creates several libraries, then
yes your patch looks OK:

> +## Make sure argz.h will be created before it is needed:
> +lib_OBJECTS = \
> + $(dlopen_la_OBJECTS) \
> + $(dld_link_la_OBJECTS) \
> + $(dyld_la_OBJECTS) \
> + $(load_add_on_la_OBJECTS) \
> + $(loadlibrary_la_OBJECTS) \
> + $(shl_load_la_OBJECTS) \
> + $(libltdl_la_OBJECTS) \
> + $(libltdlc_la_OBJECTS)
> +

Bruno



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

Re: libtool file naming conventions

[Bruno Haible]

Hello,

Peter O'Gorman wrote:
> > libtool unfortunately wants to write into the .libs directory
> > during "make install".
>
> I vaguely recall a requst fairly recently on the libool list to relink in a
> tmpdir, I guess I'd better go look into that. :/

Absolutely. There are three major grips that I have with libtool 1.x, that
could be solved by naming files differently than now:

1) "make install" relinking: it not only writes into .libs, it also
   temporarily replaces the libraries in .libs. IMO one should better
   relink in the destination directory (because this one is guaranteed to
   be writable) or in a temp dir under the the destination directory.

2) An executable in .libs an "lt-" prefix, that I must remove when I want
   good --help output in the build directory. (Which I need for using
   "help2man".) So far I'm using this code.

/* Set program_name, based on argv[0].  */
void
set_program_name (const char *argv0)
{
  /* libtool creates a temporary executable whose name is sometimes prefixed
 with "lt-" (depends on the platform).  It also makes argv[0] absolute.
 Remove this "/.libs/" or "/.libs/lt-" prefix here.  */
  const char *slash;
  const char *base;

  slash = strrchr (argv0, '/');
  base = (slash != NULL ? slash + 1 : argv0);
  if (base - argv0 >= 7 && memcmp (base - 7, "/.libs/", 7) == 0)
argv0 = base;
  if (strncmp (base, "lt-", 3) == 0)
argv0 = base + 3;
  program_name = argv0;
}

3) Instead of an executable itself I find a shell script. So that I cannot
   use "gdb foo" but rather must do "libtool gdb foo". Which I most of the
   time don't do, because setting breakpoints in shared libraries often is
   a pain. Instead "make distclean; ./configure --disable-shared", because
   then debugging with gdb is a lot easier.

Bruno



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

Re: libtool 2.1a failed mdemo-make.test on Solaris

[Bruno Haible]

Alexandre Duret-Lutz wrote:
>  Bruno> all-local $(libfoo_la_OBJECTS): $(ARGZ_H)
>
> Hmmm, why do you need this since $(ARGZ_H) is already in
> $(BUILT_SOURCES), and "all" depends on $(BUILT_SOURCES)?

You are right, the presence of $(ARGZ_H) in $(BUILT_SOURCES) makes this
rule unnecessary. (Historically, the rule predates the use of BUILT_SOURCES.)
Thanks for the hint. I propose this patch in gnulib.

Bruno


2005-07-22  Bruno Haible  <[EMAIL PROTECTED]>

* modules/alloca-opt (Makefile.am): Remove explicit dependency on
$(ALLOCA_H), redundant through BUILT_SOURCES.
* modules/argz (Makefile.am): Remove explicit dependency on $(ARGZ_H),
redundant through BUILT_SOURCES.
* modules/byteswap (Makefile.am): Remove explicit dependency on
$(BYTESWAP_H), redundant through BUILT_SOURCES.
* modules/fnmatch (Makefile.am): Remove explicit dependency on
$(FNMATCH_H), redundant through BUILT_SOURCES.
* modules/getopt (Makefile.am): Remove explicit dependency on
$(GETOPT_H), redundant through BUILT_SOURCES.
* modules/glob (Makefile.am): Remove explicit dependency on $(GLOB_H),
redundant through BUILT_SOURCES.
* modules/poll (Makefile.am): Remove explicit dependency on $(POLL_H),
redundant through BUILT_SOURCES.
* modules/stdbool (Makefile.am): Remove explicit dependency on
$(STDBOOL_H), redundant through BUILT_SOURCES.
* modules/stdint (Makefile.am): Remove explicit dependency on
$(STDINT_H), redundant through BUILT_SOURCES.
* modules/sysexits (Makefile.am): Add $(SYSEXITS_H) to BUILT_SOURCES.
Remove explicit dependency on $(SYSEXITS_H).
Reported by Alexandre Duret-Lutz <[EMAIL PROTECTED]>.

*** modules/alloca-opt  29 Sep 2004 22:10:44 -  1.1
--- modules/alloca-opt  22 Jul 2005 19:30:39 -
***
*** 18,24 
  
  # We need the following in order to create an  when the system
  # doesn't have one that works with the given compiler.
- all-local $(lib_OBJECTS): $(ALLOCA_H)
  alloca.h: alloca_.h
cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 18,23 
*** modules/argz22 Sep 2004 16:23:27 -  1.3
--- modules/argz22 Jul 2005 19:30:39 -
***
*** 17,23 
  
  # We need the following in order to create an  when the system
  # doesn't have one that works with the given compiler.
- all-local $(lib_OBJECTS): $(ARGZ_H)
  argz.h: argz_.h
cp $(srcdir)/argz_.h [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 17,22 
*** modules/byteswap1 May 2005 14:13:02 -   1.1
--- modules/byteswap22 Jul 2005 19:30:39 -
***
*** 16,22 
  
  # We need the following in order to create a  when the system
  # doesn't have one.
- all-local $(lib_OBJECTS): $(BYTESWAP_H)
  byteswap.h: byteswap_.h
cp $(srcdir)/$< [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 16,21 
*** modules/fnmatch 6 May 2005 17:22:45 -   1.8
--- modules/fnmatch 22 Jul 2005 19:30:39 -
***
*** 21,27 
  
  # We need the following in order to create an  when the system
  # doesn't have one that supports the required API.
- all-local $(lib_OBJECTS): $(FNMATCH_H)
  fnmatch.h: fnmatch_.h
cp $(srcdir)/fnmatch_.h [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 21,26 
*** modules/getopt  6 Jul 2005 15:58:47 -   1.8
--- modules/getopt  22 Jul 2005 19:30:39 -
***
*** 20,26 
  
  # We need the following in order to create an  when the system
  # doesn't have one that works with the given compiler.
- all-local $(lib_OBJECTS): $(GETOPT_H)
  getopt.h: getopt_.h
cp $(srcdir)/getopt_.h [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 20,25 
*** modules/glob29 May 2005 16:56:02 -  1.1
--- modules/glob22 Jul 2005 19:30:39 -
***
*** 28,34 
  
  # We need the following in order to create an  when the system
  # doesn't have one that works with the given compiler.
- all-local $(lib_OBJECTS): $(GLOB_H)
  glob.h: glob_.h
cp $(srcdir)/glob_.h [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 28,33 
*** modules/poll22 Sep 2004 15:11:04 -  1.5
--- modules/poll22 Jul 2005 19:30:39 -
***
*** 17,23 
  
  # We need the following in order to create an  when the system
  # doesn't have one.
- all-local $(lib_OBJECTS): $(POLL_H)
  poll.h: poll_.h
cp $(srcdir)/poll_.h [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
--- 17,22 
*** modules/stdbool 22 Sep 2004 15:11:04 -  1.10
--- modules/stdbool 22 Jul 2005 19:30:39 -
***
*** 17,23 
  
  # We need the following in order to create an  when the system
  # doesn't have one that works.
- all-local $(li

Re: use of -fno-common on Darwin

[Bruno Haible]

Paul Eggert wrote:
> "Peter O'Gorman" <[EMAIL PROTECTED]> writes:
> > getprogname(3), if it exists, can be used as well as other
> > alternatives (e.g. argv[0]).
>
> Thanks, I wasn't aware of the BSD getprogname until now.

Me too.

> How about this proposal?
>
> * Change the progname module to use the BSD getprogname naming
>   convention.  No sense reinventing the wheel.  That way, programs can
>   simply use the system-defined functions on BSD.
>
> * Rewrite the other gnulib code to use the new convention.
>
> * Ask gnulib users to switch to the new convention.

Yes, that's the most sensible thing to do. If there are no objections,
I will change the 'progname' module accordingly.

Bruno



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

Re: support for SunPRO C/C++ on Linux

[Bruno Haible]

Hello Ralf,

Here is a revised patch. I changed the recognition of the Sun compilers,
and the whole_archive_flag_spec and postdeps, so that now all 112 tests PASS.

> > With this patch, the FAILs are turned into PASS; all tests PASS or SKIP.
>
> Which ones skip?

Good question. I had many SKIPs, but this was either because I had forgotten
to copy a recent config.guess, or because I did
  ./configure
  make
  make check
- not knowing that after modifying libtool.m4, a simple "make" does not
update the aclocal.m4 and configure files in the subdirectories; now I do
  ./configure
  make
  make dist
  make check
and it works much better!


2006-05-09  Bruno Haible  <[EMAIL PROTECTED]>

* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_POSTDEP_PREDEP):
Add support for Sun C++ 5.9 on Linux.
(AC_LIBTOOL_PROG_COMPILER_PIC): Add support for Sun C 5.9 and
Sun C++ 5.9.
(AC_LIBTOOL_PROG_LD_SHLIBS): Add support for Sun C 5.9.

*** libtool-1.5.22/libtool.m4.bak   2005-12-18 22:53:17.0 +0100
--- libtool-1.5.22/libtool.m4   2006-05-09 03:55:44.0 +0200
***
*** 3353,3358 
--- 3353,3379 
# dependencies.
output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v 
conftest.$objext 2>&1 | grep "ld"`; templist=`echo $templist | $SED 
"s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; list=""; for z in $templist; do case $z in 
conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; 
done; echo $list'
;;
+   *)
+   if LC_ALL=C $CC -V 2>&1 | sed 1q | grep "Sun C" > /dev/null; then
+ # Sun C++ 5,9
+ _LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}  
-h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects 
$compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G${allow_undefined_flag} 
 -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects 
$compiler_flags ${wl}-retain-symbols-file ${wl}$export_symbols'
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+ _LT_AC_TAGVAR(whole_archive_flag_spec, 
$1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do 
test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $echo 
\"$new_convenience\"` ${wl}--no-whole-archive'
+ 
+ # Not sure whether something based on
+ # $CC $CFLAGS -v conftest.$objext -o libconftest$shared_ext 2>&1
+ # would be better.
+ output_verbose_link_cmd='echo'
+ 
+ # Archives containing C++ object files must be created using
+ # "CC -xar", where "CC" is the Sun C++ compiler.  This is
+ # necessary to make sure instantiated templates are included
+ # in the archive.
+ _LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
+   fi
+   ;;
  esac
  ;;
lynxos*)
***
*** 3872,3877 
--- 3893,3905 
_LT_AC_TAGVAR(postdeps,$1)=
;;
  
+ linux*)
+   if LC_ALL=C $CC -V 2>&1 | sed 1q | grep "Sun C" > /dev/null; then
+ # Sun C++ 5.9
+ _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun'
+   fi
+   ;;
+ 
  solaris*)
case $cc_basename in
CC*)
***
*** 4991,4996 
--- 5019,5030 
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
  *)
+   if LC_ALL=C $CC -V 2>&1 | sed 1q | grep "Sun C" > /dev/null; then
+ # Sun C++ 5.9
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
+   fi
;;
esac
;;
***
*** 5237,5242 
--- 5271,5284 
  # All Alpha code is PIC.
  _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
  ;;
+   *)
+   if LC_ALL=C $CC -V 2>&1 | sed 1q | grep "Sun C" > /dev/null; then
+ # Sun C 5.9
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+   fi
+   ;;
esac
;;
  
***
*** 5547,5559 
ifc* | ifort*)  # Intel Fortran compiler
  tmp_addflag=' -nofor_main' ;;
esac
!   _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared'"$tmp_addflag"' $libobjs 
$deplibs $compiler_flags ${wl}-so

Re: Compiling with MinGW

[Bruno Haible]

Matthew McGillis wrote:
> found that by simply  
> editing the libtool used in both of the above cases and adding:
> 
>  case $deplib in
>/home*) deplib="c:/cygwin"$deplib;;
>  esac
> 
> ...
> I was able to complete the compiles and generate a version of  
> wvware-1.2.1 that worked standalone on windows.

You appear to be using mingw as a development environment. I don't know
whether libtool supports that.

I use a recent cygwin as the development environment, and mingw only as
the deployment environment. In this setting, I can build gettext-0.15
out of the box, without problems. Here is the command that I use:

   CPPFLAGS="-mno-cygwin -Wall -I/usr/local/mingw/include" \
   CFLAGS="-mno-cygwin -O2 -g" \
   CXXFLAGS="-mno-cygwin -O2 -g" \
   LDFLAGS="-mno-cygwin -L/usr/local/mingw/lib" \
   ./configure --host=i586-pc-mingw32 --prefix=/usr/local/mingw

Why would anyone want to use mingw as a development environment?
Maybe end-users cannot learn to write "/cygdrive/c/" for "c:\". But
developers certainly can.

Apologies for having used the term "mingw development environment"
in gettext/README.woe32; I didn't know that mingw as a development
environment has problems like the one you cite.

Bruno


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

improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Hi,

There are 4 ways to deal with the problem of exported variables when
building shared libraries on Woe32 platforms. Programmers of shared libraries
have to choose among them. Two of them I'd consider unacceptable for use
in serious projects, and among the remaining two ways one is hard to put
in place in projects that make use of gnulib.

The remaining way appears to be a good compromise between
  - memory use and standards conformance - the resulting DLLs behave like
DLLs built with Microsoft's compiler,
  - efficiency of the generated code - it does not have more indirections than
code compiled with -fPIC on ELF,
  - amount of code changes - the only change to source code is that declarations
of exported variables in header files must be marked as DLL_VARIABLE; no
changes needed for functions,
  - amount of configure / makefile infrastructure - only the DLL_VARIABLE macro
must be defined; its value can be determined in an autoconf macro and is
fixed throughout the compilation.

You find complete details about this approach in
  http://www.haible.de/bruno/woe32dll.html

A prototype of this approach is being used in GNU libiconv-1.11 and
GNU gettext-0.15.

But currently, libtool lacks about 20 lines of code to make this approach
actually work.

I'd suggest to add this support to libtool. Details are in the above mentioned
web page.

I don't suggest to add it to the linker (GNU ld), because I heard rumours that
libtool shall in the long term also support the Microsoft compiler and linker
('cl'). Putting the support for this approach into libtool will also make it
work with 'cl', whereas putting it into GNU ld would not.

Bruno


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

Re: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Danny Smith wrote:
> 
> ...
> there is no need any more for this warning. gcc should remove this
> warning.
> 
> 
> Are you sure about that.
> 
> The reason that gcc emits these warnings is this:
> gcc -S dllimp.c
> 
>   .file   "dllimp.c"
>   .text
> .globl _externfunc2
>   .def_externfunc2;   .scl2;  .type   32; .endef
> _externfunc2:
>   pushl   %ebp
>   movl%esp, %ebp
>   pushl   %ebx
>   subl$4, %esp
>   movl8(%ebp), %edx
>   movl__imp__externvar, %eax  <<< imported
>   movl(%eax,%edx,4), %ebx
>   movl$0, (%esp)
>   movl__imp__externfunc, %eax <<< imported
>   call*%eax
>   leal(%ebx,%eax), %eax
>   addl$4, %esp
>   popl%ebx
>   popl%ebp
>   ret
> .globl _externvar  <<< exported
>   .data
>   .align 4

The same indirections happen on ELF systems:

externfunc2:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$4, %esp
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
movl$0, (%esp)
call[EMAIL PROTECTED] <<< imported
movl8(%ebp), %ecx
movl[EMAIL PROTECTED](%ebx), %edx  <<< imported
addl(%edx,%ecx,4), %eax
addl$4, %esp
popl%ebx
popl%ebp
ret
...
.globl externvar  <<< exported
.data
.align 4

And it doesn't yield "ambiguities" on ELF systems.

> There is dangerous ambiguity.
> In the past this kind of ambiguity cause most of the dllimport-related
> ICE's in GCC.

I assume that GCC has enough maintainers to fix ICEs inside GCC.

> Does the client really want to resolve the two symbols using dllimport
> semantics?

Sure. If someone makes a reference to 'externvar' from within a DLL,
and it is also defined in the DLL, it's hard to imagine that he would
_not_ want to use the definition from the DLL.

> With unit-a-time optimizations, we delay adding the attribute until the
> whole unit is processed.

Nice, this allows to actually optimize away the indirection.

> which is probably what the user wanted. 
>  Maybe not.
> Maybe the user really just made a [im|ex] typo.

I propose to make 'dllexport' unnecessary, and to make it possible to
use 'dllimport' everywhere where the users were used to write either
'dllimport' or 'dllexport', depending on the compilation pass and unit.
Your counterargument is that he might wanted to see a warning which
reminds him to use 'dllexport' - but this is now unnecessary. This is
precisely the point of the simplification.

Bruno


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

Re: AW: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Hello,

Markus Duft wrote:
> I implemented wgcc (a compiler wrapper behaving like gcc but calling
> cl.exe). Since the target should be to compile sources with minimum
> changes i have done lot's of work for this.

That's certainly a good idea. I would consider such a tool usable only
if it had no arbitrary limits, such as a maximum size of 65000 bytes for
an exports list, or similar. (I saw an MSVC error message once
"Too many variables in function" for a function with more than 1024 local
variables, and don't want to repeat such an experience.)

> (gets even better in wgcc v2, one will not need to export anymore, just
> import ;o)). This works for shared, and (!!) for static libraries, since
> wgcc generates some symbols.

Very nice. "Just import" is also the point of the proposed libtool changes.
If everyone was using either GNU ld or your wgcc, one could consider
implementing this functionality in GNU ld. But there are people who
use MSVC direcly or using other wrappers.

> This was one of the main problems, that any executeable sources can
> _never_ know which library gets linked statically or shared.   

Yes, I agree that adding the extra export symbols not at DLL construction
time but also at .EXE construction time is even better. It allows not
only to use the same macro
  #define DLL_VARIABLE __declspec(dllimport)
for all sources that end up in shared libraries but also for any source
code, regardless whether it ends up being built shared or statically.

> Maybe you want to have a look at it

Where are the sources to your wgcc2 ? The source of wgcc1 doesn't appear to
generate exports as needed.

Bruno


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

Re: libraries and namespaces

[Bruno Haible]

Hello Ralf,

> Slightly related question: are you planning on providing a means to
> automatically rename gnulib functions to a library-specific namespace?
> As long as there is no policy on interface stability for gnulib, I would
> fear to see lots of libraries floating around that all carry some
> slightly incompatible version of some rather common symbol name around;
> when such issues arise, they tend to be a pain to debug.

There is a problem only for documented libraries and for dependent libraries
of documented libraries.

Would you recommend to rename the functions at the C source code level?
Through #defines or asm directives? Or are there solutions at library
level? For example is it possible for a library A to export a symbol S,
such that when B depends on A and C depends on B, B can use S, but C cannot?

Bruno


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

Re: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Hello Ralf,

> | Woe32 problem 1: Exports
> [...]
> | Methods 2b and 2c don't work for C++, because of the name mangling.
> 
> Well, that assumes that you create an export list (or the asm
> statements) manually.

Yes, that's what I meant by "a selected set of symbols".

> That does not have to be the case: you 
> could use a tool like `nm' or `dumpbin' to generate the lists.
> In fact, I believe libtool does something similar in some cases.

Yes, the user can specify a regex for the symbols. Does libtool demangle
the C++ symbols so that the user can write a regex that works independently
of the compiler's name mangling algorithm?

> | Method 2c additionally has the drawback that it works in a single
> | configuration only; a library cannot export different sets of symbols
> | depending on configuration settings.
> 
> I don't understand this paragraph.  You can create an export list
> in any way you like right before creating the DLL.

This paragraph is about a manually selected set of symbols. Sure you
can postprocess this export list right before creating the DLL. That
would be a fix to the mentioned drawback; you need extra processing
to eliminate this drawback.

> | Woe32 problem 2: Exported variables
> [...]
> |4. Define a macro that expands to  __declspec(dllimport)  always, and
> | use it in all header files of the library that define variables.
> [...]
> | So, why isn't method 4 in wider use? The reason is that
> | 
> |1. the compiler signals warnings, making the developer think that he
> | is on the wrong path,
> |2. libtool fails to handle self-references, i.e. references to a
> | symbol from within the shared library that exports the symbol lead to a
> | link error.
> 
> If I have several code references using the symbol, each of them sees a
> declaration decorated with `__declspec(dllimport)', and takes the
> address of that symbol, then those pointers will compare equal only for
> code within the same library (or executable), right?

No. __declspec(dllimport) tells the compiler that an indirection is
needed. The compiler will simplify '&externvar' to '_imp__externvar'. There
is one _imp__externvar per library, but all their values are the same.

The "same function name, different address" problem will occur - as far
as I understand it - when you don't use __declspec(dllimport) for functions.
This is the case when the linker adds trampoline functions looking like:

_externfunc:
jmp *__imp__externfunc

(This case was also a headache in the ELF/IA-64 glibc implementation.)

> > But currently, libtool lacks about 20 lines of code to make this approach
> > actually work.
> 
> Well, with those 20 lines there's at least one practical issue:
> 
> `join' isn't part of MSYS (yet), and neither listed in GCS:
> http://sourceforge.net/mailarchive/message.php?msg_id=17325152
> So we can't use it easily; or at least we should push for MSYS to
> include it.

Yes, this would be a good idea. It's not the first time that "join"
is needed to get down from O(n^2) to O(n). In the meantime one should
recode that statement to use 'sort' and 'sed'/'uniq' instead.

> I haven't understood yet how you think to deal with -export-symbols or
> -export-symbols-regex.  Will the export ordinals remain constant if we
> use "the first attempt" to add the _imp__* pointers?
> ... library stability ...

I've no idea how GNU ld creates DLLs and what guarantees library stability
there. Experts?

> Next, there is existing software using method 3.  Do I understand
> correctly that method 4 may be modified to detect this case and still
> support it?

When a software uses method 3, there are no self-references. The result
of the "join" command will be an empty file, and the generated exports.c
file will be empty. Hence it will work in this case too.

> Another point that comes to mind: mutually dependent libraries.
> With manually (i.e,. non-Automake generated) rules we could add a method
> to just extract the symbol lists/create the import libs, and create the
> dlls afterwards... not sure how to feed that into Automake, though,
> should we ever wish to support this there.

Scripts for creating mutually dependent libraries should indeed, if
they wish to use method 4, be prepared to filter out self-references.

But this is not an issue for libtool, since libtool on woe32 requires
the "-no-undefined" flag and therefore cannot be used to build mutually
dependent libraries.

Bruno


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

Re: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Danny Smith wrote:
> Thinking more about this, the whole problem goes away with
> -funit-at-a-time and that is turned on by default at 
> optimization level of 1 or higher.

Not the whole problem, only the case of a reference in the same compilation
unit as the definition of the variable.

> It seems that this problem is really a GCC vs MSVC compiler difference
> and it should be addressed in GCC rather in libtool.

The general case of a self-reference from another compilation unit inside
the same shared library cannot be addressed in GCC, without changing the
object file format. It needs to be done in the linker or in libtool.
Ralf explained why it's better done in libtool.

Bruno


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

Re: AW: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

> I would consider such a tool usable only
> if it had no arbitrary limits, such as a maximum size of 65000 bytes for
> an exports list

I have to eat my words: the exports list is _not_ limited in size by wgcc.
Sorry.

Bruno


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

Re: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

Ralf Wildenhues wrote:
> > > There is dangerous ambiguity.  In the past this kind of ambiguity
> > > cause most of the dllimport-related ICE's in GCC.
> > 
> > I assume that GCC has enough maintainers to fix ICEs inside GCC.
> 
> But it's not Libtool's job to push GCC, Libtool tries to encode what
> works in practice.

The proposed method has been tested in GNU gettext 0.15, which uses quite
a few variables marked dllimport, on both Cygwin and mingw, and neither I
nor Charles Wilson have seen a gcc ICE in the process. So, it appears
that _now_ it works.

Bruno


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

Re: libraries and namespaces

[Bruno Haible]

Ralf Wildenhues wrote on 2006-09-08:
> > > are you planning on providing a means to
> > > automatically rename gnulib functions to a library-specific namespace?
> > > As long as there is no policy on interface stability for gnulib, I would
> > > fear to see lots of libraries floating around that all carry some
> > > slightly incompatible version of some rather common symbol name around;
> > > when such issues arise, they tend to be a pain to debug.

I agree this can be a problem: we often do binary-incompatible changes
to gnulib functions, and if it resides in a library and the executable
uses a different version of the symbol, havoc will occur.

> > There is a problem only for documented libraries and for dependent libraries
> > of documented libraries.
> 
> No, this is _always_ a problem.  Let's have a very specific example:
> libgettextlib exports `gcd', undocumentedly.  I have a package where I
> provide my own `gcd' in a library, and it does something completely
> different, and use it in a program.  But I link against libgettextlib,
> possibly indirectly.

If you do link against libgettextlib, it must be a documented library;
if you link to it indirectly, it must be a dependent library of a
documented library.

My real fear is with libgettextpo, which is documented, and which includes
(directly or indirectly) ca. 20 gnulib modules.

> > Would you recommend to rename the functions at the C source code level?
> 
> That's the most portable method I know.
> 
> > Through #defines or asm directives?
> 
> Through #defines, for portability as well.

OK, I'm trying to do so. I've come up with a huge list of #defines, which
all prepend a prefix. But such a list cannot be maintained by hand. There
needs to be a way to generate it.

The situation is as follows: I have

  libgettextpo_SOURCES = \
external1.c external2.c ... \
internal1.c internal2.c ...

and I wish to export the symbols of external{i}.c without modifications,
whereas the symbols of internal{j}.c should get a prefix.

Approach 1: Preprocess the include files internal{j}.h so that each
occurrence of

 extern ret_type_t func (...);

is changed into

 #define func MY_PREFIX_func
 extern ret_type_t func (...);

Approach 2: Compile each of the internal{j}.c file to .o files, then
use "nm" to extract the exported symbols of each internal{j}.o, and
for each such symbol, append a line
 #define symbol MY_PREFIX_symbol
to config.h. Then remove the internal{j}.o files and restart the compilation
for real.

Which of the two approaches do you think is the most maintainable, least
painful, in the long run?

Bruno


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

Re: libraries and namespaces

[Bruno Haible]

Hello Paul,

Thanks for the advice.

> Did you consider doing it the way glibc does it, with the
> attribute_hidden macro?  Perhaps gnulib could use the same syntax as
> glibc, albeit with different semantics on other platforms.  If that
> doesn't suffice, there's also the syntax suggested by Niall Douglas
> 

This doesn't work on all platforms: It works only with gcc >= 4.0.

> > I wish to export the symbols of external{i}.c without modifications,
> > whereas the symbols of internal{j}.c should get a prefix.
> 
> Doesn't the question of whether a symbol should get a prefix more
> properly belong to .h files than to .c files?  That is, if it's
> declared in external{i}.h it should get exported, otherwise not.

Good point. Yes, ideally one should look only at the .h files. But it's
a bit hard to actually extract the symbols. For example, in gettext-po.h
I play tricks with symbol versioning:

  #define po_file_read po_file_read_v3
  extern po_file_t po_file_read (const char *filename,
 po_xerror_handler_t handler);

For my particular case, there's only one .c file that exports the API,
therefore one can assume that it doesn't export undocumented symbols.

> "nm" on the developer's platform, or on the installer's platform?
> ("nm" is a bit of a porting nightmare.)

"nm" on the installer's platform. 'lock.c' for example has different
exported symbols, depending on the platform. Likewise for 'error' and
'obstack': The #defines need to be activated in config.h only for those
platforms which don't have the error / obstack functionality already in libc.

The porting issue has already been done by the libtool folks. I can reuse
their AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE macro.

> For approach 1, can't you also put the #define into config.h as well?
> That way you don't need to modify the C source for approach 1 (just as
> in approach 2).

Yes. Good point. There's no need to rewrite internal include files;
config.h is sufficient.

Thanks again for your help!

Bruno


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

Re: m4/bootstrap

[Bruno Haible]

Ralf Wildenhues wrote:
> - Install Libtool.  Fix your $automake_prefix/share/aclocal/dirlist file
>   so that aclocal finds libtool's files, and $PATH so that it contains
>   libtoolize.  CVS Libtool has means in place to tell apart version
>   inconsistencies.
> 
> I'm not in favor of merging libtool into gnulib, and I would prefer if
> you would not "force" CVS users.  The added inconvenience would make me
> stop testing CVS M4 with CVS Libtool.

Eric, if you agree with that, how about documenting it in the bootstrap
script?

*** bootstrap   21 Sep 2006 13:07:02 -  1.31.2.4
--- bootstrap   2 Nov 2006 13:21:21 -
***
*** 35,42 
  
  # This script bootstraps a CVS checkout of GNU M4 by correctly
  # calling out to parts of the GNU Build Platform.  Currently this
! # requires GNU Autoconf 2.60, GNU Automake 1.9.6, and bleeding edge
! # CVS snapshots of GNU Gnulib.
  
  # Report bugs to 
  
--- 35,44 
  
  # This script bootstraps a CVS checkout of GNU M4 by correctly
  # calling out to parts of the GNU Build Platform.  Currently this
! # requires GNU Autoconf 2.60, GNU Automake 1.9.6, GNU Libtool 1.5.22
! # (either installed with the same --prefix as Automake, or made accessible
! # to aclocal's search path through $AUTOMAKE_PREFIX/share/aclocal/dirlist),
! # and bleeding edge CVS snapshots of GNU Gnulib.
  
  # Report bugs to 
  


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

Re: shared library symbol exports and versioning

[Bruno Haible]

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?

> 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.

Bruno


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

[sr #111195] Include libtool-next-version in the libtool distribution

[Bruno Haible]

URL:
  <https://savannah.gnu.org/support/?95>

 Summary: Include libtool-next-version in the libtool
distribution
   Group: GNU Libtool
   Submitter: haible
   Submitted: Di 25 Feb 2025 10:38:51 CET
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email:
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Di 25 Feb 2025 10:38:51 CET    By: Bruno Haible 
As maintainer of a package that ships a shared library, it is easy to make
mistakes when assigning a new libtool version triplet, while making a release.
(Doc node "Updating version info".)

To make this process more reliable, there is a program
gnulib/build-aux/libtool-next-version that improves this process
1) by asking the maintainer questions, so that they can focus on one thing at
a time,
2) by giving additional help to the maintainer (for example, by explaining
what constitutes an "interface" of the shared library),
3) by preparing default answers based on the set of symbols exported by the
shared library.

I am using this script for the GNU gettext and GNU libunistring releases of
the last 5 years, and it has avoid a mistake more than once.

Can we move this script to the libtool project, so that it would be
distributed as $(prefix)/bin/libtool-next-version ? Also, it would be nice if
the doc node "Updating version info" would reference this script.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?95>

___
Nachricht gesendet über Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[sr #111195] Include libtool-next-version in the libtool distribution

[Bruno Haible]

Follow-up Comment #3, sr #95 (group libtool):

Here's a proposed patch that adds the libtool-next-version program to the
libtool package, including documentation.

(file #56957)

___

Additional Item Attachment:

File name: 0001-New-program-libtool-next-version.patch Size: 20KiB




AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-513955078e56c124c506c834d031bbe09cbf4040.tar.gz


___

Reply to this item at:

  

___
Nachricht gesendet über Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[sr #111195] Include libtool-next-version in the libtool distribution

[Bruno Haible]

Follow-up Comment #5, sr #95 (group libtool):


> the formatting of libtool.texi for when newlines are used.

The placement of newlines was intentional: For 1-2 years now, in
documentation, I use "semantic newlines":
https://lists.gnu.org/r/help-texinfo/2023-05/msg6.html
https://lists.gnu.org/r/help-texinfo/2023-05/msg7.html
https://discuss.python.org/t/semantic-line-breaks/13874
It makes it much easier to understand what has changed in a doc commit, when
paragraphs are not reflown each time a simple change is made.

Feel free to reformat it, if you like to. Or feel free to keep it, as a guinea
pig section, to see if it pleases you in the long run like it pleases me :)

> this script addition is definitely worth adding a NEWS entry.

I agree. It would be nice if you could add that, in a subsequent commit.




___

Reply to this item at:

  

___
Nachricht gesendet über Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[sr #111195] Include libtool-next-version in the libtool distribution

[Bruno Haible]

Follow-up Comment #2, sr #95 (group libtool):


> Here is what I have for the documentation updates, but I would be happy to
> update with more detail

Thanks; I can work on expanding that.

> I am wondering why it should be moved from gnulib to libtool.

The script implements a "wizard" for a package maintainer who is using
libtool. Since the doc node "Updating version info" is in the libtool manual,
the natural place for it is in libtool.

The main reason that I added the script to gnulib in 2019 was that at that
time, libtool was essentially unmaintained. (The previous libtool release had
been in 2015.)

> It could probably be incorporated with the gnulib submodule rather than
> existing in the libtool repository.

Ugh, that would be backwards. The gnulib git repository serves as a place that
distributes individual files from various projects (config.guess from config,
install-sh from automake, texinfo.tex from texinfo, install.texi from
autoconf, mini-gmp.c from gmp, etc. This is for developer convenience,
especially for files that vary independently of releases. So, it would be
possible that gnulib mirrors the script from its upstream location in
libtool.

> Could you supply a patch for how you intend libtool to distribute the
> script?

Sure. I'll get to that tomorrow.


___

Reply to this item at:

  

___
Nachricht gesendet über Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature