Re: transitive shared library dependencies and installation
| Newsgroups | gmane.comp.gnu.libtool.general |
|---|---|
| Message-ID | <[email protected]> |
Roumen Petrov <[email protected]> writes: > [email protected] wrote: > >> Roumen Petrov <[email protected]> writes: >> >>> [email protected] wrote: >>> >>>> I'm experimenting with the attached skeleton project on a Debian buster >>>> system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9): > > Debian is key word. > Libtool is patched, not FSF. [...] > With and without new dtags result will be the same. Very well possible, it's just one difference I happened to know about. > It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has > some issues with multiple dependent libraries (more then two). > From debian was proposed a patch related to library > dependencies. Unfortunately patch break existing regression test. From > debian never was proposed version that pass regression test. > > Libtool 2.0 fixes his issues related to multiple libraries. On the > same Debian did not stop to contribute patch that breaks libtool. > > As result when I decide to build something from source always to > updated sources to FSF version. > > So the right question is did reporter test with FSF version? I'm the reporter, and I didn't test any other version, as I wasn't even sure whether my example was correct and was supposed to work. Could you please provide some keywords to search for so that I can dig up the details of the above story? At the moment Debian carries 21 patches for libtool, if I could show that one of them breaks a valid use case, that would constitute a strong reason for dropping it. -- Thanks, Feri