Re: library linking, missing libB.so
Hi,
On Wed, Mar 26, 2014 at 10:12 AM, Nico Schlömer
<nico.schloemer@gmail.com> wrote:
>> I consider this as an important[*] bug. People should not
>> know about the low level LAPACK/ BLAS implementation.
>
> That's right. I already checked back with the CMake crowd (the
> critical lines are automatically created by CMake) and we might find
Well it is automatically generated by CMake, *because* you told it so.
Just set the LINK_INTERFACE_LIBRARIES properties of libA to empty.
> ourselves in a little bit of a tricky situation here: If a library
> libA is merely linked against libB, we of course don't want to know
> about the implementation details of libB.
> If the headers in libA-dev include something of libA-dev though,
> libA-dev should depend on libB-dev. Correct?
Rephrasing the second 'libA-dev' in 'libB-dev']
Yes, it's a *should* (well really a *must*)
> If the headers of libB-dev only appear in the sources of libA, i.e.,
> libA doesn't provide an interface to libB, libA-dev should *not*
> depend on libB-dev. Correct?
*should* is a little strong here. But really libA should not be
pulling the whole world, so yes, please restrict to the minimum dep.
> Right now, the dependency structure in debian/control looks like
>
> libA:
> Depends: ${shlibs:Depends}, ${misc:Depends}
>
> libA-dev:
> Depends: libA (= ${binary:Version}), ${shlibs:Depends},
> ${misc:Depends}, libB-dev
Ok then. this happens sometimes.
> Would you consider this sane? Will whatever magic acts in
> ${shlibs:Depends}, ${misc:Depends} be able to identify libB as a
> dependency of libA?
That's the magic behind ${shlibs:Depends}. It will read the output of
`readelf -d` to figure that (magic is lot less fun when you know the
tricks) [*].
2cts
[*] black magic will even generate proper version dependencies
figuring out which minimum version is required :-P
Reply to: