[PATCH] Add test for linking against most static libraries

Florian Weimer fweimer@redhat.com
Fri Oct 28 20:27:00 GMT 2016


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



More information about the Libc-alpha mailing list