Bug 1282502 - It would be nice of glibc-devel to include pkg-config .pc files
It would be nice of glibc-devel to include pkg-config .pc files
Status: NEW
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: glibc team
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-16 10:40 EST by Peter Jones
Modified: 2017-01-19 15:26 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Jones 2015-11-16 10:40:29 EST
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 :)

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