Re: suggestion for installcheck support

a wrapper executable which finds the > dll installed in $(DESTDIR)$(bindir) when you do this. Please read my email entirely before replying to part of it. > I really don't see how directly invoking the C compiler and trying to > re-implement features which libtool already has is goin

Re: suggestion for installcheck support

hich finds the dll installed in $(DESTDIR)$(bindir) when you do this. > Therefore, using libtool for 'installcheck' is the wrong approach, > because it's not what packages do when they use the library. I really don't see how directly invoking the C compiler and trying to re-imp

Re: suggestion for installcheck support

Nick Bowler wrote: > Won't the problem of setting up shared library search paths be solved > if you just link the test program using libtool, so the usual wrapper > programs are generated to setup the platform-specific search paths? Most packages that *use* a library do so without using libtool. F

Re: suggestion for installcheck support

On Thu, Jun 19, 2025 at 05:44:59PM +0200, Bruno Haible via Discussion list for the GNU libtool shared library maintenance tool wrote: > In the past few days, I've added an 'installcheck' Makefile target to > GNU libiconv, GNU libunistring, GNU gettext, and GNU libsigsegv. > And that uncovered a co

Re: exported symbols of shared libraries on MSVC

, June 5, 2025 1:45 AM To: libtool@gnu.org Cc: Kirill Makurin Subject: Re: exported symbols of shared libraries on MSVC Hi Kirill, > If you look at commands executed by libtool when it creates a DLL, > you may see that it runs $NM on all object files which go into DLL. > Then it uses

Re: exported symbols of shared libraries on MSVC

