From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80984 invoked by alias); 28 Oct 2016 20:27:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 80957 invoked by uid 89); 28 Oct 2016 20:26:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=separation, convince, applicable X-HELO: mx1.redhat.com Subject: Re: [PATCH] Add test for linking against most static libraries To: Joseph Myers References: <20161028125742.928D7439942E0@oldenburg.str.redhat.com> <8b17140d-bbab-95c1-7458-7214f0e474ad@redhat.com> <9c9a0748-7101-a6a0-297e-106886589d81@redhat.com> Cc: "Carlos O'Donell" , libc-alpha@sourceware.org From: Florian Weimer Message-ID: Date: Fri, 28 Oct 2016 20:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00570.txt.bz2 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