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 :)
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.