Bug 1282502 - It would be nice of glibc-devel to include pkg-config .pc files
Summary: It would be nice of glibc-devel to include pkg-config .pc files
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: glibc team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-16 15:40 UTC by Peter Jones
Modified: 2019-10-23 15:47 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-23 15:47:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Peter Jones 2015-11-16 15:40:29 UTC
Carlos told me to put this email here:

> > (Also: is there a reason glibc doesn't ship with .pc files?  They'd be
> > useful...)
>
> The .pc files are autogenerated, see README.quilt (rawhide hast the latest
> variant of all the scripts we use).
>
> In general:
> ./gen-quilt-series.sh
> ./quilt-patch.sh
>
> Leaves you with a working .pc/ in the source directory so you can work
> with the spec file patches using quilt.
>
> That's what you're asking right? I know the process is "special", but
> I didn't want to impact the other 4 people doing patch work with what
> I consider to be optimal patch workflow i.e. quilt.
>
> Where would the .pc files live? How would I ship them? How would you
> use them? I'm curious to hear your input.

I think we crossed the streams here - I meant pkg-config .pc files.  So
I could say "pkg-config --cflags pthreads dl" and be reasonably sure I'll
get "-pthreads -D_REENTRANT" (or whatever is actually appropriate) in
the output, and "--libs" could reasonably give me "-lpthreads -ldl" in a
reasonable order.

Right now a lot of packages have .pc files that look like (random
example grep found for me):
------ begin gthread.pc -------
prefix=/usr
exec_prefix=/usr
libdir=${prefix}/lib64
includedir=${prefix}/include

Name: GThread
Description: Thread support for GLib
Requires: glib
Version: 1.2.10
Libs: -L${libdir} -lgthread -lpthread
Cflags:  -D_REENTRANT
-------- end gthread.pc -------

Where if we had c.pc and pthread.pc it would wind up being:

------ begin gthread.pc -------
Name: GThread
Description: Thread support for GLib
Requires: c glib pthread
Version: 1.2.10
Libs: -lgthread
-------- end gthread.pc -------

(I mention c.pc because in my imaginary world it would have "Libs: -L${libdir}"
in it, and pthread.pc would also have "Requires: c")

For that matter, it might be interesting to use it for individual
features, i.e. provide a foritfy-source.pc with:

-----------
Name: fortify-source
Description: C options for building with fortify source and stack protector
Version: ${glibc_version}
Cflags: -O2 -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
-----------

Or a hardened-build.pc with:
-----------
Name: Hardened build
Description: C options for hardened builds
Requires: c
Cflags: -fPIC
Cflags.private: -fPIE
Libs: -shared -Wl,-z,relro,-z,now,
Libs.private: -pie -Wl,-z,now
-----------
(Okay, right now that one is a bad example; Cflags.private doesn't
currently exist as a concept in pkg-config.)

I'm sure you get the picture by now :)

Comment 1 Florian Weimer 2019-10-23 15:47:44 UTC
Thread safety no longer requires -D_REENTRANT (I think since glibc 2.0 or thereabouts). We are actively working on reducing the number of shared objects upstream, so that it will be easier to link programs. .pc files wouldn't be very useful from a portability perspective because they are based on library names, and these names vary among operating systems.

If you think .pc files for hardening flags are useful, we could perhaps generate them during the redhat-rpm-config package build.


Note You need to log in before you can comment on or make changes to this bug.