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 > <[email protected]> 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! > _______________________________________________ poppler mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/poppler
