use of libtool for linking executables - rpath problem

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 u

Re: use of libtool for linking executables - rpath problem

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 pleas

Re: use of libtool for linking executables - rpath problem

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)

Re: use of libtool for linking executables - rpath problem

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

Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

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 >

libtool-next-version: new program

ferent 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 B

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

/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]

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

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 versio

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

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 "Opt

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

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

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

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: ___

Re: How to force libtool to use CXX mode?

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 GraphicsMag

Re: libtool-2.5.1 released [beta]

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

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/archi

[sr #111011] restore shared library support on Android

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 softw

[sr #111011] restore shared library support on Android

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/pr

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

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

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

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, a

Re: libtool file naming conventions

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

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

kes 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),

Re: use of -fno-common on Darwin

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

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

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_CO

Re: Compiling with MinGW

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

improve support for building DLLs on cygwin and mingw

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 i

Re: improve support for building DLLs on cygwin and mingw

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_ex

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

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

Re: libraries and namespaces

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

Re: improve support for building DLLs on cygwin and mingw

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

Re: improve support for building DLLs on cygwin and mingw

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 see

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

> 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://

Re: improve support for building DLLs on cygwin and mingw

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

Re: libraries and namespaces

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 al

Re: libraries and namespaces

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

Re: m4/bootstrap

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 libt

Re: shared library symbol exports and versioning

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 inform

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

: 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 v

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

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

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

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

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

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