From owner-freebsd-ports@FreeBSD.ORG Mon Feb 28 15:00:23 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 6A3FC1065687; Mon, 28 Feb 2011 15:00:23 +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 E711C8FC1C; Mon, 28 Feb 2011 15:00:19 +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 p1SEl17o085131; Mon, 28 Feb 2011 08:47:01 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4D6BB565.3050006@missouri.edu> Date: Mon, 28 Feb 2011 08:47:01 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ade Lovett , "gerald@FreeBSD.org" , "b. f." , "freebsd-ports@FreeBSD.org" 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: Mon, 28 Feb 2011 15:00:23 -0000 b. f. wrote: >>> On Sun 27 Feb 2011 at 12:24:06 PST Stephen Montgomery-Smith wrote: >>>> I am the maintainer of the port vis5d+. I just got this email (copied below) saying that vis5d+ isn't building right now. >>>> >>>> The issue seems to be that some reference to __i686.get_pc_thunk.bx is included twice at some point. This variable seems to be part of an object file crtbeginS.o that is created by gcc or gcc45, in what seem to me to be very mysterious conditions. I am rather sure that the issue has nothing to do with vis5d+, but rather is something to do with either gcc45, or libtools, neither of which I understand. >>>> >>>> Does anyone out there have any idea of what the problem is, or how it can be solved? >>>> >> >> From a relatively cursory examination, this appears to be a flaw in the USE_FORTRAN=yes stanza. This will bring in gcc45 as a dependency but doesn't appear to be setting CXX to g++45 though it does do CC=gcc45. Possibly the same for LD, though I haven't checked that. > > 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. > > b. I agree. libtool is the real culprit. When you run it as libtool -mode=link g++45 stuff and stuff libtool uses c++ instead of g++45. I think it would be a relatively easy fix to make to libtool. I will even have a go at it myself if no-one else takes the baton, but I think it would be far easier for someone who knows libtool to do it. By the way, my proposed bandaid fix is this: ln -s /usr/local/bin/gcc45 ${WRKDIR}/cc ln -s /usr/local/bin/g++45 ${WRKDIR}/c++ MAKE_ENV += PATH=${WRKDIR}:$$PATH which could be put into bsd.gcc.mk. But it really is a very bad hack.