This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add test for linking against most static libraries


On 10/28/2016 10:07 PM, Joseph Myers wrote:
On Fri, 28 Oct 2016, Florian Weimer wrote:

I suspect the only way to guard against this is to parse the default compiler
search paths from gcc -v and replace the variants of /usr/include found
therein with a carefully prepared directory tree of installed headers and some
linked-in kernel headers.

Building glibc needs compiler headers (include and include-fixed
directories - but while we need limits.h from include-fixed, there may be
other headers in include-fixed that we don't want) and kernel headers.

Are you certain about include-fixed part?

Are there any distributions which actually use fixincludes? What would be found there?

We need quite a few headers from GCC (even more with C++), but I'd suggest to rewrite the default include path to strip /usr/include, /usr/local/include and the multi-arch header directories if applicable, and leave the GCC include directories in place. The glibc installed header directory would take the place where /usr/include originally was.

But in some cases it may require other installed system headers as well.
E.g. memusagestat requires installed GD headers.  Systemtap support
requires installed sys/sdt.h.  I don't know what might require other
installed headers as well, especially for the non-Linux ports.

True.  NSS is another problematic case.

So while avoiding /usr/include is desirable, doing so while keeping all
the cases that properly use installed headers working may be tricky.

Yes, but a cleaner separation seems desirable to me.

(I'd argue that the memusagestat case should be solved by moving it to a
separate package - maybe released along with glibc, but built with
installed libraries only rather than as part of a glibc build.)

Seems reasonable.

I'm also trying to phase out NSS-based libcrypt at Red Hat, or alternatively, convince a real cryptographic library to build the library for us.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]