[sr #111245] MSVC removes MAGIC_EXE when -Gw or -GL is specified

indows ___ Follow-up Comments: --- Date: Fri 23 May 2025 08:47:19 AM UTC By: Anonymous In lt-main.in, MAGIC_EXE hold a magic string to distinguish it whether it is a wrapper executable or not. It&#

[sr #111241] Fixes build issue on MSVC

: None ___ Follow-up Comments: --- Date: Sun 11 May 2025 11:00:41 AM UTC By: Anonymous 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 tran

[sr #111217] "link_all_deplibs": issue with overlinking dependencies

Operating System: *BSD ___ Follow-up Comments: --- Date: Thu 03 Apr 2025 07:48:53 PM UTC By: Anonymous Hi, I am facing an issue with dependency "overlinking" (related to the &

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

Follow-up Comment #7, sr #111210 (group libtool): [comment #6 comment #6:] > Thank you for suggestion. I have updated the patch to include this change > with some minor updates to what is listed in the documentation also. Great. Looks OK now, I did a quick test (NetBSD only) and it went fine. >

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

Follow-up Comment #5, sr #111210 (group libtool): [comment #4 comment #4:] > I made the option available for other systems since I have seen other bug > reports [1] requesting the removal of '-nostdlib'. I see. Then I'm fine with this. I feel that the documentation is maybe a bit misleading. Actu

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

Follow-up Comment #3, sr #111210 (group libtool): Thanks for your quick reply and review. > [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

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

Follow-up Comment #1, sr #111210 (group libtool): Sorry, I mentionned the wrong commit in the message. I meant to mention commit:c7be1f229c: https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=c7be1f229c ___ Reply to this item at:

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

: *BSD ___ Follow-up Comments: --- Date: Sun 23 Mar 2025 01:06:14 PM UTC By: Anonymous commit:4f7704015 addesses an issue with building C++ modules on NetBSD, by removing -lgcc_s and -lgcc. This may sometimes not work cor

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

Follow-up Comment #2, sr #96 (group libtool): Okay thanks, fair enough! Feel free to close this (I assume I can't, or I don't see how to) ___ Reply to this item at: ___

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

k: Any Operating System: Mac OS ___ Follow-up Comments: --- Date: Tue 25 Feb 2025 06:32:59 PM UTC By: Anonymous On macOS, I can generate a static convenience library with "f

[sr #111161] aix-soname behavior inconsistent

m: AIX ___ Follow-up Comments: --- Date: Tue 10 Dec 2024 12:14:16 AM UTC By: Anonymous On AIX, the results of using --with-aix-soname=svr4 and LT_INIT([aix-soname=svr4]) should be the same, but they are not. One project where t

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

Operating System: Mac OS ___ Follow-up Comments: --- Date: Tue 03 Dec 2024 07:15:19 AM UTC By: Anonymous I'm using a Power Mac G5 with Mac OS 10.5.8 (Darwin 9.8). My package

[sr #111038] QNX version_type handling is wrong

Additional Item Attachment, sr #111038 (group libtool): File name: 0001-ltmain.in-update-QNX-version_type-handling.patch Size:1 KB AGPL NOTICE These attachments are served by Savane.

[sr #111038] QNX version_type handling is wrong

: None ___ Follow-up Comments: --- Date: Fri 22 Mar 2024 05:01:30 PM UTC By: Anonymous SONAME versioning on QNX OS works just like all the other popular ELF targets and has done so for the last decade. The c

[sr #111002] regression in libtool 2.4.7: build error in ncurses

/Linux ___ Follow-up Comments: --- Date: Sat 06 Jan 2024 07:54:04 AM UTC By: Anonymous ncurses 6.4 can be built with libtool when configured with `--with-libtool` option. I found that

[sr #110962] pass_all for z/OS

: None ___ Follow-up Comments: --- Date: Tue 28 Nov 2023 05:16:41 PM UTC By: Anonymous Hi, I wanted to submit this patch for z/OS: https://lists.gnu.org/archive/html/libtool-patches/2023-11/msg8.html It's a simple patch to add p

[sr #110947] flang: error: unknown argument: '-soname'

Follow-up Comment #3, sr #110947 (project libtool): I confirm that the patch works against the latest development branch: $ libtool --version libtool (GNU libtool) 2.4.7.4-1ec8f I just added "flang" in addition to "armflang": cat < patch.libtool.m4 diff --git a/m4/libtool.m4 b/m4/libtool.m4 in

[sr #110947] flang: error: unknown argument: '-soname'

Follow-up Comment #2, sr #110947 (project libtool): Sorry, a typo -- I got this via autom...@gnu.org. ___ Reply to this item at: ___ Message sent vi

[sr #110947] flang: error: unknown argument: '-soname'

Follow-up Comment #1, sr #110947 (project libtool): I got this via autoto...@gnu.org: Dear Anton, here is a patch for libtool that Francois Coppens and I submitted to libtool in February. I think we did something went wrong in the PR process because it has still not been included... Maybe you ca

[sr #110947] flang: error: unknown argument: '-soname'

ystem: GNU/Linux ___ Follow-up Comments: --- Date: Sun 22 Oct 2023 12:02:06 PM UTC By: Anonymous It seems flang (and armflang) are not handled correctly by libtool. In a simple project (rep

[sr #110925] libtool 2.4.7.4-1ec8f-dirty infinite loop on unknown (out of order) argument

k: Any Operating System: GNU/Linux ___ Follow-up Comments: --- Date: Sun 20 Aug 2023 08:15:20 AM UTC By: Anonymous Libtool 2.4.7.4-1ec8f-dirty enters an infinite loop in func_parse_o

[sr #110796] libtool-2.4.7/build-aux/git-version-gen uses kind of a hack

System: Mac OS ___ Follow-up Comments: --- Date: Wed 07 Dec 2022 11:26:55 PM UTC By: Anonymous Hello! On an elderly Mac with PPC Mac OS X 10.4.11, Tiger, this was reported: expr: br

[sr #110550] File expected to be at /usr/bin/file, isn't on ChromeOS

URL: Summary: File expected to be at /usr/bin/file, isn't on ChromeOS Project: GNU Libtool Submitted by: None Submitted on: Sun 17 Oct 2021 04:47:52 AM UTC Category: None

[sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers

URL: Summary: Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers Project: GNU Libtool Submitted by: None Submitted on: Sat 13 Jul 2019 09:50:51 AM UTC

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

URL: Summary: ltmain.sh: [_MSC_VER] should be [_WIN32] in one place Project: GNU Libtool Submitted by: None Submitted on: Mon 04 Jun 2018 02:21:41 PM UTC Category: None

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

Follow-up Comment #2, sr #108637 (project libtool): As pointed out by Roumen Petrov, overriding the sys_lib_dlsearch_path_spec variable gets the behavior I want. In specific, passing lt_cv_sys_lib_dlsearch_path_spec=... with a list of paths to ./configure gets them excluded from the default -rpath

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

Follow-up Comment #1, sr #108637 (project libtool): Small correction, step #4 should read "Build dbus". If someone could confirm this is indeed a bug and whether there's a good workaround for it that would be great. Thinking about it, my impression is that bintest should actually be a wrapper sh

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

URL: Summary: libtool adds -rpath to staging directory Project: GNU Libtool Submitted by: None Submitted on: Tue 19 Aug 2014 11:30:33 PM UTC Category: None Priority

[sr #107959] Libtool generates invalid .def files

Additional Item Attachment, sr #107959 (project libtool): File name: 01-def-syntax.patchSize:0 KB ___ Reply to this item at: ___ Messag

[sr #106790] Version 2.2.6 shaded native option -shared of ld

Follow-up Comment #3, sr #106790 (project libtool): Thanks for explanation. And one question left. Can I disable static libraries building only for modules, without --disable-static global using? ___ Reply to this item at:

[sr #106790] Version 2.2.6 shaded native option -shared of ld

Follow-up Comment #1, sr #106790 (project libtool): Sorry, not applets. Plugins build. ___ Reply to this item at: ___ Message sent via/by Savannah

[sr #106790] Version 2.2.6 shaded native option -shared of ld

URL: Summary: Version 2.2.6 shaded native option -shared of ld Project: GNU Libtool Submitted by: None Submitted on: Wed 27 May 2009 09:38:18 AM UTC Category: None

[sr #106237] Newbie: libltdl not matching #include

URL: Summary: Newbie: libltdl not matching #include Project: GNU Libtool Submitted by: None Submitted on: Saturday 01/26/2008 at 22:53 UTC Category: None Priorit

[sr #105489] --whole-archive doesn't work on OSX

Follow-up Comment #1, sr #105489 (project libtool): Mac OS/X does have a way to turn off the all_load option. The (undocumented) option is -noall_load. I have this from Apple compiler developers. ___ Reply to this item at:

[sr #105489] --whole-archive doesn't work on OSX

URL: Summary: --whole-archive doesn't work on OSX Project: GNU Libtool Submitted by: None Submitted on: Wednesday 08/02/2006 at 01:21 UTC Category: None

[sr #100410] clean mode wants to remove unknown files

Additional Item Attachment, sr #100410 (project libtool): File name: \'¿i╨.åë½Size:0 KB ___ Reply to this item at:

[support #103719] catching unresolved symbols at link time, and template instantiation

This mail is an automated notification from the support tracker of the project: GNU Libtool. /**/ [support #103719] Full Item Snapshot: URL: Project: GNU L