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

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

[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 #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

[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

Re: [patch #10393] Fix shared library support on Android

Roumen Petrov wrote: > Android and Microsoft windows must not encode any paths. You probably mean to say: Shared libraries packaged in Android .apk files are mentioned in the Android manifest file (elements and ) [1] and therefore don't need a RUNPATH. But shared libraries created in the Termux

Re: [patch #10393] Fix shared library support on Android

Roumen Petrov wrote: > Android and Microsoft windows libraries must not use hard coded paths! > Nevertheless what is supported by linker or loader. Why do you mention Microsoft Windows? The commit 47c71f61df9ace4956cc943f291480315174726b has no effect on Microsoft Windows. > When I read commit

[patch #10393] Fix shared library support on Android

mments: --- Date: Mon 18 Sep 2023 01:25:06 PM CEST By: Bruno Haible On Android, within the termux environment, I encountered two problems during the "make install" phase of GNU gettext. The attached patch fixes them. 1) On this platform, libtool is conf

[patch #10387] Recognize the *-*-windows* config triplets introduced on 2023-06-26

low-up Comments: --- Date: Wed 30 Aug 2023 02:18:09 PM CEST By: Bruno Haible Through this commit to config.sub https://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=91f6a7f616b161c25ba2001861a40e662e18c4ad the host_os values windows*

[patch #9467] Fix -export-symbols and -export-symbols-regex support on Solaris 11.3

Follow-up Comment #1, patch #9467 (project libtool): This patch is also needed for Solaris 11.4. ___ Reply to this item at: ___ Message sent via

[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] try

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 Bruno

[patch #9467] Fix -export-symbols and -export-symbols-regex support on Solaris 11.3

Additional Item Attachment, patch #9467 (project libtool): File name: 0001-Fix-export-symbols-and-export-symbols-regex-support-.patch Size:0 KB ___ Reply to this item at:

[patch #9467] Fix -export-symbols and -export-symbols-regex support on Solaris 11.3

URL: Summary: Fix -export-symbols and -export-symbols-regex support on Solaris 11.3 Project: GNU Libtool Submitted by: haible Submitted on: Sat 21 Oct 2017 02:40:53 PM CEST Category:

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

Re: [bug-libunistring] Fix quoting in exported.sh.in, allow multiple arguments.

-quote $lt_cv_sys_global_symbol_pipe for eval, like we do in ltmain, in order to preserve TABs and multiple adjacent whitespace. Report by Bruno Haible. There are 5 more occurrences of this idiom, IMO, at lines 4127, 4142, 4145, 4158, 4288, but I'm not sure whether the way

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

Re: libtool --mode=execute gdb

Ralf Wildenhues wrote: That let me check in more detail. Mode inference was removed here: http://lists.gnu.org/archive/html/libtool-patches/2003-09/msg00062.html and deprecated here: http://lists.gnu.org/archive/html/libtool-patches/2002-11/msg7.html The removal did not apply to the

portability of -Lrelative_directory_name

Hi, A while ago someone said that if in a build directory I have a (not yet installed) ../lib/libfoo.la, to link with this library I should *not* use libtool ... -L../lib -lfoo but rather mention the .la file explicitly: libtool ... -L../lib ../lib/libfoo.la or libtool ...

libtool runs compiler command in wrong locale

to commands that run a program, not to shell builtins like eval ... or (cd ... ...). Bruno 2008-01-20 Bruno Haible [EMAIL PROTECTED] * ltmain.in (lt_env): New variable. Use it when running commands. *** ltmain.in.bak 2007-06-24 03:30:51.0 +0200 --- ltmain.in 2008-01-20 17:11

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 libtool

Re: strings.h in argz.c?

Simon Josefsson wrote: I assume that memory.h is a side-effect of using strings.h, and that memory.h is not needed today either? Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11, OSF/1 4.0, the contents of memory.h is also available through string.h. Bruno

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: 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 all carry

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 works in

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 seems

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 ___

Re: improve support for building DLLs on cygwin and mingw

Danny Smith wrote: quote ... there is no need any more for this warning. gcc should remove this warning. /quote 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

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 the

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

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 that

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

Ralf Wildenhues wrote: Yes. HP-UX /bin/sh is known to dump core in case `command that produces more than 1 KB of output` in and I don't know how much output other compilers generate when given the -V option. But say, why is that HP-UX shell issue not listed in the Autoconf

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

Ralf Wildenhues wrote: and note that with C++, your patch sets ${wl} to `-Qoption ld ' as well, not to `-Wl,'. Yes. Indeed I don't know whether -Qoption ld arg1,arg2,arg3will pass arg1, arg2, arg3 separately to the linker or glued together. I hope the tests in libtool HEAD will detect

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

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

support for SunPRO C/C++ on Linux

testsuite passes as well. 2006-05-05 Bruno Haible [EMAIL PROTECTED] * libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG): 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

Re: new module 'ldd'

[redirected to bug-libtool, from bug-gnulib] Ralf Wildenhues wrote: The fact that a libtool created program is not actually a program but a script, is a problem of libtool. Fix that, then we can also use gdb program instead of the surprising syntax libtool gdb program. Two comments: I

Re: libtool patch from gettext

Ralf Wildenhues wrote: The first one below I'd like to apply: return error from cwrapper if exec*() failed (all branches). 2003-11-27 Bruno Haible [EMAIL PROTECTED] * config/ltmain.sh (cwrappersource): return 127 if exec failed. Yes, that matches the standard convention about exit

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

, 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

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 I have

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

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

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

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) has this