[lsb-discuss] Question on LSB and pkg-config
Mats Wichmann
mats at wichmann.us
Fri Jun 28 02:44:24 UTC 2013
On 06/27/2013 04:58 PM, Petrie, Glen wrote:
> Hello,
>
>
>
> During my on-going testing of SANE for LSB - 5.0, I installed the video
> lib 'libv4l1.so/a' which some SANE module support if the library exist.
> Using the configure file for SANE without LSB, the video library was
> found to exist through the use of a
>
>
>
>>> /usr/bin/pkg-config -exists -print-errors -errors-to-stdout "libv4l1"
>
>
>
> Thus, the configure file added the "capability" to the Makefiles for
> SANE.
>
>
>
> I changed to the LSB (for CC and CXX) and reran the SANE configure file.
>
>
>
> I am trying to verify from someone on the mailing list that the LSB
> (can/)will not intercept a configure file test like pkg-config. Thus,
> the test still passes, even thought the LSB does not support
> 'libv4l1.so/a'
Never simple questions, are there.
lsbcc is set up so in normal cases, it will leave alone -lfoo if libfoo
is part of LSB, and wrap it in stuff to pick up the .a version if it is
not part of LSB. As the manpage says:
Non LSB Shared Libraries
Normally, only LSB-defined libraries should be linked as
shared
libraries, all others must be linked statically. However, if an
appli‐
cation provides its own shared libraries which have been
carefully
checked for LSB conformance, the following methods can be
used to
selectively override lsbcc's rule of forcing static linking. The
appli‐
cation may not depend on such a library being present on a
system, so
it must either be shipped with the application, or with
another LSB
conforming application on which this application depends.
That is, you can either explicitly say libfoo.so as opposed to -lfoo, or
fiddle with one of the options that says where to find shared libraries.
We assume that a static library is okay, and don't mess with that
further. It may or may not be true, but there's no way to tell.
Now in the case of pkg-config and libtool, the relevant config files for
a feature may push in a library by pathname rather than by -lfoo, so the
LSB rules on this may or may not apply. There's an option to lsbcc
(--lsb-libtool_fixups) that tries to deal with this case, but it
s only a a guess, and in general, if you or a tool have put in the full
path to a library, nothing is done to get around that.
Again, lsbcc manpage says:
BUGS
It is possible to confuse the automatic library processing of
lsbcc
(and lsbc++). In particular, build systems that include "clever"
tools
to manage which libraries to use, such as GNU libtool and
pkgconfig,
may defeat the checks for non-LSB libraries by silently supplying
full
pathnames instead of the -llib form.
Does any of this help answer the question?
More information about the lsb-discuss
mailing list