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

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

Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

On 2022-09-06 11:17:27 +0200, Vincent Lefevre wrote: > On 2022-09-06 10:12:23 +0200, Frederic Berat wrote: > > The behavior is likely not due to patches on libtool (at least I > > couldn't find anything obviously relevant), but more probably to the > > default behavio

Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

On 2022-09-06 10:12:23 +0200, Frederic Berat wrote: > The behavior is likely not due to patches on libtool (at least I > couldn't find anything obviously relevant), but more probably to the > default behavior of gnu ld. > From the behavior described in the thread earlier, it looks like > Debian

Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

On 2022-09-04 20:52:07 -0500, Corey Minyard wrote: > It compiles a program with -rpath and expects to see the set rpath > appear after RUNPATH. On the system that works: > > $ gcc -o hello hello.c -Wl,-rpath -Wl,/foo > $ objdump -p hello | grep RUNPATH > RUNPATH /foo > >

Re: LD_LIBRARY_PATH set by wrapper on Ubuntu, not on Rocky (Redhat)

On 2022-09-04 12:21:58 -0500, Corey Minyard wrote: [...] > I haven't figured out why, and I can't find a way to force libtool to > put in the LD_LIBRARY_PATH. What am I doing wrong? Look at the line "shlibpath_overrides_runpath=" in the generated libtool script. I suspect that you have "yes" in

Re: .gitmodules security

On 2022-02-11 05:05:45 -0500, Mike Frysinger wrote: > i'm not sure that's accurate. if you look at the history of the gnulib > submodule, it's updated maybe once a year. gnulib doesn't need to be > synced to its latest commit all the time to work. i think any automated > distro testing should

Re: .gitmodules security

On 2022-02-07 05:43:11 -0500, Mike Frysinger wrote: > On 07 Feb 2022 09:32, Vincent Lefevre wrote: > > what is done on Debian (where the libtool uses the version from the > > gnulib package, so that it is interesting to know the behavior with > > the current gnulib)

Re: .gitmodules security

On 2022-02-06 19:49:36 -0500, Mike Frysinger wrote: > the repository is pinned to a specific commit as you can see online: > https://git.savannah.gnu.org/cgit/libtool.git/log/gnulib > > so the normal git clone + submodule sync requires a sha1 collision. > > if someone were to manually update the

Re: .gitmodules security

On 2022-02-06 16:43:47 -0500, Mike Frysinger wrote: > it requires more than a MITM to be successful. you'd also have to > come up with a sha1 collision which is non-trivial for most people. > not out of the reach of nation states, but we prob aren't the target > market :p. I don't understand why

Re: .gitmodules security

On 2022-02-06 14:59:00 -0600, Alex Ameen wrote: > Hey, I can't claim to be an expert about this category of vulnerability; but > I appreciate you raising this concern. > > So is your recommendation to use https://git.savannah.gnu.org/git/gnulib.git > instead of git://git.sv.gnu.org/gnulib.git?

Re: .gitmodules security

On 2022-02-06 21:22:11 +0100, Vincent Lefevre wrote: > The .gitmodules file contains: > > [submodule "gnulib"] > path = gnulib > url = git://git.sv.gnu.org/gnulib.git > [submodule "bootstrap"] > path = gl-mod/bootstrap >

.gitmodules security

The .gitmodules file contains: [submodule "gnulib"] path = gnulib url = git://git.sv.gnu.org/gnulib.git [submodule "bootstrap"] path = gl-mod/bootstrap url = https://github.com/gnulib-modules/bootstrap.git but AFAIK, there is no host authentication done with the

Re: disable invocation of winepath by libtool

On 2021-12-05 21:28:40 +0300, ilya Basin wrote: > Dear List. I'm cross compiling a program on Linux for a mingw host > and sometimes this shows Wine dialogs like "updating wine > configuration" or "download and install Mono". I believe it's only > needed to run `make check` successfully, but I

Re: New release?

On 2020-05-24 14:24:12 +0200, Marc Nieper-Wißkirchen wrote: > Please excuse if this has been asked recently and I have missed it. > > I'd like to ask when or whether we can expect a new libtool release? Many > improvements have happened since the last release. For example, many builds > are

Re: libtool-next-version: new program

On 2019-05-12 16:12:47 +0200, Bruno Haible wrote: > Bumping the libtool version of a shared library according to > > seems to be harder than expected: Both the gettext-0.19.8 and gettext-0.20 > release suffer from a

[PATCH] libtool: pass more flags to the linker

Resolves bug 17750. * build-aux/ltmain.in (func_mode_link): In the flags to be passed through unchanged, also pass -static-* and -fcilkplus. Signed-off-by: Vincent Lefevre --- build-aux/ltmain.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/build-aux/ltmain.in b/build

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-06-01 18:46:56 +0200, Thomas Jahns wrote: > On 06/01/2017 11:09 AM, Vincent Lefevre wrote: > > Perhaps defining the LD_RUN_PATH environment variable instead of > > LD_LIBRARY_PATH could be a workaround, but gold does not support > > it, so that this cannot

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-06-01 08:30:43 -0500, Bob Friesenhahn wrote: > This requires that libtool re-link upon installation if the temporary rpaths > are not wanted. If the temporary rpaths are left in place, then > reliability, performance, and security issues are left baked into the > binaries. > > Are these

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-06-01 09:56:29 +0200, Thomas Jahns wrote: > GCC doesn't generate binaries or shared libraries, ld does. Passing > > -Wl,-rpath,/path/to/dependency/lib But this is not automatic. When typing $CC program.c -o program -lmpfr -lgmp (where $CC can be gcc, tcc or icc, for instance), things

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-05-31 11:58:05 +0200, Thomas Jahns wrote: > On 05/30/2017 06:30 PM, Vincent Lefevre wrote: > > On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote: > > > I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not > > > working for you is just a sympto

Re: binutils 2.28 breaking libtool for test programs when -no-install is used

On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote: > I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not > working for you is just a symptom of that. So, how can I make things work *automatically* under Linux without setting LD_LIBRARY_PATH? -- Vincent Lefèvre

binutils 2.28 breaking libtool for test programs when -no-install is used

Hi, Note that binutils 2.28 is breaking libtool for test programs ("make check") when -no-install is used. I've reported the following bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21476 The problem is that with this version, RUNPATH is used instead of RPATH in the executable generated

[PATCH] Add run path when linking with tcc, fixing bug #20622.

Add run path when linking with tcc, fixing bug #20622. Signed-off-by: Vincent Lefevre vinc...@vinc17.net --- m4/libtool.m4 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index a3bc337..cb4fea3 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -5232,6 +5232,7

Re: [PATCH] Fixed -fvisbility=hidden typo in a comment

On 2014-11-17 16:01:18 +, Gary V. Vaughan wrote: Nice catch! I had no idea people scrutinized the comments so carefully :-) It was actually reported by Kiyoshi KANAZAWA in the GNU MPFR list: http://comments.gmane.org/gmane.comp.lib.mpfr.general/2246 BTW, some typos can be found by using

[PATCH] Fixed -fvisbility=hidden typo in a comment

Fixed -fvisbility=hidden typo in a comment. Signed-off-by: Vincent Lefevre vinc...@vinc17.net --- m4/libtool.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 281e70f..6143541 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1840,7

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

On 2008-06-23 07:25:59 +0200, Ralf Wildenhues wrote: What I'd like to know is if mpfr works with patched Libtool, and how the Libtool testsuite fares with icc (see README for how to invoke it). I have installed the patched libtool from http://pogma.com/libtool/ in my home directory, but I don't

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

On 2008-06-23 07:25:59 +0200, Ralf Wildenhues wrote: What I'd like to know is if mpfr works with patched Libtool, and how the Libtool testsuite fares with icc (see README for how to invoke it). Concerning the testsuite with icc (CC=icc ./configure), I get the following failure (but this isn't

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

, 2003, 2004, 2005, # 2006, 2007, 2008 Free Software Foundation, Inc. [...] Is that correct? * Vincent Lefevre wrote on Mon, Jun 23, 2008 at 01:07:53PM CEST: Concerning the testsuite with icc (CC=icc ./configure), I get the following failure (but this isn't related to icc

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

On 2008-06-19 19:39:09 +0200, Ralf Wildenhues wrote: Unfortunately I can't try the patch on the same machine because the icc license has expired a few days ago (it was just an evaluation version). However I have access to another machine with icc installed; this is a different version, but

Re: Bug#485421: With icc, libtool tries -KPIC (removed option) instead of -fPIC

Hi Ralf, On 2008-06-18 22:31:49 +0200, Ralf Wildenhues wrote: diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index a2a4534..4a8d3e5 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -3703,8 +3703,15 @@ m4_if([$1], [CXX], [

libtool generates incorrect option for Solaris ld

I've done a make dist on the MPFR library under Debian, and with this tarball, when I do a ./configure --enable-shared under Solaris, make fails: [...] /bin/ksh ./libtool --tag=CC --mode=link cc -xtarget=native -xarch=v9 -xO4 -L/users/spaces/vlefevre/sparc-solaris/gmp-assert/lib -o libmpfr.la

Re: libtool generates incorrect option for Solaris ld

On 2007-07-02 11:20:54 -0500, Peter O'Gorman wrote: Please show '/usr/ccs/bin/ld -V' output, and the version of solaris. bar:~ /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris/ELF (3.0) This is Solaris 2.7. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100%

Re: libtool generates incorrect option for Solaris ld

On 2007-07-02 22:40:37 +0200, Ralf Wildenhues wrote: Thanks for your feedback. Does this patch work for you? Yes, it solves the problem. Thanks. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR

Re: libtool generates incorrect option for Solaris ld

On 2007-07-02 22:40:37 +0200, Ralf Wildenhues wrote: Thanks for your feedback. Does this patch work for you? Yes, it solves the problem. Thanks. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR

libtool uses incorrect module extension (.so instead of .dylib) under Darwin

When modules are generated under Darwin (Mac OS X 10.4.5), the extension .so is always used; I've been told that this comes from libtool (there's this problem with Liferea 1.0.8, whose tarball has been generated using libtool 1.5.22 Debian 1.5.22-4). Unfortunately, the value of G_MODULE_SUFFIX has

library interfaces and pseudo-random number generators

Hi, I'd like to know if the algorithm used for a pseudo-random number generator provided by a library is part of the library interface. A PRNG can be used so that the results are reproducible (using the same seed). From this point of view, I'd say that a new library version which gives different

Re: library interfaces and pseudo-random number generators

On 2006-02-20 10:10:02 +0100, Ralf Wildenhues wrote: Good question. I'd say that depends on documentation: if the interface was documented to either provide a certain PRNG, or weaker, if it was documented to provide deterministic series, then that would likely change the library interface.