Hi Kirill, > If you look at commands executed by libtool when it creates a DLL, > you may see that it runs $NM on all object files which go into DLL. > Then it uses some awk script to generate list of all `extern` symbols > defined in those object files. Libtool then appends each symbol with > `-l

Re: libtool installs the wrapper executable in MSVC with -O2 -GL options

After a few attempts, I summarized a much easier steps to reproduce this issue. I'm highly recommend that run in a VM. 1. Install vs_BuildTools.exe, and then just install C++ components 2. Install msys2 from https://www.msys2.org/ 3. Click "x64 Native Tools Command Prompt for VS" from start menu

Re: Build shared and static libs on the same run?

* On 2025 08 Apr 07:06 -0500, Simon Richter wrote: > Hi, > > On 4/8/25 18:29, Nate Bargmann wrote: > > > Normally the result is reversed. My observation is that whenever > > '--enable-static' is passed the shared libs are suppressed. The > > architecture I am using is what Debian calls 'amd64'

Re: Build shared and static libs on the same run?

Hi, On 4/8/25 18:29, Nate Bargmann wrote: Normally the result is reversed. My observation is that whenever '--enable-static' is passed the shared libs are suppressed. The architecture I am using is what Debian calls 'amd64' and other distributions call 'x86_64-linux-gnu'. Ah, configure.ac h

Re: Build shared and static libs on the same run?

* On 2025 07 Apr 20:39 -0500, simon.rich...@hogyros.de wrote: > Hi, > > if I remember correctly, you need to pass both --enable-static and > --enable-shared to get both. Hi Simon. That is an idea worth a try but it didn't work for me. The first indication is at the end of the 'configure' script

Re: Build shared and static libs on the same run?

Hi, if I remember correctly, you need to pass both --enable-static and --enable-shared to get both. On many systems, both are built with -fPIC now, to allow use of static libraries in position-independent executables, I'm not sure if libtool handles this efficiently, but it mostly means longer

Re: What is the purpose of CXX's and FC's predeps, postdeps, and friends?

Hi Christian, On 18/02/2025 10:49, Christian Feld wrote: Dear libtoolers, the macro _LT_SYS_HIDDEN_LIBDEPS sets the _LT_TAGDECLs   predep_objects,   postdep_objects,   predeps (always empty),   postdeps,   compiler_lib_search_dirs, and   compiler_lib_search_path. _LT_SYS_HIDDEN_LIBDEPS

Re: libtool on AIX - soname feature inconsistent?

On 09/12/2024 17:57, Ben Huntsman wrote: Hi everyone-    Just wanted to bring this up again.  Is there a formal procedure for filing a bug?  Anyone here who is more familiar with the libtool codebase and would have some advice on how to fix this? Here [1] is some documentation for contributi

Re: libtool on AIX - soname feature inconsistent?

@gnu.org on behalf of Ben Huntsman Sent: Saturday, November 30, 2024 3:48 PM To: Nick Bowler Cc: libtool@gnu.org Subject: Re: libtool on AIX - soname feature inconsistent? Hi there! Thank you for confirming my findings. That was exactly what I was seeing. Now the question is, how do

Re: libtool-2.5.4 released [stable]

Hi everyone! I just want to say that I appreciate all of the thank you emails I have received for the latest release of GNU Libtool. It has not been an easy project to maintain, but it has been a fun challenge for me. Also, thank you to everyone who has helped submit bugs and patches to GNU Libt

Re: libtool on AIX - soname feature inconsistent?

From: Nick Bowler Sent: Thursday, November 28, 2024 9:33 AM To: Ben Huntsman Cc: libtool@gnu.org Subject: Re: libtool on AIX - soname feature inconsistent? On 2024-11-27 01:01, Ben Huntsman wrote: > In particular, I noticed that if you add libtool to a project

Re: libtool on AIX - soname feature inconsistent?

On 2024-11-27 01:01, Ben Huntsman wrote: > In particular, I noticed that if you add libtool to a project by > calling LT_INIT, and then run ./configure with the > --with-aix-soname=svr4, the .la files that get produced with the > library_names='whatever.so.3 whatever.so', but if you call > LT_INIT(

Re: Dynamic libraries on OpenBSD

On 24/10/2024 06:37, Artemis Tosini wrote: Hello, I'm working on a tool for cross-compiling an OpenBSD system from Linux and libtool is causing some issues with shared libraries. My Linux system doesn't have `/usr/libexec/ld.so`, so libtool always claims that the target does not support share

Re: Some questions about use libtool when linking

On 08/10/2024 18:31, Kun Yang wrote: Greetings, I'm intended to update libtool package for MSYS2, but some troubles occurred that beyond my ability. I'm confused by some flags when linking. Compared to v2.4.7, libtool now accepts more flags when linking. The most of the flags in https://githu

Re: Some questions about use libtool when linking

Oh, I'm sorry for the confusing mail, it was truncated and combined by with 80 column limit. Here is the right commands. libtool --version | head -1 echo "void foo(void) {}" >foo.c libtool --mode=compile --tag=CC cc -c foo.c  -o foo.lo    -O3 -ffast-math libtool --mode=link    --tag=CC cc    fo

Re: Issue with added '-threads' added while using Intel 2024.0.0 C compiler icx

Hello, I'm sorry for top posting. Multithread library does not mean that program(utility,command,application) is multithreaded. From my point of view libraries must not export information for threads. This could be from either shell config-script, or "package-config file, or predefined autoc

Re: Issue with added '-threads' added while using Intel 2024.0.0 C compiler icx

On 2024-08-23 13:35, Witold Interewicz wrote: > I have 2 Qs here: > - What is (in short/sketch) the set of conditions that causes libtool > to add this switch '-threads' (or where may I read about it)? It could be coming from another library you are using. For example, some libtool library (.la f

Re: Replacing ar with libtool

On Sat, 10 Aug 2024, Simon Richter wrote: Libtool supports "convenience libraries", which are unpacked and repacked automatically to merge all objects to a single large library. That takes a bit of extra time in a build and cannot be parallelized either, but in large projects it makes the Mak

Re: Replacing ar with libtool

Hi, On 8/10/24 20:08, Navin P wrote: When i run make -j1 i find all the object files  libx.a but when i do make -j8 i find some missing object files inside libx.a. Typically you'd generate all objects first, then archive them in a single invocation. This is I/O bound anyway, so you're not lo

Re: libtool-2.5.1 released [beta]

Hi Richard, On 09/08/2024 17:41, Richard Purdie wrote: On Fri, 2024-07-26 at 19:13 +0300, Ileana Dumitrescu wrote: On 26/07/2024 03:26, Bruno Haible wrote: 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

Re: libtool-2.5.1 released [beta]

On Fri, 2024-07-26 at 19:13 +0300, Ileana Dumitrescu wrote: > On 26/07/2024 03:26, Bruno Haible wrote: > > 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;

Re: libgcc crossback fails

configure: error: in `/home/cqwrteur/toolchains_build/toolchainbuildscripts/gccbuild/x86_64-w64-mingw32/.gnuartifacts/x86_64-generic-linux-gnu/x86_64-w64-mingw32/x86_64-generic-linux-gnu/gcc/x86_64-generic-linux-gnu/32/libgcc': configure: error: C preprocessor "/lib/cpp" fails sanity check See `co

