[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