Re: GNU Libtool-2.4.3 released [stable]

not break the build, at least not now. [1] https://bugs.gentoo.org/show_bug.cgi?id=527200 Pavel From 124712553f84f9052b14b0ef9ddac1314f9c1aa0 Mon Sep 17 00:00:00 2001 From: Pavel Raiskup prais...@redhat.com Date: Thu, 30 Oct 2014 13:44:59 +0100 Subject: [PATCH] libtoolize: do not remove gnulib files

Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

On Thursday 04 of December 2014 17:51:28 Gary V. Vaughan wrote: Hi Orion, [...] Does this work for you? diff --git a/m4/libtool.m4 b/m4/libtool.m4 [...] + case $host_cpu in +# match at least x86_64, ia64, powerpc64* +*64*) sys_lib_dlsearch_path_spec=/lib64 /usr/lib64

Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

On Friday 05 of December 2014 10:56:28 Gary V. Vaughan wrote: This really needs to be sorted out. However this approach does not match the s390x at least. As in `case $host_cpu in *64*|s390x) ...` ? I can add that if you'd like? That would be at least better :), but I would still need to

Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

On Friday 05 of December 2014 12:11:57 Gary V. Vaughan wrote: Yes, we can use ac_cv_ workaround globally, but that is not ideal as this turns off the ld.so.conf parsing in libtool (which works pretty well to reimplement). ... so yet another idea. What about have some API

Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

On Saturday 06 of December 2014 14:36:23 Pavel Raiskup wrote: Iteration #0. Patch (for discussion, not push) implementing configure time PREPEND_LIB_DLSEARCH_PATH variable. Possible enhancements for future could be {APPEND_,}LIB_DLSEARCH_PATH and {,APPEND_,PREPEND_}LIB_SEARCH_PATH

Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec)

On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote: [..] LT_SYS_LIBRARY_PATH [..] That LT_SYS_LIBRARY_PATH concept sounds good, thanks! * should I use AC_ARG_VAR rather? I'm not entirely clear yet exactly when the extra directories are important... It seems not that useful

Re: Tune rpath by env. variable

On Tuesday 09 of December 2014 11:53:22 Gary V. Vaughan wrote: That makes sense. Ideally, we could make the variable ./configure time sensitive and also sensitive to environment. Something like : ${LT_SYS_LIBRARY_PATH=/configure/time/detected/LT_SYS_LIBRARY_PATH}? Great. The only

Re: Tune rpath by env. variable

. Patch attached. Pavel From fdc38af01a9079f712787db451ca6003101d53f1 Mon Sep 17 00:00:00 2001 From: Pavel Raiskup prais...@redhat.com Date: Sat, 6 Dec 2014 16:35:41 +0100 Subject: [PATCH] libtool: allow adjusting run-time library path Some GNU/Linux distributions install libraries into /lib64

Re: Tune rpath by env. variable

On Thursday 11 of December 2014 23:29:56 Gary V. Vaughan wrote: I applied your patch with some fairly heavy-handed changes: 1. Added a NEWS update. 2. Simplified the new documentation. 3. Changed the name of some internal API symbols. 4. Fixed dollar quoting with quadrigraphs, and

Re: Tune rpath by env. variable

in the wild. Something like the attachment 0002 would be nice to have pushed. That code seems like asking for test-case also? Thanks, Pavel From 562a2a74f7cbaf236aee46b88cf01e06217300cb Mon Sep 17 00:00:00 2001 From: Pavel Raiskup prais...@redhat.com Date: Sat, 13 Dec 2014 10:59:37 +0100 Subject

Re: Tune rpath by env. variable

