From owner-freebsd-ports@FreeBSD.ORG Tue Mar 1 18:36:57 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5919E1065670; Tue, 1 Mar 2011 18:36:57 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0288E8FC16; Tue, 1 Mar 2011 18:36:56 +0000 (UTC) Received: from [128.206.184.213] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.4/8.14.4) with ESMTP id p21Iatwc097292; Tue, 1 Mar 2011 12:36:55 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4D6D3CC7.6000000@missouri.edu> Date: Tue, 01 Mar 2011 12:36:55 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.16) Gecko/20101225 SeaMonkey/2.0.11 MIME-Version: 1.0 To: "bf1783@gmail.com" References: <4D6BB565.3050006@missouri.edu> <4D6C793C.7070803@missouri.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@FreeBSD.org" , "gerald@FreeBSD.org" , "b. f." , Ade Lovett Subject: Re: multiple definition of `__i686.get_pc_thunk.bx' X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 18:36:57 -0000 b. f. wrote: > On 3/1/11, Stephen Montgomery-Smith wrote: >> Stephen Montgomery-Smith wrote: >>> b. f. wrote: >>>>>> On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: > ... >>>> >>>> As is clear from bsd.gcc.mk, in almost every case now in use, >>>> USE_FORTRAN sets _USE_GCC, which sets CC, CPP, and CXX to the proper >>>> values. Also, it sets USE_BINUTILS where appropriate, which sets LD, >>>> etc. The problem is rather with libtool, particularly in the link >>>> mode, where it may not respect the choice of compiler and toolchain. >>>> This problem has been remarked, for two years or more, in the mailing >>>> lists and forums, when people discuss the use of compilers other than >>>> the base system compiler. With the recent updates, it is more >>>> obtrusive, and several ports that were building successfully with >>>> default settings are now broken. This needs to be fixed, and it would >>>> be better to fix libtool than to add a bunch of ad-hoc fixes to >>>> individual ports. > ... >> >> OK, this problem was more subtle than I originally thought. The error I >> pointed out doesn't occur consistently, but it does occur in the context >> of building vis5d+. >> >> But I have a patch that definitely fixes libtool enough for me. What do >> you guys think? This perhaps doesn't fix all the problems, but maybe it >> can act as a model to fix them all. >> >> > > libtool caches more than just the compiler name. It also stores the > path to various utilities (ar, as, ld, etc.), various compiler flags, > compiler search directories, (pre|post)dep objects, etc. These aren't > always used, but they may sometimes be important, and they vary among > the different compilers in ports, so I think that any modifications > should take these into account. One of the problems is that the > upstream developers didn't think that (outside of cross-building, > which is handled a bit differently) more than one toolchain would be > in use on a given system. On my system I adopted the expedient of > modifying bsd.autotools.mk and adding separate per-compiler libtool > ports. That's not the prettiest way of handlng this problem either, > and it is awkward for the libltdl ports, so I'm not saying that this > method should be adopted. > > b. But maybe one could patch libtool by putting a similar if statement around every tool, to see if there is a similar tool already defined by the environment: if test -z "\$CXX"; then \\ CC=$lt_compiler_CXX else CC=\$CXX fi