From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31001 invoked by alias); 2 Mar 2003 15:45:47 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 30994 invoked from network); 2 Mar 2003 15:45:46 -0000 Received: from unknown (HELO stardust.solidas.com) (217.13.28.68) by 172.16.49.205 with SMTP; 2 Mar 2003 15:45:46 -0000 Received: from solidas.com (217-13-28-85.dd.nextgentel.com [217.13.28.85]) (authenticated) by stardust.solidas.com (8.11.6/8.11.6) with ESMTP id h22Fjjd31577 for ; Sun, 2 Mar 2003 16:45:45 +0100 Message-ID: <3E622725.1040306@solidas.com> Date: Sun, 02 Mar 2003 15:45:00 -0000 From: "Svein E. Seldal" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: binutils@sources.redhat.com Subject: [RFC] BFD library installation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00016.txt.bz2 Hi, What is the exact motivation behind... 1) ... not installing libbfd.a per default when compiling cross targets. I have written a communication application for a specific development kit for the tic4x target, dsktools, and to be able to use the generated coff files from the GNU tools, I must rely on the BFD library. As libbfd.a is not installed per. default I now need to instruct all users of this program to install the library manually -- which I feel is cumbersome. Thus I wonder why binutils has taken this turn and made it this way... I tend to use the BFD library very often, and I dont quire see why it was removed. 2) ... installing the bfd library under a machine-specific directory. I must admit that I quite dont understand the motivation behind this! (please enlighten me.) When I compile the binutils on a linux host for the tic4x target, it will install the (host) binaries under $prefix/tic4x/bin and $prefix/bin. Why not still install the target-specific libbfd.a under $prefix/tic4x/lib as it once was? I mean, the other tools in $prefix/tic4x/bin is also host-specific executeables, right? All the tools that I have written that needs the libbfd.a library will now need a config.sub script lying around to properly discover the host-triplet. Thanks, Svein