On Tuesday 20 of January 2015 07:40:20 Pavel Raiskup wrote: Something like the attachment 0002 would be nice to have pushed. This would be nice to have it in git also. The LT_SYS_SEARCH_PATH does not survive automatic re-autoconf of configure script: Argh :(, sorry. Fixing the example

Re: Tune rpath by env. variable

On Saturday 13 of December 2014 18:58:58 Pavel Raiskup wrote: On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote: I'll commit a follow on patch, to tweak it like this, later today. Thanks for the patch! It is almost perfect. During testing I noted that there is still one dollar

Re: Bash-specific performance by avoiding sed

On Friday 09 of October 2015 17:16:03 Pavel Raiskup wrote: > > Here's a (lightly-tested) idea of what it would look like, where we'd > > have to audit every caller to deal with the result already including > > full quoting: > > > > if test yes = `(x=; printf -v

Re: Bash-specific performance by avoiding sed

On Monday 05 of October 2015 15:28:56 Pavel Raiskup wrote: > On Monday 05 of October 2015 09:47:05 Pavel Raiskup wrote: > > On Monday 05 of October 2015 01:25:24 Pavel Raiskup wrote: > > > On Monday 05 of October 2015 00:45:50 Pavel Raiskup wrote: > > > > > shou

Re: Bash-specific performance by avoiding sed

On Wednesday 07 of October 2015 08:03:01 Eric Blake wrote: > On 10/07/2015 06:28 AM, Pavel Raiskup wrote: > > > .. so it is (2.4.6 vs. 2.4.7~dev, user+sys) 7m23.5s vs 8m58.3s. It's not > > completely back yet but it's much better than v2.4.6. > > Thanks again for

Re: Bash-specific performance by avoiding sed

On Monday 05 of October 2015 01:25:24 Pavel Raiskup wrote: > On Monday 05 of October 2015 00:45:50 Pavel Raiskup wrote: > > > should we test the size of the string first ? i've written such raw > > > shell > > > string parsing functions before, and once you hit

Re: Bash-specific performance by avoiding sed

ortable while it keeps almost the same speed (if we can use += its even faster). I have yet a another patch trying to minimize option-parser overhead (that is focused on the POV of Richard, but that needs to be cleaned up a bit, I'll post hopefully tomorrow). Any comment is welcome! Pave

Re: Bash-specific performance by avoiding sed

On Monday 05 of October 2015 00:45:50 Pavel Raiskup wrote: > > should we test the size of the string first ? i've written such raw shell > > string parsing functions before, and once you hit a certain size (like 1k+ > > iirc), forking out to sed is way faster, espec

Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

On Wednesday 23 of September 2015 16:09:49 Eric Blake wrote: > On 09/23/2015 03:37 PM, Pavel Raiskup wrote: > > > > >>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001 > > From: Pavel Raiskup <prais...@redhat.com> > > Date: Fri, 18 Sep

[PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

ning libtoolize, to keep the correct libtool macros > in-tree. > > real 0m1.003s > user 0m0.364s > sys 0m0.540s > > > >From 40d297de7502f93a546126ff69d3f687f3d3ca1a Mon Sep 17 00:00:00 2001 From: Pavel Raiskup <prais...@redhat.com> Date: Fri, 18 Sep 2015 23:17:07 +0200 S

Re: Bash-specific performance by avoiding sed

On Monday 05 of October 2015 09:47:05 Pavel Raiskup wrote: > On Monday 05 of October 2015 01:25:24 Pavel Raiskup wrote: > > On Monday 05 of October 2015 00:45:50 Pavel Raiskup wrote: > > > > should we test the size of the string first ? i've written such raw > > > &

Re: How to build libtool from git sources properly?

On Thursday, May 19, 2016 8:56:20 AM CEST Bruce Korb wrote: > On Thu, May 19, 2016 at 7:22 AM, Eric Blake wrote: > > ... However, libtool uses its own > > custom bootstrap, and I don't know if it has that same functionality. > > Patches are certainly welcome. And it would also

Re: syntax error in VERSION script

Hi John, thanks for the report. On Saturday 20 of February 2016 17:26:14 John Elaine wrote: > I am trying to compile the C bindings for Zookeeper (uses libtool), but I > am unable to do so. When I run make, I receive the following error: > > /usr/bin/ld:.libs/libzookeeper_st.ver:2: ignoring

Re: [PATCH] Fix typo of non-existing function name

On Thursday, June 16, 2016 5:12:14 PM CEST Mike Frysinger wrote: > lgtm. hopefully a committer will wake up to merge it :). Thanks for the patch and review, committed as 350082b6aa89. Pavel ___ https://lists.gnu.org/mailman/listinfo/libtool

Attempt to release GNU Libtool Was: Re: macOS version detection in libtool.m4

On Thursday, October 21, 2021 10:02:12 AM CEST Werner LEMBERG wrote: > > > A patch [4] was submitted to fix this [...] I already contacted Jeremy (patch author) with the Copyright paperwork details. > > Is there anything I can do to help this patch along? > > You might step up as a new libtool

Re: New libtool maintainer

Hello Alex! On Wednesday, October 27, 2021 4:44:00 AM CEST Alex Ameen wrote: > Howdy! > > This is Alex Ameen reporting in from Austin, Texas. I'm a long time GNU > and `autotools' user who specializes in ELF linking and loading. I'm > writing you today to introduce myself and announce that I

Re: powerpc*le-linux support

[...] config.sub won't return ppc*-*linux* so there isn't much point in matching that. [...] Haven't found enough time to do the review but issues with config.{guess,sub} should be discussed on different list: config-patc...@gnu.org Pavel

Re: powerpc*le-linux support

Haven't found enough time to do the review .. but I should have to try to find at least a second. I see patch is relevant to libtool, sorry for my previous pointless comment.

[PATCH] testsuite: fix race conditions in ltdl dryrun

/autoreconf.in#n356 Pavel racy-tests.tar.gz Description: application/compressed-tar From 2ad0598f0d8cd8c8532a2c34ea1b06c71901047d Mon Sep 17 00:00:00 2001 From: Pavel Raiskup prais...@redhat.com Date: Mon, 15 Dec 2014 13:42:25 +0100 Subject: [PATCH] tests: fix race in aclocal/autoheader calls Put

[PATCH] libtoolize: fix ltdl installation order

Makefile.in has aclocal.m4 as prerequisite, so Makefile.in should be installed later to avoid unnecessary rebuild by (versioned) aclocal. The problem is worse if the current libtool package has been built against different automake version than the current libtoolize is run against (high chance

[SCM] GNU Libtool branch, praiskup-ARFLAGS, created. v2.4.6-6-ge503ccc

- commit e503ccc64bcac5a80766876fe985937194d4cf12 Author: Pavel Raiskup prais...@redhat.com Date: Thu Jun 25 14:53:28 2015 +0200 maint: relax 'sc_prohibit_test_dollar' check * cfg.mk (sc_prohibit_test_dollar): White-list

[SCM] GNU Libtool branch, praiskup-ARFLAGS, created. v2.4.6-6-ge503ccc

- commit e503ccc64bcac5a80766876fe985937194d4cf12 Author: Pavel Raiskup prais...@redhat.com Date: Thu Jun 25 14:53:28 2015 +0200 maint: relax 'sc_prohibit_test_dollar' check * cfg.mk (sc_prohibit_test_dollar): White-list

[SCM] GNU Libtool branch, praiskup-ARFLAGS, deleted. v2.4.6-6-ge503ccc

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, praiskup-ARFLAGS has been deleted was e503ccc64bcac5a80766876fe985937194d4cf12

[SCM] GNU Libtool branch, master, updated. v2.4.6-19-gaabc46a

list those revisions in full, below. - Log - commit aabc46ac1bee0bf79e0185f70eb58df8568f37af Author: Pavel Raiskup <prais...@redhat.com> Date: Mon Nov 2 14:54:11 2015 +0100 gl/tests: new tests for options-parser

[SCM] GNU Libtool branch, master, updated. v2.4.6-11-gb7b6ec3

t appeared on any other notification email; so we list those revisions in full, below. - Log - commit b7b6ec33baa4747eb147e9e249e675e477d861f4 Author: Pavel Raiskup <prais...@redhat.com> Date: Sat Sep 26 17:47:56 2015 +0200

Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

On Wednesday 23 of September 2015 16:09:49 Eric Blake wrote: > On 09/23/2015 03:37 PM, Pavel Raiskup wrote: > > > > >>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001 > > From: Pavel Raiskup <prais...@redhat.com> > > Date: Fri, 18 Sep

[PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

ning libtoolize, to keep the correct libtool macros > in-tree. > > real 0m1.003s > user 0m0.364s > sys 0m0.540s > > > >From 40d297de7502f93a546126ff69d3f687f3d3ca1a Mon Sep 17 00:00:00 2001 From: Pavel Raiskup <prais...@redhat.com> Date: Fri, 18 Sep 2015 23:17:07 +0200 S

Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

Hi Eric, thanks for your review! On Saturday 19 of September 2015 15:05:07 Eric Blake wrote: > On 09/19/2015 02:09 AM, Pavel Raiskup wrote: > > Hi Hiroyuki Sato, > > > > On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote: > >> This configure.ac is

[SCM] GNU Libtool branch, master, updated. v2.4.6-7-g0f84217

revisions in full, below. - Log - commit 0f84217752fe50155f1f00fd14efdfaaed24 Author: Pavel Raiskup <prais...@redhat.com> Date: Fri Sep 25 08:14:02 2015 +0200 maint: put newline after 'Subjecŧ' in ChangeLog

[patch #8775] Add support for passing -fsanitize=* to the linker (eg: for ASan)

Update of patch #8775 (project libtool): Status:None => Done Assigned to:None => praiskup ___ Reply to this item at:

[SCM] GNU Libtool branch, master, updated. v2.4.6-21-gae816ac

--- commit ae816aced1e09adaf38a8d938f226db1cc27e79c Author: Pavel Raiskup <prais...@redhat.com> Date: Mon Nov 30 07:06:56 2015 +0100 gl-tests: make the failure more readable * gl/tests/test-funclib-quote.sh (_compare_or_error): Put $1 into error output, not having it like tha

Re: [patch #8675] elftoolchain strip support

ESULT([yes]) > > > > Following up again to see about including this patch in libtool. Is > > there anything else I can do to have this considered? > > Ping? Xin Li and Ed, thanks and sorry for the delay. Can you please check the attached patch on FreeBSD? There is separate code

[patch #7049] [PATCH] 79d9801 2009-12-25: Ppefer double quotes in output

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

[patch #8775] Add support for passing -fsanitize=* to the linker (eg: for ASan)

Update of patch #8775 (project libtool): Open/Closed:Open => Closed ___ Reply to this item at: ___

[SCM] GNU Libtool branch, master, updated. v2.4.6-24-g5944fdc

--- commit 5944fdcc7390fb3a619235d3c4b7f7ef34bc0f8a Author: Pavel Raiskup <prais...@redhat.com> Date: Wed Feb 3 10:18:14 2016 +0100 gl: minor typo fixes * gl/build-aux/options-parser (func_run_hooks): s/funcions.n./functions./, s/$@/${1+"$@"}/. * gl/modules/funclib.sh: Sync license

[SCM] GNU Libtool branch, master, updated. v2.4.6-23-g4985667

--- commit 498566799618cba7d0e7b22140673f0582814054 Author: Pavel Raiskup <prais...@redhat.com> Date: Wed Feb 3 10:05:51 2016 +0100 gl-tests: dash && option-parser test fix Rico pointed out that the testsuite failed on his system (dash represented /bin/sh). Turns out that 'shift' in dash e

[SCM] GNU Libtool branch, master, updated. v2.4.6-32-gf10e22c

--- commit f10e22c2a13876a5494f11b1110d0e2976797873 Author: Pavel Raiskup <prais...@redhat.com> Date: Fri Feb 19 18:22:15 2016 +0100 tests: fix $objdir hardcoding check with CFLAGS=-g3 At least with gcc, specifying -g3 in CFLAGS ends up with macros expanded including LT_OBJDIR macro. This fool

Re: [PATCH 2/2] libtool: set file_list_spec to '@' on OS/2

KO Myung-Hun, thanks for this patch but I need to see a bit deeper reasoning for this change as I do not understand the code properly. As the $file_list_spec is used in libtool under special circumstances, can you describe what are the values of important variables (or could you post a full

Re: [PATCH 2/2] libtool: set file_list_spec to '@' on OS/2

Applied. Hard to test check for me, but strictly about OS/2. Thanks! Pavel

[SCM] GNU Libtool branch, master, updated. v2.4.6-33-ga938703

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU Libtool". The branch, master has been updated via a938703c462bd2ba0e520808d45186020ea600be (commit) from

[SCM] GNU Libtool branch, master, updated. v2.4.6-27-gb89a47e

ow. - Log - commit b89a47eae6d81a039f2ab36a8c510586f39afbd9 Author: Pavel Raiskup <prais...@redhat.com> Date: Tue Feb 16 01:16:20 2016 +0100 maint: fix for 'make sc_immutable_NEWS' hints * NEWS: Remove the leading white-spaces before Copyright line b

[SCM] GNU Libtool branch, master, updated. v2.4.6-28-g40bc062

--- commit 40bc0628d5c8c9790164e76c9ab07ab170e2eafd Author: Pavel Raiskup <prais...@redhat.com> Date: Wed Feb 17 16:27:25 2016 +0100 edit-readme-alpha: generate the "stable" README properly Fixes bug#20196. Reported by Peter Johansson and KO Myung-Hun * build-aux/edit-readme-alpha:

[SCM] GNU Libtool branch, master, updated. v2.4.6-31-gf9970d9

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU Libtool". The branch, master has been updated via f9970d99293faf908fdc153a653fa5781095fb7a (commit) from

Re: [PATCH 1/2] edit-readme-alpha: do not edit again a file already edited

On Tuesday 29 of December 2015 23:55:08 KO Myung-Hun wrote: > Ping ? Thanks, and sorry for the delay. Fixed by 40bc0628d5c8c979 as a part of fix for bug#20196, this double-edit issue is fixed by reverting the order of checks. Please check and comment if there is an issue. Thanks! Pavel

Re: [PATCH] libtoolize: don't execute automake and autoconf on every invocation.

Mike, thanks for this patch. You seem to not have the copyright assignment for the GNU Libtool project. Can you please update this? Thanks, Pavel

[SCM] GNU Libtool branch, master, updated. v2.4.6-35-gf003a1f

--- commit f003a1f96e67f3cb823c1c7081efab445e3f0c83 Author: Pavel Raiskup <prais...@redhat.com> Date: Mon Jan 16 12:45:03 2017 +0100 libltdl: handle ENOMEM in lt_dlloader_remove() Reported by Alexander Hass. * libltdl/lt_dlloader.c (lt_dlloader_remove): Detect NULL return value from lt_dlin