Re: libgcc crossback fails

___ From: pifminns deettnta Sent: Monday, August 5, 2024 02:40 To: gcc-h...@gnu.org Subject: Re: libgcc crossback fails Config.log is generated ridiculously. From: pifminns deettnta Sent: Monday, August 5, 2024 02:30 To: gcc-h...@gnu.org Subject: Fw: libgcc cro

Re: libtool-2.5.1 released [beta]

Hi Bruno! On 26/07/2024 03:26, Bruno Haible wrote: 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 I am happy to hear that, and thank you for

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

Re: -no_fixup_chains patch

On 05/07/2024 21:53, Gary V. Vaughan wrote: On Jul 5, 2024, at 8:05 AM, Ileana Dumitrescu wrote: On 04/07/2024 20:55, Gary V. Vaughan wrote: On Jul 2, 2024, at 12:01 PM, Václav Haisman wrote: On 28. 06. 24 0:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message f

Re: -no_fixup_chains patch

> On Jul 5, 2024, at 8:05 AM, Ileana Dumitrescu > wrote: > > On 04/07/2024 20:55, Gary V. Vaughan wrote: >>> On Jul 2, 2024, at 12:01 PM, Václav Haisman wrote: >>> >>> On 28. 06. 24 0:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message from my inbox] Rega

Re: -no_fixup_chains patch

On 04/07/2024 20:55, Gary V. Vaughan wrote: On Jul 2, 2024, at 12:01 PM, Václav Haisman wrote: On 28. 06. 24 0:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e.   http://git.savannah.gnu.org/gitweb/?p=libtool.

Re: -no_fixup_chains patch

> On Jul 2, 2024, at 12:01 PM, Václav Haisman wrote: > > On 28. 06. 24 0:41, Ozkan Sezer wrote: >> [Sorry, I seem to have deleted the mailing list message from my inbox] >> Regarding -no_fixup_chains patch i.e. >> >> http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90

Re: -no_fixup_chains patch

On Thu, Jul 4, 2024 at 4:54 PM Ileana Dumitrescu wrote: > > On 03/07/2024 21:28, Ozkan Sezer wrote: > > On Wed, Jul 3, 2024 at 6:42 PM Ileana Dumitrescu > > wrote: > > However, if you guys do this: AS_VAR_APPEND requires autoconf 2.64. What > > is the minimum required autoconf version for libtool

Re: -no_fixup_chains patch

On 03/07/2024 21:28, Ozkan Sezer wrote: On Wed, Jul 3, 2024 at 6:42 PM Ileana Dumitrescu wrote: On 02/07/2024 22:01, Václav Haisman wrote: On 28. 06. 24 0:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e. htt

Re: -no_fixup_chains patch

On Wed, Jul 3, 2024 at 6:42 PM Ileana Dumitrescu wrote: > > On 02/07/2024 22:01, Václav Haisman wrote: > > On 28. 06. 24 0:41, Ozkan Sezer wrote: > >> [Sorry, I seem to have deleted the mailing list message from my inbox] > >> > >> Regarding -no_fixup_chains patch i.e. > >> > >> http://git.savanna

Re: -no_fixup_chains patch

On 02/07/2024 22:01, Václav Haisman wrote: On 28. 06. 24 0:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e. http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90a6b9e16c545babe833f28dca1

Re: flang compiler and wrappers

On 03/07/2024 17:41, Shterenlikht, Anton wrote: On 3 Jul 2024, at 15:17, Ileana Dumitrescu wrote: Hi Anton, On 03/07/2024 16:40, Shterenlikht, Anton wrote: Hello Ileana It seems your original patch is good, To make sure I understand, is the original patch that worked for you the one appl

Re: flang compiler and wrappers

> On 3 Jul 2024, at 15:17, Ileana Dumitrescu > wrote: > > Hi Anton, > > On 03/07/2024 16:40, Shterenlikht, Anton wrote: >> Hello Ileana >> It seems your original patch is good, > > To make sure I understand, is the original patch that worked > for you the one applied here: > https://git.sav

Re: flang compiler and wrappers

Hi Anton, On 03/07/2024 16:40, Shterenlikht, Anton wrote: Hello Ileana It seems your original patch is good, To make sure I understand, is the original patch that worked for you the one applied here: https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=master&id=33d4b69fccbbb557c1160cc46c

