multiple definition of `__i686.get_pc_thunk.bx'

[Stephen Montgomery-Smith]

b. f. wrote:
> On 3/1/11, Stephen Montgomery-Smith<stephen at 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