From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15282 invoked by alias); 11 Oct 2010 15:09:52 -0000 Received: (qmail 15266 invoked by uid 22791); 11 Oct 2010 15:09:51 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Oct 2010 15:09:46 +0000 Received: (qmail 13742 invoked from network); 11 Oct 2010 15:09:44 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Oct 2010 15:09:44 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1P5K0V-00008x-Fd; Mon, 11 Oct 2010 15:09:43 +0000 Date: Mon, 11 Oct 2010 15:10:00 -0000 From: "Joseph S. Myers" To: Andi Kleen cc: Andi Kleen , gcc-patches@gcc.gnu.org, hubicka@ucw.cz Subject: Re: [PATCH 1/3] Add native ELF and LTO support in collect2 In-Reply-To: <20101011145646.GA9269@gargoyle.fritz.box> Message-ID: References: <1286792263-9244-1-git-send-email-andi@firstfloor.org> <20101011145646.GA9269@gargoyle.fritz.box> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-10/txt/msg00920.txt.bz2 On Mon, 11 Oct 2010, Andi Kleen wrote: > On Mon, Oct 11, 2010 at 02:33:07PM +0000, Joseph S. Myers wrote: > > On Mon, 11 Oct 2010, Andi Kleen wrote: > > > > > Controlled by a define in the OS specific config file. > > > I only enabled this on x86 Linux for now. > > > > OBJECT_FORMAT_ELF is already defined in elfos.h where it belongs (and in > > several target-specific headers where it doesn't belong - some duplicating > > the definition in elfos.h, others ELF targets that don't use elfos.h for > > whatever reason). > > What do you suggest? Use a different name? No. Just allow this code to apply for all ELF targets like it should, rather than trying to enable it specially only for one particular target. > > > +#if !defined (HAVE_LIBELF_H) || !defined (HAVE_GELF_H) \ > > > + || !defined (HAVE_UNISTD_H) || !defined (HAVE_FCNTL_H) \ > > > + || defined (CROSS_DIRECTORY_STRUCTURE) > > > > Why the CROSS_DIRECTORY_STRUCTURE conditional? > > I wasn't sure if the host libelf works from cross compilation. libelf should work for all targets for any host. > Also some of the other elf format code had checks for it so > I thought it was safer to exclude. What code are you talking about? The compiler should never behave differently for a particular target depending on the host unless you have a properly understood reason for it; such a difference certainly isn't "safer", it's dangerous. If it's a matter of non-GNU native linkers, the conditional should be on the choice of linker, not on whether it's a cross compiler. If it's a matter of native system headers describing an object file format, that won't apply with libelf (and in any case, adding equivalent GNU headers describing the format is the correct approach). CROSS_DIRECTORY_STRUCTURE should only ever be used when it is genuinely the *directory structure* - the locations of various files - that is relevant. -- Joseph S. Myers joseph@codesourcery.com