Date: Tue, 01 Mar 2011 12:36:55 -0600 From: Stephen Montgomery-Smith <stephen@missouri.edu> To: "bf1783@gmail.com" <bf1783@gmail.com> Cc: "freebsd-ports@FreeBSD.org" <freebsd-ports@freebsd.org>, "gerald@FreeBSD.org" <gerald@freebsd.org>, "b. f." <bf1783@googlemail.com>, Ade Lovett <ade@freebsd.org> Subject: Re: multiple definition of `__i686.get_pc_thunk.bx' Message-ID: <4D6D3CC7.6000000@missouri.edu> In-Reply-To: <AANLkTimLkaBgYK4_4YWcRjva7cYZ7yKwp7QR4oS0Gbsw@mail.gmail.com> References: <AANLkTi=x1m%2BgJ5cRJDbCSHXRFEbr-EHC8VwrfMrNsAZj@mail.gmail.com> <4D6BB565.3050006@missouri.edu> <4D6C793C.7070803@missouri.edu> <AANLkTimLkaBgYK4_4YWcRjva7cYZ7yKwp7QR4oS0Gbsw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
b. f. wrote: > On 3/1/11, Stephen Montgomery-Smith<stephen@missouri.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D6D3CC7.6000000>