Re: flang compiler and wrappers

Hello Ileana It seems your original patch is good, provided I add autoreconf -fiv -Wall or similar. My problem was in building netcdf. However, on closer inspection, I noticed that the patched libtool was not picked up, for some reason: 40 # Which release of libtool.m4 was used? 41 mac

Re: -no_fixup_chains patch

On 28. 06. 24 0:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e. http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90a6b9e16c545babe833f28dca155a7 Is '+=' universally supported?? Maybe

Re: [PATCH] fix appending of -no_fixup_chains to _lt_dar_allow_undefined

On 29/06/2024 17:58, Ozkan Sezer wrote: With current development branch, 'allow_undefined_flag' in the libtool script generated after running configure looked like this: allow_undefined_flag="\$_lt_dar_allow_undefined \$wl-no_fixup_chains" The solution I ended up with and applied in SDL is the

Re: flang compiler and wrappers

On 28/06/2024 08:56, Shterenlikht, Anton wrote: On 27 Jun 2024, at 17:36, Ileana Dumitrescu wrote: On 26/06/2024 10:21, Shterenlikht, Anton wrote: Please help understand and fix this problem: libtool: link: ftn -shared -soname libxxx.so.0 -o .libs/libxxx.so.0.0.0 clang-16: error: unkn

Re: -no_fixup_chains patch

