From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7625 invoked by alias); 19 May 2015 23:55:05 -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 7615 invoked by uid 89); 19 May 2015 23:55:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: homiemail-a57.g.dreamhost.com Message-ID: <555BCD55.1000205@eagerm.com> Date: Wed, 20 May 2015 07:44:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: libc-alpha@sourceware.org Subject: Re: Problem building glibc References: <555B84FA.7090902@eagerm.com> <20150519194000.1E23E2C3AD8@topped-with-meat.com> <555BBCDF.6020300@eagerm.com> <20150519234031.5261A2C3A73@topped-with-meat.com> In-Reply-To: <20150519234031.5261A2C3A73@topped-with-meat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00409.txt.bz2 On 05/19/2015 04:40 PM, Roland McGrath wrote: >> There are a number of dependencies on headers in the install directory. >> Most are the headers installed by gcc, under ...-linux-gnu/4.9.2. > > If the install directory contains the GCC installation too, then that is > perfectly normal. What I meant was files installed by libc. > >> If >> I filter those out, there are dependencies for install/include/limits.h. >> Once this is touched, almost everything needs to be remade. > > That's not surprising given what you reported. This is the crux of the > problem. The build should not be finding limits.h there, but instead in > the libc source tree (libc/include/limits.h). Because of the complex > #include_next dance between GCC's limits.h and libc's limits.h (via GCC's > syslimits.h), figuring out how this is going wrong could be nontrivial. It > might be a new bug in trunk GCC's #include_next behavior, or it might be a > strange confluence of "correct" behavior and the particular circumstances > of your setup that we have just happened never to see before. > > So pick some one file that gets limits.h into its .d (aka .dt) file, run > that one compilation command by hand, and figure out how the include nest > is (not) working. Thanks for the suggestion. I'll look at the gcc commit log and see if there is anything that looks suspect, and perhaps build an older gcc and try to bisect the problem. Otherwise, a frontal attack. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077