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...
_______________________________________________
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