On 28/06/2024 01:41, Ozkan Sezer wrote: [Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e. http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90a6b9e16c545babe833f28dca155a7 Is '+=' universally supported?? Maybe

Re: flang compiler and wrappers

> On 27 Jun 2024, at 17:36, Ileana Dumitrescu > wrote: > > On 26/06/2024 10:21, Shterenlikht, Anton wrote: >> Please help understand and fix this problem: >> libtool: link: ftn -shared -soname libxxx.so.0 -o >> .libs/libxxx.so.0.0.0 >> clang-16: error: unknown argument: '-soname' >> whic

Re: -no_fixup_chains patch

[Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e. http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90a6b9e16c545babe833f28dca155a7 Is '+=' universally supported?? Maybe change to something like the following??

Re: flang compiler and wrappers

On 26/06/2024 10:21, Shterenlikht, Anton wrote: Please help understand and fix this problem: libtool: link: ftn -shared -soname libxxx.so.0 -o .libs/libxxx.so.0.0.0 clang-16: error: unknown argument: '-soname' which comes from my compiler wrapper not recognised. Sorry for missing your ea

Re: [sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker

On 27/06/2024 18:28, Ozkan Sezer wrote: On Thu, Jun 27, 2024 at 5:29 PM Ileana Dumitrescu wrote: Follow-up Comment #16, sr #111069 (group libtool): I have updated development with a feature test: https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=3d1baeeef90a6b9e16c545bab

Re: [sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker

On Thu, Jun 27, 2024 at 5:29 PM Ileana Dumitrescu wrote: > > Follow-up Comment #16, sr #111069 (group libtool): > > I have updated development with a feature test: > > https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=3d1baeeef90a6b9e16c545babe833f28dca155a7 > > Please tell me

Re: [sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker

On 21/06/2024 21:36, Ozkan Sezer wrote: I have merged a patch in the development branch to append '-no_fixup_chains' for macOS versions 11.3*-14* and Xcode versions 13-15*. I have verified this removes the warning that I was seeing on macOS 12.7.5, Xcode 14.2.0.0.1.1668646533 [1][2]. I have not s

Re: [sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker

> I have merged a patch in the development branch to append '-no_fixup_chains' > for macOS versions 11.3*-14* and Xcode versions 13-15*. I have verified this > removes the warning that I was seeing on macOS 12.7.5, Xcode > 14.2.0.0.1.1668646533 [1][2]. I have not seen any regressions from this on >

Re: Add missing sysroot to library path ?

On 31/05/2024 17:47, Joakim Tjernlund wrote: On Thu, 2024-05-30 at 18:10 +0300, Ileana Dumitrescu wrote: On 29/05/2024 16:27, Joakim Tjernlund wrote: Ping ? On Wed, 2024-01-31 at 19:53 +0200, Ileana Dumitrescu wrote: On 31/01/2024 17:15, Joakim Tjernlund wrote: Has some variant of https://l

Re: Add missing sysroot to library path ?

On Thu, 2024-05-30 at 18:10 +0300, Ileana Dumitrescu wrote: > On 29/05/2024 16:27, Joakim Tjernlund wrote: > > Ping ? > > > > On Wed, 2024-01-31 at 19:53 +0200, Ileana Dumitrescu wrote: > > > On 31/01/2024 17:15, Joakim Tjernlund wrote: > > > > Has some variant of > > > > https://lists.gnu.org/ar

Re: some options still missing?

On 31/05/2024 14:42, Joakim Tjernlund wrote: On Mon, 2024-05-20 at 17:06 +0200, Joakim Tjernlund wrote: This fix seems to have been lost: https://lists.gnu.org/archive/html/libtool-patches/2019-05/msg0.html Ping? I think the current state in libtool is that static ASAN works for LLVM now

Re: some options still missing?

On Mon, 2024-05-20 at 17:06 +0200, Joakim Tjernlund wrote: > This fix seems to have been lost: > https://lists.gnu.org/archive/html/libtool-patches/2019-05/msg0.html Ping? I think the current state in libtool is that static ASAN works for LLVM now but not for gcc as gcc has libasan/libubsan e

Re: Add missing sysroot to library path ?

On 29/05/2024 16:27, Joakim Tjernlund wrote: Ping ? On Wed, 2024-01-31 at 19:53 +0200, Ileana Dumitrescu wrote: On 31/01/2024 17:15, Joakim Tjernlund wrote: Has some variant of https://lists.gnu.org/archive/html/libtool-patches/2022-04/msg00010.html been discussed/considered ? Joakim Th

Re: Number of tests in GNU Libtool 2.4.7 test suite

Hi, On 20/05/2024 14:22, mjjm 1.14.2 wrote: Hello dear developers and programmers and maintainers of GNU Libtool. I just wanted to know how many tests are there in GNU Libtool 2.4.7 test suite? Its already a few hours since I've run the make -k check command. I'm already in the 87th test, I w

Re: How to force libtool to use CXX mode?

On 2024-05-14 17:02, Bob Friesenhahn wrote: > Since it is not allowed to wrap a target replacement in an Automake > condition, I am finding it necessary to write new rules which use > variables that I define. I think it works despite the strange warning about multiple targets? But regardless, you

Re: How to force libtool to use CXX mode?

On 5/13/24 20:52, Bruno Haible wrote: 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 w

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: How to force libtool to use CXX mode?

On 5/13/24 16:37, Karl Berry wrote: convince Automake to force libtool to link using the C++ compiler When there are no C++ sources? Why? Just trying to understand ... There are no C++ sources from my project, but there is a C++ compiler used for the overall build. As clarification, this i

Re: How to force libtool to use CXX mode?

convince Automake to force libtool to link using the C++ compiler When there are no C++ sources? Why? Just trying to understand ... I'm sorry Bob, but I just don't know. Maybe the just-released libtool-2.5.0 alpha offers some new help? If there is some bug in or feature for Automake that wo

Re: Installation of libtool-2.4.7 from source

You can set datadir by running "./configure --datadir=/usr/opt" when you build libtool. datadir is responsible for setting the path to /usr/local/share/. This should fix the issue. Alternatively, you could manually patch libtoolize with this: --- build/libtoolize2024-04-23 18:38:01.944324133

Re: Next libtool release?

On 18/04/2024 21:52, Joakim Tjernlund wrote: What happened to the release? Joakim The release has been delayed since I have not received a confirmation email from ftp-upload administrators that the Automated Upload Registration is complete. I am sure they have been busy, and I assure you th

Re: .la file dependency_libs dropping sole -lm dependency

Well this definitely looks like a bug. I can't imagine any reason that would be correct. I'm trying to reproduce it now, with GraphicsMagick. I filed a bug [1]. Thanks for the detailed report! Thank you very much for volunteering to be a libtool maintainer. You would need latest GraphicsMagic

Re: .la file dependency_libs dropping sole -lm dependency

On 31/01/2024 17:33, Bob Friesenhahn wrote: The libtool used reports itself as   % /usr/local/bin/libtool --version   libtool (GNU libtool) 2.4.7   Written by Gordon Matzigkeit, 1996   Copyright (C) 2014 Free Software Foundation, Inc. which I think is confusing since the tarball date is

Re: .la file dependency_libs dropping sole -lm dependency

On 31/01/2024 20:57, Bob Friesenhahn wrote: On Wed, 31 Jan 2024, Bob Friesenhahn wrote: bin/bash ./libtool  --tag=CXX --mode=link g++-10 -no-undefined -export-symbols-regex ".*"  -version-info 27:4:24 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -o magick/libGraphicsMagick.la -rpath /usr/loc

Re: .la file dependency_libs dropping sole -lm dependency

On Wed, 31 Jan 2024, Bob Friesenhahn wrote: bin/bash ./libtool --tag=CXX --mode=link g++-10 -no-undefined -export-symbols-regex ".*" -version-info 27:4:24 -L/usr/local/lib -Wl,-rpath,/usr/local/lib -o magick/libGraphicsMagick.la -rpath /usr/local/lib [ list of .lo files ] -lm An I misunde

Re: Add missing sysroot to library path ?

On 31/01/2024 17:15, Joakim Tjernlund wrote: Has some variant of https://lists.gnu.org/archive/html/libtool-patches/2022-04/msg00010.html been discussed/considered ? Joakim The patchset seems good, and that particular patch was most likely forgotten about. I'll look through the thread and

Re: Introducing a new maintainer of libtool

On 18 Jan 2024 11:25, Ozkan Sezer wrote: > On 1/18/24, Mike Frysinger wrote: > > On 17 Jan 2024 20:07, Ozkan Sezer wrote: > [...] > >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 > > > > doesn't look like a regression. it can wait. > > It's a regression from 2.2.6, later versions have th

Re: Introducing a new maintainer of libtool

On 18/01/2024 08:41, Mike Frysinger wrote: i was looking in HACKING & README & the manual & in a clean tree. if you bootstrap, you get the README-release file which explains things. i posted 2 patches which fix `make distcheck` for me. i'll wait a little to see if there's any feedback on them

Re: Introducing a new maintainer of libtool

On 1/18/24, Mike Frysinger wrote: > On 17 Jan 2024 20:07, Ozkan Sezer wrote: [...] >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 > > doesn't look like a regression. it can wait. It's a regression from 2.2.6, later versions have the issue, so how is it not a regression?

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 18:43, Mike Frysinger wrote: > On 17 Jan 2024 16:09, Ileana Dumitrescu wrote: > > 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 da

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 16:09, Ileana Dumitrescu wrote: > 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. there doesn't seem to be libtool-specific relea

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 20:07, Ozkan Sezer wrote: > Please remember to check with debbugs.gnu.org: > https://debbugs.gnu.org/cgi/pkgreport.cgi?package=libtool;max-bugs=100;base-order=1;bug-rev=1 > > There are plenty of bugs in there. E.g.: we're always going to have a bug backlog. if there's something sp

Re: Introducing a new maintainer of libtool

On 17/01/2024 19:07, Ozkan Sezer wrote: Please remember to check with debbugs.gnu.org: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=libtool;max-bugs=100;base-order=1;bug-rev=1 There are plenty of bugs in there. E.g.: Yes, there's quite a lot that have piled up. I'll do my best to triage

Re: Introducing a new maintainer of libtool

On 2024-01-17 20:07:55 +0300, Ozkan Sezer wrote: > Please remember to check with debbugs.gnu.org: > https://debbugs.gnu.org/cgi/pkgreport.cgi?package=libtool;max-bugs=100;base-order=1;bug-rev=1 > > There are plenty of bugs in there. E.g.: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 >

Re: Introducing a new maintainer of libtool

Please remember to check with debbugs.gnu.org: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=libtool;max-bugs=100;base-order=1;bug-rev=1 There are plenty of bugs in there. E.g.: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738 https://deb

Re: Introducing a new maintainer of libtool

On 17 Jan 2024 15:56, Simon Josefsson wrote: > Looking at that, it seems the bootstrap and bootstrap.conf scripts are > really old. seems like they're up-to-date to me. it's using the fork: https://github.com/gnulib-modules/bootstrap > Do we have any GitLab CI/CD testing for libtool? there is n

Re: Introducing a new maintainer of libtool

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

Re: Introducing a new maintainer of libtool

> 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

Re: Introducing a new maintainer of libtool

On 2024-01-16 15:44:08 -0500, Mike Frysinger wrote: > 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 v

Re: Introducing a new maintainer of libtool

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

Re: Introducing a new maintainer of libtool

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 b

Re: [PATCH] libtool: Use AC_CHECK_PROG instead of AC_CHECK_TOOL to find "find"

lgtm -mike signature.asc Description: PGP signature

Re: [PATCH] libtool: Use AC_CHECK_PROG instead of AC_CHECK_TOOL to find "find"

Hello, I got the Subject wrong, it must read: libtool: Use AC_CHECK_PROG instead of AC_CHECK_TOOL to find "file" (i.e. s/"find"/"file"/) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 30 Nov 2023 22:45, Nick Bowler wrote: > Interestingly the libtool manual also says "If [libtool] can't infer a > tag, then it defaults to the configuration for the C language", which is > clearly not the case (it seems what actually happens is that if libtool > can't infer a tag then it exits

Re: libtool using AC_CHECK_TOOL to find file

On 25 Oct 2023 20:24, Uwe Kleine-König wrote: > while cross-building a package I noticed a warning emitted by configure: > > ... > checking for arm-v7a-linux-gnueabihf-file... no > checking for file... file > configure: WARNING: using cross tools not prefixed with host trip

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get

Re: stable release from 2.4.7 branch?

On 2023-10-22 10:48, Shterenlikht, Anton wrote: > I'm working on > > https://savannah.gnu.org/support/index.php?110947 > > and tried the development version from git. > > That version identifies itself as > > $ libtool --version > libtool (GNU libtool) 2.4.7.4-1ec8f > > yet the latest stable versi

Re: stable release from 2.4.7 branch?

> On 22 Oct 2023, at 15:48, Shterenlikht, Anton > wrote: > > I'm working on > > https://savannah.gnu.org/support/index.php?110947 > > and tried the development version from git. > > That version identifies itself as > > $ libtool --version > libtool (GNU libtool) 2.4.7.4-1ec8f > > yet th

Re: armflang: error: unknown argument: '-soname'

For comparison, here's how the same line looks like when I use gfortran: libtool: link: gfortran -shared -fPIC -g -O2 -Wl,-soname -Wl,libp2.so.0 -o .libs/libp2.so.0.0.0 > On 19 Oct 2023, at 19:20, Shterenlikht, Anton > wrote: > > Please help me understand how to deal correctly with t

Re: shrext_cmds get passed literally into user code

On Mon, Jul 31, 2023 at 7:18 PM Eric Gallager wrote: > > I am on Darwin, where libtool sets shrext_cmds to `test .$module = > .yes && echo .so || echo .dylib`. In the project's configure.ac, there > is code that does this: > > AC_DEFINE_UNQUOTED([SHARED_LIB_EXT],["${shrext_cmds}"], >

Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin

Sorry for necroreply. When *cross* compiling from Cygwin to MinGW (read: native Windows) the different "--build" and "--host" must be used, like --build=x86_64-pc-cygwin --host=x86_64-w64-mingw32 or --build=x86_64-pc-cygwin --host=x86_64-pc-mingw64 as you are building is on Cygwin, not on MinGW

Re: libtool (use with autotest)

Thank you for the feedback, I may need to make this clearer Am 24.07.2023 um 22:01 schrieb Nick Bowler: On 2023-07-24, Simon Sobisch wrote: [...] Am 06.07.2023 um 14:55 schrieb Jose E. Marchesi: On 2023-07-03 17:16:59 +0200, Bruno Haible wrote: Someone wrote: Without relinking at in

Re: libtool (use with autotest)

On 2023-07-24, Simon Sobisch wrote: > > I hope to possibly get an answer by moving this question to the > appropriate lists :-) > For more context I provide the original responses to this topic. > > Am 06.07.2023 um 14:55 schrieb Jose E. Marchesi: >> >>> On 2023-07-03 17:16:59 +0200, Bruno Haible

Re: [opensoftware] [sr #110849] make check darwin.at test fails on Linux

> Was this run on a git checkout or distribution tarball? tarball: https://ftp.gnu.org/gnu/libtool/libtool-2.4.7.tar.gz > You bring up a good question. If it's a git checkout I think it makes sense > to run these since it may detect potential portability issues for Darwin > hosts that are obser

Re: [sr #110849] make check darwin.at test fails on Linux

Was this run on a git checkout or distribution tarball? You bring up a good question. If it's a git checkout I think it makes sense to run these since it may detect potential portability issues for Darwin hosts that are observable from Linux systems. It may also make sense to run some of these tes

  1   2   3   4   5   6   7   8   9   10   >