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

Follow-up Comment #13, sr #111069 (group libtool): [comment #7 comment #7:] > ... Newer versions of ld64 already know to disable chained fixups when it is passed `-undefined dynamic_lookup`. This patch is really only relevant for a small range of versions of ld64 that doesn't have this behavi

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

Follow-up Comment #12, sr #111069 (group libtool): This is the commit: https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development=001d22d7d587e85a911c71c4d0c798ede8014b77 It's a good idea to always provide a link to the commit. You could remove the comment

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

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

Follow-up Comment #11, sr #111069 (group libtool): [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 understand libtool enough to

[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: <https://savannah.gnu.org/support/?

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

branch development updated: libtool: Correct DLL Installation Path for mingw

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new d3dd6fa0 libtool: Correct DLL Installation Path for mingw d3dd6fa0

branch development updated: libtool: Skip passing CXX flags test on NetBSD

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new 2da3546a libtool: Skip passing CXX flags test on NetBSD 2da3546a is described

branch development updated: libtool: Add remaining test case descriptions

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new 22389943 libtool: Add remaining test case descriptions 22389943 is described

branch development updated: libtool: Add no-undefined flag based on host OS

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new ad8aeb7d libtool: Add no-undefined flag based on host OS ad8aeb7d

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

Follow-up Comment #9, sr #111069 (group libtool): [comment #8 comment #8:] > If you could modify this patch to include a linker version check that should be sufficient. You could probably try to parse this output: ``` ❯ cc -Wl,-version_details -xc - -o /dev/null <<<'int main(){}'

branch development updated: libtool: Remove no-undefined flag from test

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new 7854e410 libtool: Remove no-undefined flag from test 7854e410 is described

[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

branch development updated: libtool: Check if -no-canonical-prefixes supported

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new e40ba04a libtool: Check if -no-canonical-prefixes supported e40ba04a

branch development updated: libtool: pass more flags to the linker

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch development in repository libtool. The following commit(s) were added to refs/heads/development by this push: new 40b73c11 libtool: pass more flags to the linker 40b73c11 is described below

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

Follow-up Comment #7, sr #111069 (group libtool): [comment #6 comment #6:] > It would be better to understand whether what libtool is doing is incompatible with chained fixups, and if so, fix that so that it works with chained fixups. libtool passes `-undefined dynamic_lookup` to the lin

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

Follow-up Comment #6, sr #111069 (group libtool): The libtool that was used to generate gsl 2.8's configure script includes this patch, which is why gsl 2.8 is failing to build with older macOS toolchains that don't understand this flag. It does not seem like libtool should accept this patch

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

Follow-up Comment #5, sr #111069 (group libtool): Actually, checking the behaviour of ld64 when it's given unknown flags isn't hard: ``` ❯ clang -xc - -Wl,-nonexistent_flag -o /dev/null <<<'int main(){}' ld: unknown options: -nonexistent_flag clang: error: linker command failed with ex

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

Follow-up Comment #4, sr #111069 (group libtool): [comment #3 comment #3:] > I personally tested this a while back Thanks for letting me know about that testing. Now I wonder if a feature test might be better here in libtool, rather than a linker version number t

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

Follow-up Comment #3, sr #111069 (group libtool): > My original patch assumes that `-no_fixup_chains` would be silently ignored by intermediate linker versions older than Xcode 13. I have not yet tested this assumption on any such Macs. This is not a good assumption, I'm afraid. I persona

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

Follow-up Comment #2, sr #111069 (group libtool): [comment #1 comment #1:] > Note that the `-no_fixup_chains` flag is supported only on Xcode 13 or newer (which in turn requires macOS 11.3 or newer). > > See this relevant method used in Homebrew: ... Thank you for this information

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

Follow-up Comment #1, sr #111069 (group libtool): Note that the `-no_fixup_chains` flag is supported only on Xcode 13 or newer (which in turn requires macOS 11.3 or newer). See this relevant method used in Homebrew: https://github.com/Homebrew/brew/blob/f1a7d971f2e5d04097d7a360aa1f9a910ccc20f3

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

URL: <https://savannah.gnu.org/support/?111069> Summary: libtool: patch: Fix dynamic_lookup warnings from new Mac linker Group: GNU Libtool Submitter: dallured Submitted: Fri 24 May 2024 06:01:06 PM UTC Ca

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

Number of tests in GNU Libtool 2.4.7 test suite

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 wonder how many are still there left. Thank you

GNU Libtool thanks and updates

Hi! I want to thank everyone who has been testing the recent alpha release of libtool-2.5.0. I also want to especially thank Bruno Haible for the CI checks on Github. I hope to fix the several reports of test failures before a beta release. Also, I plan to fork the gnu-libtool/ci-check

[patch #10455] libtool: add support for wasm32-emscripten

URL: <https://savannah.gnu.org/patch/?10455> Summary: libtool: add support for wasm32-emscripten Group: GNU Libtool Submitter: labnan Submitted: Wed 15 May 2024 11:49:35 AM UTC Category

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,

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

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

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

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

How to force libtool to use CXX mode?

I have expended quite a few days already (over a 6 month span) with attempting to convince Automake to force libtool to link using the C++ compiler.  I tried optionally adding an empty C++ source file to the target build but this does not work because then Automake always assumes C++ linkage

[patch #9996] Patch libtool for macOS 11.0 (aka darwin20)

Follow-up Comment #1, patch #9996 (group libtool): It looks like that patch was merged in 2021 (9e8c882517082fe5755f2524d23efb02f1522490) and was included in libtool 2.4.7. ___ Reply to this item at: <https://savannah.gnu.org/pa

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

Installation of libtool-2.4.7 from source

Hello, I have installed libtool-2.4.7 from source as I require it for the latest Singularity version. However when I try to run libtoolize, it gives this error. libtoolize: error: $pkgauxdir is not a directory: '/usr/local/share/libtool/build-aux' I’m not quite familiar with source

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

Next libtool release?

What happened to the release? Joakim

branch master updated: libtool: Pass the "-no-canonical-prefixes" linker flag

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 297b5cf1 libtool: Pass the "-no-canonical-prefixes" linker flag 297b5cf1 is

branch master updated: libtool: Add more test case descriptions

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 3a82c4aa libtool: Add more test case descriptions 3a82c4aa is described below commit

branch master updated: libtool: Fix and remove TODO for improperly sized symbol in TOC

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new deba4f81 libtool: Fix and remove TODO for improperly sized symbol in TOC deba4f81

branch master updated: libtool: Fix documentation for demo compile mode commands

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 98ed9b7b libtool: Fix documentation for demo compile mode commands 98ed9b7b

branch master updated: libtool: Some outdated documentation warnings removed

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 498bad82 libtool: Some outdated documentation warnings removed 498bad82 is described

branch master updated: libtool: Add test case descriptions

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new b07d71b3 libtool: Add test case descriptions b07d71b3 is described below commit

branch master updated: libtool: Documentation refers to demo directory that no longer exists

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 7f254d96 libtool: Documentation refers to demo directory that no longer exists

[PATCH] libtool: Add support for SerenityOS

This hobbyist OS has already been added to `config.sub` (and `config.guess` respectively) some time ago, but was still lacking upstream support for building libraries using libtool. Since it is a relatively up-to-date system with ports of modern software, "adding support" mostly just me

[patch #10433] libtool: Add support for SerenityOS

URL: <https://savannah.gnu.org/patch/?10433> Summary: libtool: Add support for SerenityOS Group: GNU Libtool Submitter: timschumi Submitted: Sun 25 Feb 2024 01:26:01 AM UTC Category: None Pr

[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

[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 #102300] libtool confused by depcomp

Update of sr#102300 (group libtool): Status:None => Need Info ___ Follow-up Comment #1: sorry, but i'm not quite following the issue here. can you include a full command line &

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

Follow-up Comment #1, sr#110925 (group libtool): please show an example command that fails, and ideally include a patch showing what change you want to make i tried to quickly reproduce this locally based on your description, but it works fine for me

[sr #100875] libtool and amanda-2.4.3b3

Update of sr#100875 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: seems like this

[sr #109183] Problem on compiling on git-bash/mingw using libtool coming with mpfr3.1.5

Update of sr#109183 (group libtool): Status:None => Need Info ___ Follow-up Comment #1: if this is still an issue with current mpfr releases, please attach the generated "libtool

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

and/or dirs separated by ':' including PATH and LD_LIBRARY_PATH. >> >> If rpath entries is separated by ':', it's also true. > > i'm not familiar with the diff (non-glibc) runtime loaders, so will > take your word for this. afaict, libtool has behaved this way for > a long time,

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

> > the separator used by PATH is also used with that var ? > > This is applied to all the variables containing a list of paths and/or > dirs separated by ':' including PATH and LD_LIBRARY_PATH. > > If rpath entries is separated by ':', it's also true. i'm not familiar with the diff

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

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

hes over the past few days. > > there doesn't seem to be libtool-specific release details in the tree. > i can update HACKING with some notes for you. plus the dist target > seems to be broken :/. i was looking in HACKING & README & the manual & in a clean tree. if you boo

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

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

branch master updated: libtool: add mingw to systems not requiring libm

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 97859bda libtool: add mingw to systems not requiring libm 97859bda is described below

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

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

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 fo

Re: Introducing a new maintainer of libtool

lly upsets you and needs >> to be backed out. Don't look at more patches until a first pretest >> release is out, IMHO, as I'm sure one can go mad pondering implications >> of a libtool patch forever... > > Thanks, it seems like the general consensus is to get a release out &g

Re: Introducing a new maintainer of libtool

ore patches until a first pretest release is out, IMHO, as I'm sure one can go mad pondering implications of a libtool patch forever... Thanks, it seems like the general consensus is to get a release out soon. I went through older emails on the mailing list when Alex Ameen was named as maintai

Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

On Wed, 17 Jan 2024, Roumen Petrov wrote: Hi All Mike Frysinger wrote: On 16 Jan 2024 21:11, Brad Smith wrote: libtool: remove OpenBSD support for non-shared and a.out archs OpenBSD stopped supporting the last non-shared arch 8 years ago and stopped supporting a.out 10.5 years ago

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: > On 16 Jan 2024 23:44, KO Myung-Hun wrote: >> Some OSes such as OS/2, uses ';' as a path separator. So using >> $PATH_SEPARATOR instead of hard-coded ':' is more proper. > > so we're on the same page, we're talking about the

Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

Hi All Mike Frysinger wrote: On 16 Jan 2024 21:11, Brad Smith wrote: libtool: remove OpenBSD support for non-shared and a.out archs OpenBSD stopped supporting the last non-shared arch 8 years ago and stopped supporting a.out 10.5 years ago. This cannot be reason to drop support. For instance

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

Update of sr#111002 (group libtool): Status:None => Need Info ___ Follow-up Comment #1: are you using patched libtool in your system ? ncurses-6.4 builds fine for me with libtool-2.

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

Update of sr#108559 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: <https://savannah.gnu.org/support/?

[sr #108558] libtool nm test does not really work for W32 versions of nm

Update of sr#108558 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: <https://savannah.gnu.org/support/?

[sr #107959] Libtool generates invalid .def files

Update of sr#107959 (group libtool): Open/Closed:Open => Closed ___ Reply to this item at: <https://savannah.gnu.org/support/?

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

Follow-up Comment #4, sr#108987 (group libtool): bootstrap & build-aux/funclib.sh are not maintained in libtool. you'll want to send those fixes upstream. https://github.com/gnulib-modules/bootstrap ___ Reply to this item at: &l

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

Update of sr#110796 (group libtool): Status:None => Wont Do Open/Closed:Open => Closed ___ Follow-up Comment #1: build-aux/git-v

branch master updated: libtool: fix Solaris 11 builds

This is an automated email from the git hooks/post-receive script. vapier pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new b67d1a2d libtool: fix Solaris 11 builds b67d1a2d is described below commit

Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

On 16 Jan 2024 21:11, Brad Smith wrote: > libtool: remove OpenBSD support for non-shared and a.out archs > > OpenBSD stopped supporting the last non-shared arch 8 years ago > and stopped supporting a.out 10.5 years ago. i'm on the fence here, and i don't know what historical gui

[PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

libtool: remove OpenBSD support for non-shared and a.out archs OpenBSD stopped supporting the last non-shared arch 8 years ago and stopped supporting a.out 10.5 years ago. * m4/libtool.m4: Remove support for a.out and non-shared archs. --- m4/libtool.m4 | 59

Re: [PATCH] libtool: remove OpenBSD specific performance hack for ranlib

On 16 Jan 2024 16:30, Brad Smith wrote: > The -t flag was used as a performance hack for ranlib. The flag was > supported by the GNU toolchain, but is a no-op with the LLVM toolchain. merged, thx -mike signature.asc Description: PGP signature

branch master updated: libtool: remove OpenBSD specific performance hack for ranlib

This is an automated email from the git hooks/post-receive script. vapier pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 1ae386ba libtool: remove OpenBSD specific performance hack for ranlib 1ae386ba

Re: [PATCH 3/3] libtool: Fix support for NIOS2 processor

On 16 Jan 2024 15:14, Richard Purdie wrote: > The name of the system contains the string "nios2". This string > is caught by the some of the greedy checks for OS/2 in libtool, > in particular the *os2* branches of switch statements match for > the nios2 string, which results

branch master updated: libtool: Fix support for NIOS2 processor

This is an automated email from the git hooks/post-receive script. vapier pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 49e6cb0d libtool: Fix support for NIOS2 processor 49e6cb0d is described below commit

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

On 16 Jan 2024 23:44, KO Myung-Hun wrote: > Some OSes such as OS/2, uses ';' as a path separator. So using > $PATH_SEPARATOR instead of hard-coded ':' is more proper. so we're on the same page, we're talking about the separator that is used in the $PATH environment variable. it doesn't show up

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 libt

[PATCH] libtool: remove OpenBSD specific performance hack for ranlib

libtool: remove OpenBSD specific performance hack for ranlib The -t flag was used as a performance hack for ranlib. The flag was supported by the GNU toolchain, but is a no-op with the LLVM toolchain. * m4/libtool.m4: Remove use of -t flag with ranlib. --- m4/libtool.m4 | 9 + 1 file

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 als

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

branch master updated: libtool: Use $LD when checking for --whole-archive

This is an automated email from the git hooks/post-receive script. vapier pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new f81f36e4 libtool: Use $LD when checking for --whole-archive f81f36e4 is described below

Re: [PATCH] libtool: remove bitrig support.

On 16 Jan 2024 01:49, Brad Smith wrote: > libtool: remove bitrig support. > > Bitrig has been defunct for 7 years. pushed, thanks -mike signature.asc Description: PGP signature

branch master updated: libtool: remove bitrig support.

This is an automated email from the git hooks/post-receive script. vapier pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 5a7193db libtool: remove bitrig support. 5a7193db is described below commit

branch master updated: libtool: use -Fe with MSVC to specify filename

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 81e8abf3 libtool: use -Fe with MSVC to specify filename 81e8abf3 is described below

[patch #10411] libtool: fix empty "-L" in compiler_lib_search_path

Update of patch#10411 (group libtool): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks for f

branch master updated: libtool: fix empty "-L" in compiler_lib_search_path

This is an automated email from the git hooks/post-receive script. ildumi pushed a commit to branch master in repository libtool. The following commit(s) were added to refs/heads/master by this push: new 4da5b575 libtool: fix empty "-L" in compiler_lib_search_path 4da5b575 is

[PATCH 3/3] libtool: Fix support for NIOS2 processor

The name of the system contains the string "nios2". This string is caught by the some of the greedy checks for OS/2 in libtool, in particular the *os2* branches of switch statements match for the nios2 string, which results in incorrect behavior of libtool. Switch to use $host_os instea

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

2) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFlppZFE9YstvghgroRAjFKAJ0fQTTh4qTJtgRvd/pI2TSeFIf4xgCeNEWF mWoDIYiA2aMRvGaFs3ES9cE= =fXIc -END PGP SIGNATURE- From 11d5ba83c5211ec7e149f3170bbaf7d49e6448da Mon Sep 17 00:00:00 2001 From: KO Myung-Hun Date: Thu, 3 Nov 2022 23:32:37 +0900 Subj

[PATCH] libtool: remove bitrig support.

libtool: remove bitrig support. Bitrig has been defunct for 7 years. * build-aux/ltmain.in (func_mode_link): Remove bitrig support. * m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE, LT_CMD_MAX_LEN) (_LT_SYS_DYNAMIC_LINKER, _LT_CHECK_MAGIC_METHOD) (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG): Ditto. * m4/ltdl.m4

Re: [PATCH 00/12] Yocto Project libtool patch queue

there's a bunch of changes in here, but no additional test coverage also the project still requires ChangeLog entries in the commit message, so can you please add those so we don't have to write them for you ? if you look at commit history, the format should hopefully be obvious. -mike

Re: [PATCH 07/12] libtool: Fix support for NIOS2 processor

On 25 Oct 2021 15:33, Richard Purdie wrote: > The name of the system contains the string "nios2". This string > is caught by the some of the greedy checks for OS/2 in libtool, > in particular the *os2* branches of switch statements match for > the nios2 string, which results

  1   2   3   4   5   6   7   8   9   10   >