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 v

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 behavi

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 has

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

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 o

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 be

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 y

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? Ye

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 "g

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 want

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 plague

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

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 p

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 jus

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 - Web:

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

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.

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 r