Introducing a new maintainer of libtool

Hi all, I am Ileana Dumitrescu, a new maintainer of libtool. To give some background on myself, I have been contributing to Debian over the past few years. Presently, I am a Debian Maintainer and the maintainer for zvbi, which utilizes libtool. To reference my application email: "

Re: Introducing a new maintainer of libtool

amed as maintainer, and there were similar opinions on getting a release out quickly. I'll need some time figuring out the release process, but otherwise I should be able to get an alpha release out soon. Mike has been helpful and has merged in many patches over the past few days. --

Re: Introducing a new maintainer of libtool

to triage and address them when possible. Patches are always appreciated. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

Re: Introducing a new maintainer of libtool

load the alpha [1]. [1] https://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

[sr #108637] libtool adds -rpath to staging directory

Update of sr#108637 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Reply to this item at:

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

Follow-up Comment #3, sr#110674 (group libtool): Makes sense. We could change this after the next release. It does seem odd now that I'm looking at it. ___ Reply to this item at: _

Re: Add missing sysroot to library path ?

ain.in. Somehow, I'd previously missed that. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

Re: .la file dependency_libs dropping sole -lm dependency

same thing happens under Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. Bob 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! [1] https://debbugs.gnu.org/c

Re: .la file dependency_libs dropping sole -lm dependency

of Libtool the copyright will be up to date. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Update of sr#108201 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #32: Did some digging and gcc appears to have solved the issue themselves[1]. >From GCC commit 6ee5892

[sr #109514] ltmain.sh: [_MSC_VER] should be [_WIN32] in one place

Update of sr #109514 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you! A similar patch was submitted and applied [1]. [1] https://savannah.gnu.org/patch/inde

[sr #111038] QNX version_type handling is wrong

Update of sr #111038 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you for the patch! It has been merged in.

Re: Next libtool release?

that I have not forgotten about the release :) I plan to release a beta prior to the release (maybe even an alpha), so the official release will not be out for at least several months. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

Re: Installation of libtool-2.4.7 from source

/usr/local/share/libtool" - aclocaldir="/usr/local/share/aclocal" + datadir="/usr/opt" + pkgauxdir="/usr/opt/libtool/build-aux" + pkgltdldir="/usr/opt/libtool" + aclocaldir="/usr/opt/aclocal" # Allow the user to override the master libt

GNU Libtool thanks and updates

l/ci-check -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

Re: Number of tests in GNU Libtool 2.4.7 test suite

th test, I wonder how many are still there left. Thank you so much. There are 169 tests in GNU Libtool 2.4.7 testsuite, and it usually takes about 15 minutes to test on Debian and Ubuntu. Depending on the OS and architecture you are on, it can take a couple hours to complete. -- Ileana Dumit

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

Re: some options still missing?

but not for gcc as gcc has libasan/libubsan etc. rather than one libsan library. I actually started testing this patch yesterday. It has been applied to the development branch now, and it will soon be in master. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F

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

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

Follow-up Comment #8, sr #111069 (group libtool): Thanks for the discussion. If you could modify this patch to include a linker version check that should be sufficient. I do not think a feature test is necessary since the behaviour seems rigidly defined between linker versions, and these fixup ch

[sr #111081] Cannot find shared libraries with aarch64-w64-mingw32.

Follow-up Comment #1, sr #111081 (group libtool): Thank you for the report. I recently saw the same issue with libgcc on NetBSD. It helps to know this issue is more widespread than just NetBSD. I was also beginning to wonder if I had introduced the issue in a recent commit, but since you are runni

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

Update of sr #111069 (group libtool): Status:None => Done ___ Follow-up Comment #10: I have merged a patch in the development branch to append '-no_fixup_chains' for macOS versions 1

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

Update of sr #111069 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: ___ Me

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

m/Homebrew/brew/blob/f1a7d971f2e5d04097d7a360aa1f9a910ccc20f3/Library/Homebrew/extend/os/mac/extend/ENV/shared.rb#L37-L42 -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Descript

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

Follow-up Comment #14, sr #111069 (group libtool): [comment #11 comment #11:] > [comment #10 comment #10:] > > 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* ... > > Thanks for taking care of this. I did not und

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

Update of sr #111069 (group libtool): Status:Done => In Progress Open/Closed: Closed => Open ___ Follow-up Comment #15: [comment #12 comment

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

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 if there are any issues with it. ___

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&am

Re: flang compiler and wrappers

tch from https://savannah.gnu.org/patch/?9442 be included in the upcoming libtool release? The previous patch was applied in the latest alpha release of libtool 2.5.0, and you should see it in the upcoming beta and stable releases. Thank you Anton -- Ileana Dumitrescu GPG Public Key: FA26 CA7

Re: -no_fixup_chains patch

_lt_dar_allow_undefined='$_lt_dar_allow_undefined $wl-no_fixup_chains' fi -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

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

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

fi ;; esac Thank you for attaching the patch. I have applied it to development, and it should move to master later this week. The '-no_fixup_chains' issue is hopefully resolved! -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146

Re: flang compiler and wrappers

40 macro_version=2.5.0.21-cc511 41 macro_revision=2.5.0.21 I am glad you found a solution! I will remember this for when someone else is having trouble testing an applied patch. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_

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

Re: -no_fixup_chains patch

low_undefined+=' $wl-no_fixup_chains' +    _lt_dar_allow_undefined='$_lt_dar_allow_undefined $wl-no_fixup_chains'     fi -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 From de453742b79726648ff5154fb8f5fb47b193a50c Mon Se

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

Re: -no_fixup_chains patch

Unless there is an issue with including the functionality of funclib.sh in libtool.m4, I will apply this patch early next week. The actual issue with appending the '-no_fixup_chains' option should be fixed at this point, so I will close that [1]. [1] https://savannah.gnu.org/support/inde

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

Update of sr #111069 (group libtool): Status: In Progress => Done Open/Closed:Open => Closed ___ Follow-up Comment #17: Closing, since this

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

Re: libtool-2.5.1 released [beta]

testing the beta release! I hope to release a stable version soon after fixing a few more bugs that have already been reported. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key

[sr #111105] libtool use incorrect rpath when using sysroot

Follow-up Comment #1, sr #05 (group libtool): Thank you for your bug report. I have not spent much time looking at this, but I think it may be fixed in the latest beta release of libtool 2.5.1. Here are the commits that should have fixed the issue: https://git.savannah.gnu.org/cgit/libtool.

[sr #111105] libtool use incorrect rpath when using sysroot

Update of sr #05 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: I am glad it is fixed

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

[sr #111104] GCC crossback fails to build libgcc for multilibs since it sets the configure ridiculously.

Follow-up Comment #1, sr #04 (group libtool): With what was stated in the thread "libgcc crossback fails" and looking over the logs attached, I do not think you have an issue with libtool. It seems like your issue should be submitted to autoconf instead. As a temporary fix, you could manually

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #4, sr #110901 (group libtool): This is a similar report to both of the following: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49246 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949 Maybe an update to libtool's documentation should be made, since this has been recurring

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

Follow-up Comment #1, sr #110849 (group libtool): The latest beta release of libtool 2.5.1 passes test 161 on Ubuntu GNU/Linux. Could you retest for this failure? If you attach the testsuite.log for test 161, it may show why the test was failing for you. You can find the log in tests/testsuite.di

[sr #111011] restore previous shared library logic on Android

Update of sr #111011 (group libtool): Status:None => Wont Do Open/Closed:Open => Closed Summary: restore shared library support on Android => restore previous shared library log

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

Update of sr #110674 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #7: Thank you for the pat

[sr #110261] _LT_CMD_OLD_ARCHIVE should not inline AC_PROG_RANLIB

Update of sr #110261 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Thank you for forward

[sr #111081] Cannot find shared libraries with aarch64-w64-mingw32.

Update of sr #111081 (group libtool): Status:None => In Progress ___ Follow-up Comment #2: I have pushed a potential fix to libtool's development branch: https://git.savannah.gnu.org/cgit

[sr #111081] Cannot find shared libraries with aarch64-w64-mingw32.

Update of sr #111081 (group libtool): Status: In Progress => Done Open/Closed:Open => Closed ___ Follow-up Comment #4: Thank you for testing

Re: Some questions about use libtool when linking

ptions listed here [1] are needed, I would be happy to accept a patch for them with the listed rationale for why these flags should be passed through unchanged. [1] https://github.com/msys2/MSYS2-packages/blob/master/libtool/0003-Pass-various-runtime-library-flags-to-GCC.mingw.patch -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

[sr #110937] -single_module detection broken with Xcode 15

Update of sr #110937 (group libtool): Status: In Progress => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Thank you again for y

Re: Dynamic libraries on OpenBSD

ol-patches/2007-03/msg00044.html -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature

[sr #110937] -single_module detection broken with Xcode 15

Update of sr #110937 (group libtool): Status:None => In Progress ___ Follow-up Comment #1: Thank you for the patch, and sorry for the wait. It has been applied to the development branch for

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

Update of sr #110849 (group libtool): Status:None => Need Info ___ Reply to this item at: ___ Me

Re: libtool-2.5.4 released [stable]

primarily contained bug fixes, I hope to focus on enhancing existing functionality and incorporating new features in upcoming releases next year. Best, -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP

Re: libtool on AIX - soname feature inconsistent?

contributing to GNU Libtool. The section 'Submitting Bug Reports' should contain enough information to help you with your bug submission. [1] https://www.gnu.org/software/libtool/contribute.html -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01

[sr #111161] aix-soname behavior inconsistent

Follow-up Comment #1, sr #61 (group libtool): Thank you for your bug submission. Without immediate access to AIX, I reproduced this issue by removing the host constraint for the macro in ltoptions.m4, by editing a test file to use LT_INIT([aix-soname=svr4]), and by cleaning the testsuite's ca

[sr #111158] 'make check' fails on older Mac, especially when building fat binaries

Follow-up Comment #1, sr #58 (group libtool): Thank you for your bug report and sharing your findings. [comment #0 original submission:] > I'm using a Power Mac G5 with Mac OS 10.5.8 (Darwin 9.8). My package manager > massages the build environment a bit to ensure consistent behaviour. Part

[sr #102300] libtool confused by depcomp

Update of sr #102300 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing. If this is still an issue, please provide logs for debugging. __

[sr #111161] aix-soname behavior inconsistent

Follow-up Comment #2, sr #61 (group libtool): I have merged the proposed patch into the development branch [1]. I will close this issue when it is merged to master. Any feedback on this patch would be nice. [1]https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=34de5bf8bc31

[sr #111158] 'make check' fails on older Mac, especially when building fat binaries

Update of sr #58 (group libtool): Status:None => Need Info ___ Reply to this item at: ___ Message sent via

[sr #111104] GCC crossback fails to build libgcc for multilibs since it sets the configure ridiculously.

Update of sr #04 (group libtool): Status:None => Invalid Open/Closed:Open => Closed ___ Reply to this item at: __

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

Update of sr #110849 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing. If there are still test failures on Ubuntu GNU/Linux, please report them with logs attached. ___

[sr #108987] libtool doesn't like simple RM defined (without options)

Update of sr #108987 (group libtool): Status:None => Wont Do Open/Closed:Open => Closed ___ Follow-up Comment #5: [comment #4 comment #4:] > bootstrap & build-aux/funcl

[sr #107584] Fails to detect the global symbol pipe

Update of sr #107584 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing. If this is still an issue, please provide a patch for the proposed fix.

[sr #100409] install & clean broken on cygwin

Update of sr #100409 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you for your bug submission. Currently, install and

[sr #111202] Libtool strips -static flag from CFLAGS

Update of sr #111202 (group libtool): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #6: Since this is not a bug with libtool, closing. _

[sr #111193] libtool misses adding `libclang_rt.builtins-x86_64.a` to c++ shared libraries

Follow-up Comment #1, sr #93 (group libtool): Thank you for your bug report. The following patch may fix this: diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 434f9ba7..33383e9d 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -7748,7 +7748,7 @@ if AC_TRY_EVAL(ac_compile); then for p in

[sr #111210] libtool.m4: Fix postdeps in NetBSD

Follow-up Comment #2, sr #111210 (group libtool): Thank you for your bug and patch submission. [comment #0 original submission:] > Instead, I suggest to use the compiler frontend to do the right thing, > removing -nostdlib and setting output_verbose_link_cmd > to empty. I have attached a patch wh

[sr #111193] libtool misses adding `libclang_rt.builtins-x86_64.a` to c++ shared libraries

Follow-up Comment #2, sr #93 (group libtool): While patching a different issue, I generated the attached patch to add a configuration option for libtool to avoid the usage of '-nostdlib' when linking C++ modules. I think this might be a good alternative solution for your issue. (file #57070)

[sr #111184] libtool breaks -static-libstdc++ by adding it to .la files

Follow-up Comment #2, sr #84 (group libtool): Thank you for your bug report. While patching a different issue, I generated the attached patch to add a configuration option for libtool to avoid the usage of '-nostdlib' when linking C++ modules. From a quick look at your issue, this might be a

[sr #111210] libtool.m4: Fix postdeps in NetBSD

Follow-up Comment #4, sr #111210 (group libtool): [comment #3 comment #3:] > My suggestion above was actually meant for the NetBSD case only. My intention > with this paragraph was to explicit the changes that I made in my initial > patch, as it indeed suppresses the use of -nostdlib for NetBSD sy

[sr #111210] libtool.m4: Fix postdeps in NetBSD

Follow-up Comment #6, sr #111210 (group libtool): [comment #5 comment #5:] > I feel that the documentation is maybe a bit misleading. Actually, standard > libraries are always linked, it is rather the method to determine them that > changes. > > Just a suggestion: Thank you for suggestion. I have

[sr #111210] libtool.m4: Fix postdeps in NetBSD

Follow-up Comment #8, sr #111210 (group libtool): Thank you for testing and reviewing! I have committed both patches to the development branch. After some time, these will migrate to master prior to a release. https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=b26f7c36fb2094d4

[sr #111210] libtool.m4: Fix postdeps in NetBSD

Update of sr #111210 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Reply to this item at: _

[sr #111184] libtool breaks -static-libstdc++ by adding it to .la files

Follow-up Comment #3, sr #84 (group libtool): The patch has been committed to the development branch for disabling the use '-nostdlib' to let the compiler frontend decide what standard libraries to link when building C++ shared libraries and modules. Could you test if using '--enable-cxx-stdli

[sr #111193] libtool misses adding `libclang_rt.builtins-x86_64.a` to c++ shared libraries

Follow-up Comment #3, sr #93 (group libtool): The patch has been committed to the development branch for disabling the use '-nostdlib' to let the compiler frontend decide what standard libraries to link when building C++ shared libraries and modules. Could you test if using '--enable-cxx-stdli

[sr #111193] libtool misses adding `libclang_rt.builtins-x86_64.a` to c++ shared libraries

Update of sr #93 (group libtool): Status:None => Ready For Test ___ Reply to this item at: ___ Message sen

[sr #111193] libtool misses adding `libclang_rt.builtins-x86_64.a` to c++ shared libraries

Update of sr #93 (group libtool): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Follow-up Comment #5: [comment #4 comment #4:] > I tried on `libtool` from deve

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

n preparation for other compiler issues. I do not see a reason for FC compilers to need _LT_SYS_HIDDEN_LIBDEPS, so it can probably be removed... If there it is not causing failures, I would prefer to keep it to prevent causing failures for an issue I do not see currently. -- Ileana Dumitrescu GPG Public K

[sr #111202] Libtool strips -static flag from CFLAGS

Follow-up Comment #4, sr #111202 (group libtool): Flags can be passed to libtool when linking from within a Makefile.am. There are a few examples in the documentation for updating LDFLAGS for a libtool library or a program with a format, like myprog_LDFLAGS. Pkgconf fields (libpkgconf_la_LDFLAGS,

[sr #111202] Libtool strips -static flag from CFLAGS

Follow-up Comment #2, sr #111202 (group libtool): Thank you for your bug report. It looks like you are trying to create a standalone binary, which means you should link with the '-all-static' flag. Libtool static library/binary linking is different depending on a variety of factors, which is docu

[sr #111161] aix-soname behavior inconsistent

Update of sr #61 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: The proposed patch has been applied to master: https://

[sr #111191] libtool mistakes a directory as an executable

Update of sr #91 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you for the bug report and patch! [comment #0 orig

[sr #111196] Linking a static convenience library with fat objects fails if output already exists

Update of sr #96 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Reply to this item at: _

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

Follow-up Comment #4, sr #95 (group libtool): [comment #3 comment #3:] > Here's a proposed patch that adds the libtool-next-version program to the > libtool package, including documentation. Thank you for the patch file! It looks great, but I would make small changes to the formatting of libt

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

Update of sr #95 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #6: [comment #5 comment #5:] >> the formatting of libtool.tex

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

Follow-up Comment #1, sr #95 (group libtool): [comment #0 original submission:] > 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 scri

[sr #111158] 'make check' fails on older Mac, especially when building fat binaries

Follow-up Comment #2, sr #58 (group libtool): The test for Darwin fat compile has been updated on the development branch, which should fix the behaviour you observed where it was being skipped. https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=6b306695ea58c82320d6ee9c3f7c

[sr #111196] Linking a static convenience library with fat objects fails if output already exists

Follow-up Comment #1, sr #96 (group libtool): Thank you for your bug report. I was able to reproduce this issue, but I do not think it is something that needs an update in libtool. Instead, you should execute a libtool clean between subsequent builds, similarly to just removing the output arc

[sr #111184] libtool breaks -static-libstdc++ by adding it to .la files

Update of sr #84 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #5: Thank you for testing!

[sr #111241] Fixes build issue on MSVC

Follow-up Comment #1, sr #111241 (group libtool): [comment #0 original submission:] > I'm trying to build libtool with MSVC, but it failed with an error that a > symbol not found. (Please noticed that the following message is translated > from Chinese) > > CCLD libltdl/libltdl.la > libltdlS.c

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Update of sr #110901 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #7: I have applied a patch for this issue on the development

[sr #111191] libtool mistakes a directory as an executable

Follow-up Comment #3, sr #91 (group libtool): A patch for this issue with MSVC has been applied [1] to the development branch, which should migrate to master after testing. [1]https://cgit.git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=64b48f0bbd126c209895b163b0a4571d96778d9a

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #9, sr #110901 (group libtool): [comment #8 comment #8:] > [comment #7 комментарий №7:] >> I have applied a patch for this issue on the development branch [1], which >> should migrate to master after more testing. If this does not seem to fix >> it, I will reopen. >> >> [1]https

[sr #111157] MSVC / cl.exe .exp extension collision

Update of sr #57 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you for your bug report and proposed patch! I have

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

Follow-up Comment #14, sr #110901 (group libtool): [comment #13 comment #13:] >> This sounds fine to me. Could you write a patch for this, or specify the ENV >> variable and parts of path conversion that you would like bypassed? > > > I updated > https://github.com/mitchcapper/libtool/compare/ad

[sr #111257] Missing quotes for lt_ar_flags

Update of sr #111257 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Thank you for your bug submission! I have applied a patch

  1   2   >