[poppler] Requires.private field missing in poppler.pc

[suzuki toshiya]

Dear Jeroen,

Thank you for testing!

After testing additional several cases, I found that more tweaks are
expected.

The case I concern is:
condition A) libpoppler, libpoppler-cpp, etc are created as archive files.
condition B) a dependent library (required by libpoppler etc) provide
both of shared + archive files but the subdependent files for its shared
file are not provided as a part of SDK.

Maybe it's not easy to imagine the situation that I'm talking about.
Taking libcurl-gnutls4-dev of Ubuntu as an example.

$ pkg-config --libs libcurl
-lcurl

$ pkg-config --libs --static libcurl
-L/usr/lib/x86_64-linux-gnu/mit-krb5 -lcurl -lidn2 -lrtmp -lpsl -lnettle
-lgnutls -Wl,-Bsymbolic-functions -Wl,-z,relro -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -llber -lldap -lz

This package provides libcurl.so + libcurl.a. libcurl.so depends on
libidn2.so.0, librtmp.so.1, libpsl.so.5, libnettle.so.6, libgnutls.so.30,
libgssapi_krb5.so.2, libliber-2.4.so.2, libldap_r-2.4.so.2. Even if there
are no libidn2.so (as a part of libidn2-dev), librtmp.so.1 (as a part of
librtmp-dev) etc, libcurl-gnutls4-dev could be installed well.

# some people may say "oh, it's a bug of the package dependency, it
# should be dependent with libidn2-dev etc". but, please consider that
# we have to co-work with the people who do not care for the static
# linking. even if Ubuntu maintainer welcomes such "fix", we should
# not take such situation as totally confused and out of scope.

In such environment, linking the shared version libcurl.so would have no
problem. but linking the archive version libcurl.a would fail, because
its dependent libraries are missing (not only libidn2.a but also libidn2.so).

Then, what would happen?

"pkg-config --libs --static poppler" tries to capture all dependent libraries,
for static linking. thus, the libraries required by libcurl.a are
requested, then, failed.

In this case, the expected situation would be:
we *cannot* "pkg-config --libs --static poppler" gives appropriate options,
because it is impossible to make a static linked binary.

basically, pkg-config libxxx --static --libs is *not* the option to choose
"libxxx.a" or "libxxx.so" simply. it is an option to affect the final
output is static linked binary /or not.

# this is an issue by design of pkg-config. pkg-config can distinguish
# 2 cases, "do not care complete, partial or none static binary" or
# "complete static binary". there is no option to specify as "link
# this library statically, but I don't care about others".

but, it would be reasonable to expect "pkg-config --libs poppler" returns
the flags to make a binary linking libpoppler.a statically and linking
libcurl.so dynamically, because now cmake does not have both of shared +
archive libraries at once. Making an useless poppler.pc under archive
library configuration is not good idea.

how to do that? the easiest way would be...

1) checking our target is shared library (libpoppler.so) or archive
library (libarchive.a). if our target is shared library (and on the
platform with changed dependency support in shared library), no special
tweak is needed. if our target is archive library, proceed to 2, 3, 4.

2) checking all libraries directly required by libpoppler, and classify
them into archive libraries and shared libraries.

3) shared libraries are collected to Requires or Libs simply. no need
to track their chained dependency.

4) for archive libraries, we should check the chained dependencies by
"--libs --static" (if they are not managed by pkg-config? ummm). the
dependencies should be collected to Requires or Libs, not to
Requires.private or Libs.private. Because "--libs" is expected to be
more generic than "--libs --static".

--

The problem is that the pkg-config files by above flow would be
quite different between one for shared library and another for
archive library. It would be confusing for the binary package
maintainers, because they would assume pkg-config files are always
same regardless with the target is shared or archive.

It would not be so difficult to have a tool merging 2 pkg-config
files, but I guess the solution hoped by the maintainers would be
"single invocation of cmake with special configuration can generate
the both of shared + archive libraries, and ready-to-use pkg-config
file".

--

Sorry for lengthy discussion. Also it would be difficult to evaluate
this proposal without concrete example. I would make some commits to
some branch in my github repository, to demonstrate of this idea.

Regards,
mpsuzuki

Jeroen Ooms wrote:
> On Thu, Mar 22, 2018 at 8:53 AM, suzuki toshiya
> <mpsuzuki at hiroshima-u.ac.jp> wrote:
>> Dear Jeroen,
>>
>> Please check https://github.com/mpsuzuki/poppler/tree/for-travis whether it
>> can serve for you.
> 
> Yes this works! I now get:
> 
> pkg-config --libs-only-l poppler-cpp
>   -lpoppler-cpp
> 
> pkg-config --libs-only-l --static poppler-cpp
> -lpoppler-cpp -lpoppler -ljpeg -ltiff -lpng -lfontconfig -lexpat
> -lfreetype -lz -lbz2 -lpng16 -lz -lcurl -lldap -lz -llcms2 -lm
> -lpthread -lopenjp2 -lm
> 
> pkg-config --libs-only-l --static poppler-glib
> -lpoppler-glib -lpoppler -ljpeg -ltiff -lpng -lcurl -lldap -lz -llcms2
> -lm -lpthread -lopenjp2 -lm -lcairo -lz -lgobject-2.0 -lffi -lglib-2.0
> -lintl -lpcre -lintl -liconv -lpcre -lpixman-1 -lfontconfig -lexpat
> -lfreetype -lz -lbz2 -lpng16 -lz -lpng16 -lz
> 
> Hope this patch will get accepted!
>