From owner-freebsd-current@FreeBSD.ORG Sat Jul 1 16:05:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 484F316A416 for ; Sat, 1 Jul 2006 16:05:08 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1209844044 for ; Sat, 1 Jul 2006 15:02:33 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 4F31F5DD8; Sat, 1 Jul 2006 11:02:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB-qXvPB3PSl; Sat, 1 Jul 2006 11:02:32 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-201-170.ny325.east.verizon.net [68.160.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id AF8865CB5; Sat, 1 Jul 2006 11:02:31 -0400 (EDT) Message-ID: <44A68E85.9080207@mac.com> Date: Sat, 01 Jul 2006 11:02:29 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kostik Belousov References: <200607010009.09231@aldan> <20060701122005.GC37822@deviant.kiev.zoral.com.ua> <44A681C3.3000309@mac.com> <20060701142020.GF37822@deviant.kiev.zoral.com.ua> In-Reply-To: <20060701142020.GF37822@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Mikhail Teterin Subject: Re: weird limitation on the system's binutils X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2006 16:05:08 -0000 Kostik Belousov wrote: > On Sat, Jul 01, 2006 at 10:08:03AM -0400, Chuck Swiger wrote: [ ... ] >> Note that the GNU tools themselves include a certain search path where they >> look for cross-compilation tools using long pathnames involving a tuple >> somewhat like the autoconf target specifier, something like: >> "toolname-vendor-arch-version" > Exactly, I have the impression that arch-vendor-system- > is the way to go if several crosstools are needed simultaneously. > And this is how GNU toolchain installs itself by default if > cross-compiling. Agreed. The work isn't so much in the GNU tools-- they've been cross-compile aware for a long, long time to their credit, although the filename conventions and path lookups are becoming more ornate than functional as time passes. I start to worry a bit about the extra overhead that lurks behind replacing a real, compiled compiler executable with a shell script that globs hither and yon through the filesystem in a quest to find yet more shell-script wrappers or other forms of indirection. [1] >> That much would still work on FreeBSD, but big issue comes in creating, >> importing, and updating the cross-platform shared resources in an organized >> fashion so that the GNU tools can find it, and there is a ton of glue work >> that goes into things like ld, ldd, ld.so.1, ar, and the Makefile >> infrastructure to fully support multi-architecture development. > Another issue is that, again AFAIK, interface between bfd and rest of binutils > code is highly fragile and changes in subtle ways between versions. > It is not supported and definitely causes bugs to mix bfd and the rest > from different version of binutils. Yeah, NeXT/Apple has to sit on or be very careful updating changes to the tools once they'd pushed out a release and needed to maintain backward binary compatibility. FreeBSD seems to do OK with this, except for C++-- where changing the symbol mangling or some such with each point release seems to be common. >> I'd be happy to help where I can with regard to this, but it's not a minor >> task-- there's a lot of moving pieces and work involved. > Completely agree. From my experience with cross-tools, I had to > carefully select version of binutils and gcc for given target. And, > sometimes, augment chosen version with patch found somewhere. > As I see it, having specific ports for each arch, that is maintained > individually, gives much less maintainance work. > > BTW, are there plans for updating binutils in the base system ? -- -Chuck [1]: For example, no doubt there exists broken compilers somewhere, for which wrapping every build line in an "if cc $MUMBLE >/dev/null 2>&1; then exit 1" wrapper would be beneficial rather than counterproductive. Doing it by default on a Unix system with a working toolchain is silly, and obviously, hides any useful warnings or errors from being displayed if there was a problem. And then there's autoconf playing Sorcerer's Apprentice by testing for stuff that has no bearing on the program being built (ie, looking for a Fortran compiler or trying to find sizeof() random Windows datatypes when building C99 code that uses int32_t or whatnot)...