Bug 77947

Summary: [PATCH] Libs.private in pkgconfig files
Product: poppler Reporter: Sandro Mani <manisandro>
Component: generalAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Proposed patch
Proposed patch

Description Sandro Mani 2014-04-25 22:00:00 UTC
Created attachment 98000 [details]
Proposed patch

A user noted [1] that, when linking statically against poppler using $(pkg-config --static --libs poppler), he gets undefined reference errors. To avoid requiring the user to enter all the libs on the command line, the required libraries can be added to the Libs.private section of the respective pkg-config files. The proposed patch does this for the autotools build (similar should be done with the cmake build, but I'm not terribly familiar with cmake).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1089380
Comment 1 Albert Astals Cid 2014-05-03 22:06:06 UTC
hardcoding stuff like iconv in there seems a bit weird can we use some kind of alias like you do in the other files?
Comment 2 Sandro Mani 2014-05-03 22:46:21 UTC
Created attachment 98391 [details]
Proposed patch

Looks like @LIBICONV@ does the job.
Comment 3 Albert Astals Cid 2015-01-04 16:19:11 UTC
Any chance you can fix this on cmake? Increasing the delta between the two build systems for something as static linking of poppler is something i'm not very keen on doing.
Comment 4 Sandro Mani 2015-01-04 17:04:52 UTC
Hmm, seems the only way to do it with cmake is to hard code the -l<lib> in the pc file... I.e.

Libs.private: @GLIB2_LIBRARIES@ @CAIRO_LIBRARIES@ @FREETYPE_LIBRARIES@

results in

Libs.private: gio-2.0;gobject-2.0;glib-2.0 /usr/lib64/libcairo.so /usr/lib64/libfreetype.so

which is obviously not what we want.

Do you perhaps know some cmake black magic to get only the actual -l<lib> instead of the output above?
Comment 5 Albert Astals Cid 2015-01-04 18:39:31 UTC
No idea sorry :/
Comment 6 Sandro Mani 2015-01-05 19:11:11 UTC
So the only other nice option I saw was to read what was passed to target_link_libraries, do some regex magic and use that in the pc files. However, looks like there is no way to read the target_link_libraries a posteriori.... 

So I suppose what one could do is introduce a variable containing what is passed to target_link_libraries and then filter that to use in the pc files. Along the lines of i.e.:

set(POPPLER_GLIB_LIBRARIES ${GLIB2_LIBRARIES} ${CAIRO_LIBRARIES} ${FREETYPE_LIBRARIES} -lpthread)

target_link_libraries(poppler-glib poppler ${POPPLER_GLIB_LIBRARIES})

string(REGEX REPLACE <stuff> <stuff> POPPLER_GLIB_LIBRARIES_CLEANED ${POPPLER_GLIB_LIBRARIES})

# In the .pc
Libs.private=@POPPLER_GLIB_LIBRARIES_CLEANED@

Perhaps adding a comment above the target_link_libraries notifying the developer to add varabiles to POPPLER_XXX_LIBRARIES variable instead of directly to the target_link_libraries.

Sounds like a plan?
Comment 7 Albert Astals Cid 2015-01-05 19:26:34 UTC
That setting all the libs to a variable is something we already kind of do, so i'm in favor of it, on the other hand that regexp stuff may be not even be doable.

Give it a "quick" try. If you don't succeed come back and i'll think if we care about this at all or not, honestly static linking poppler is not something that i think makes sense at all.
Comment 8 Sandro Mani 2015-01-05 19:31:30 UTC
So I think something like

"[\w/]+lib(\w+)\.so[.\w]*" -> "\1"
"[\s;]+" -> " -l"

could work.

But yeah, the issue is not one which personally affects me, I only gave it a shot because of rhbz #1089380. So as far as I'm concerned we can very well just happily stop here and move on ;)
Comment 9 GitLab Migration User 2018-08-20 21:57:33 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/133.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.