Hi Russ, libtool members,
I work on open source projects in my spare time. And so I can not
provide feedback promptly. Today I have time to re read mail thread and
to clarify my strong position.
Russ Allbery wrote:
Roumen Petrov writes:
Urgh, article with very limited niche. First is
Roumen Petrov writes:
> Urgh, article with very limited niche. First is only for shared libraries,
> next unresolved externals in shared library, and finally requires
> "advanced" loader.
Overlinking isn't about unresolved externals in shared libraries. It's
about avoiding linking with shared
Hi Feri,
wf...@niif.hu wrote:
[SNIP]
On the other hand, this overlinks the final binary:
$ objdump -p .libs/translib | fgrep NEEDED
NEEDED liba.so
NEEDED libb.so
NEEDED libc.so.6
libb.so is unneeded here (but is present in the installed
Bob Friesenhahn writes:
> On Sun, 5 Jan 2020, wf...@niif.hu wrote:
>
>> On the other hand, this overlinks the final binary:
>>
>> $ objdump -p .libs/translib | fgrep NEEDED
>> NEEDED liba.so
>> NEEDED libb.so
>> NEEDED libc.so.6
>>
>> libb.so is
On Sun, 5 Jan 2020, wf...@niif.hu wrote:
On the other hand, this overlinks the final binary:
$ objdump -p .libs/translib | fgrep NEEDED
NEEDED liba.so
NEEDED libb.so
NEEDED libc.so.6
libb.so is unneeded here (but is present in the installed program
Roumen Petrov writes:
> wf...@niif.hu wrote:
>
>>> 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.
>
> You sample is correct . One minor
Hi Feri,
wf...@niif.hu wrote:
[SNIP]
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
On Sat, 4 Jan 2020, Russ Allbery wrote:
wf...@niif.hu writes:
Bob Friesenhahn writes:
That sounds like a great idea. However, there is a problem that
linking on some systems does depend on already installed libraries (or
will end up using them) and so the libraries need to be installed
wf...@niif.hu writes:
> Bob Friesenhahn writes:
>> That sounds like a great idea. However, there is a problem that
>> linking on some systems does depend on already installed libraries (or
>> will end up using them) and so the libraries need to be installed and
>> linked in a particular order.
Bob Friesenhahn writes:
> On Sat, 4 Jan 2020, wf...@niif.hu wrote:
>
>>> Above dependency explain all - lib_LTLIBRARIES is project (sample)
>>> specific. Project should ensure order.
>>
>> Fair enogh, but my point (which I didn't really emphasize) is that
>> installation could work in any order,
Roumen Petrov writes:
> wf...@niif.hu wrote:
>
>> Roumen Petrov writes:
>>
>>> wf...@niif.hu 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
On Sat, 4 Jan 2020, wf...@niif.hu wrote:
...
Above dependency explain all - lib_LTLIBRARIES is project (sample)
specific. Project should ensure order.
Fair enogh, but my point (which I didn't really emphasize) is that
installation could work in any order, if relinking didn't depend on
already
Hello,
wf...@niif.hu wrote:
Roumen Petrov writes:
wf...@niif.hu wrote:
I'm experimenting with the attached skeleton project on a Debian buster
Debian is key word.
system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9):
Libtool is patched, not FSF.
[SNIP]
/usr/bin/ld:
Roumen Petrov writes:
> wf...@niif.hu 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):
> [SNIP]
>> /usr/bin/ld: cannot find -lb
>> collect2: error: ld returned 1 exit status
>> libtool:
wf...@niif.hu wrote:
Hi,
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):
[SNIP]
/usr/bin/ld: cannot find -lb
collect2: error: ld returned 1 exit status
libtool: error: error: relink 'a/liba.la' with
On Fri, 3 Jan 2020, Richard Purdie wrote:
Libtool must also work for static linking. It seems to me that your
issue also impacts static linking.
I think the challenge that libtool has here is that many of these older
systems that libtool supports aren't so prevalent anymore.
This is true.
On Thu, 2020-01-02 at 16:24 -0600, Bob Friesenhahn wrote:
> On Thu, 2 Jan 2020, wf...@niif.hu wrote:
> > > If Libtool were to depend on non-portable features, [...] then it
> > > could not longer be described as a portability tool.
> >
> > In my understanding, Libtool is a portability shim,
On Thu, 2 Jan 2020, wf...@niif.hu wrote:
If Libtool were to depend on non-portable features, [...] then it
could not longer be described as a portability tool.
In my understanding, Libtool is a portability shim, providing a regular
interface for developers across systems with wildly varying
Bob Friesenhahn writes:
> On Thu, 2 Jan 2020, wf...@niif.hu wrote:
>
True, but man ld states in the -rpath-link option description that the
directories specified by -rpath options are used with a very high
priority for locating required shared libraries.
>>>
>>> This is
On Thu, 2 Jan 2020, wf...@niif.hu wrote:
True, but man ld states in the -rpath-link option description that the
directories specified by -rpath options are used with a very high
priority for locating required shared libraries.
This is interesting but I am not seeing any use of -rpath-link in
On Thu, 2 Jan 2020, wf...@niif.hu wrote:
In this case libtool is a slave of Automake and Automake is
controlling the build and installation order. This means that it
should be expected behavior. Installation is serialized and thus
order matters.
But in case of a dependency cycle there's no
Bob Friesenhahn writes:
> On Wed, 1 Jan 2020, wf...@niif.hu wrote:
>
>> make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
>> make: *** [Makefile:798: install-am] Error 2
>>
>> No cyclic dependencies here, so this can be worked around by
>>
>> -lib_LTLIBRARIES = a/liba.la b/libb.la
On Wed, 1 Jan 2020, wf...@niif.hu wrote:
make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
make: *** [Makefile:798: install-am] Error 2
No cyclic dependencies here, so this can be worked around by
-lib_LTLIBRARIES = a/liba.la b/libb.la
+lib_LTLIBRARIES = b/libb.la a/liba.la
in
Hi,
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):
$ autoreconf -f -i
$ ./configure --prefix=/tmp/translib
$ make
$ ./translib; echo $?
6
$ make install
make[1]: Entering directory
24 matches
Mail list logo
