py-numpy build failure, multiple definition of `__i686.get_pc_thunk.bx'

[Charlie Kester]

On Fri 04 Feb 2011 at 11:54:00 PST Kostik Belousov wrote:
>On Fri, Feb 04, 2011 at 10:55:12AM -0800, Charlie Kester wrote:
>> On Fri 04 Feb 2011 at 02:05:44 PST Kostik Belousov wrote:
>> 
>> >Can you show the actual invocation of the compiler driver for linking ?
>> 
>> Isn't that the line right before the first report of the error?
>> 
>> cc -shared -pthread -mtune=generic -msse -msse2 -msse3 -mfpmath=sse -O2 
>> -fno-strict-aliasing -pipe -Wl,-rpath=/usr/local/lib/gcc45 
>> build/temp.freebsd-8.2-PRERELEASE-i386-2.7/build/src.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/src/_sortmodule.o -Lbuild/temp.freebsd-8.2-PRERELEASE-i386-2.7 -lm -o build/lib.freebsd-8.2-PRERELEASE-i386-2.7/numpy/core/_sort.so
>> 
>I wanted the confirmation of exact command that failed. If your
>citation above is right, then port _does not_ use gcc45 to do linkage
>of the module. Generally, crtbegin/crtend.o come from the compiler
>installation, so I am suspicious at least to report of use of
>/usr/lib/crtbegin.So.
>
>Can you enter the port build directory and execute the same command
>manually, substituting "cc" with full path to gcc45 ?

Done.  Replacing "cc" with "gcc45" built the library without any error.
(I didn't need to specify the full path to gcc45.)

So the question is, why is cc being invoked in the first place?  As far
as I know, I'm not doing anything to force using it.  Something seems to
have gone wrong during py-numpy's configtests...