Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#27688 closed defect (fixed)

py27-numpy @1.5.1 Build ignores archflags

Reported by: corwin.amber@… Owned by: skymoo (Adam Mercer)
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Port: py27-numpy py26-numpy

Description

I am building on Intel Mac OS X 10.6.5 with:

build_arch                x86_64
macosx_deployment_target  10.5

Which causes gcc-4.0 to be used as the C compiler. Architecture-specific flags are passed to setup.py as CFLAGS, LDFLAGS etc., but numpy.distutils ignores LDFLAGS, which causes link to fail immediately due to mach-o mismatch:

:info:build C compiler: /usr/bin/gcc-4.0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch x86_64
:info:build
:info:build compile options: '-c'
:info:build gcc-4.0: _configtest.c
:info:build /usr/bin/gcc-4.0 _configtest.o -L/opt/local/lib -llapack -lptf77blas -lptcblas -latlas -o _co
nfigtest
:info:build ld: warning: in _configtest.o, file was built for unsupported file format which is not the ar
chitecture being linked (i386)
:info:build Undefined symbols:
:info:build   "_main", referenced from:
:info:build       start in crt1.10.5.o
:info:build ld: symbol(s) not found

I didn't try this, but I suspect the problem will also affect users of 10.6 without macosx_deployment_target trying to compile 32-bit libraries (are there any?).

In my case, I managed to circumvent this issue by adding the following line to the Portfile:

build.env-append        ARCHFLAGS="${configure.ld_archflags}"

Change History (9)

comment:1 Changed 10 years ago by corwin.amber@…

(typo: 'port' should be py27-numpy)

comment:2 Changed 10 years ago by skymoo (Adam Mercer)

Cc: ram@… removed
Owner: changed from macports-tickets@… to ram@…
Port: py27-numpy added; py27-scipy removed
Status: newassigned

comment:3 Changed 10 years ago by jmroot (Joshua Root)

Cc: mcalhoun@… added
Port: py26-numpy added

This was no doubt inherited from py26-numpy.

comment:4 Changed 10 years ago by skymoo (Adam Mercer)

Resolution: fixed
Status: assignedclosed

fixed in r74507, thanks

comment:5 Changed 10 years ago by jmroot (Joshua Root)

Won't that do the wrong thing with +universal? I actually have my doubts about whether the universal variant works anyway, but I haven't tested it, so maybe it does.

comment:6 Changed 10 years ago by skymoo (Adam Mercer)

I don't use universal and have never got universal to work right on my system, so I don't know. Personally I can't see the point of universal for numpy etc..

comment:7 in reply to:  6 Changed 10 years ago by corwin.amber@…

I tried in fact and it really doesn't work, nor did it work before. It appears the MacPorts gcc lacks the Apple extension which enables the creation of universal binaries. Since gfortran-mp-4.4 is used for linking, even if the link flags are set to "-arch i386 -arch x86_64", they will be ignored.

comment:8 Changed 10 years ago by jmroot (Joshua Root)

Yeah, that's about what I thought would happen when using the gccXX variants. So they should conflict with universal at least. It might still work with -atlas though?

comment:9 Changed 10 years ago by jmroot (Joshua Root)

Universal should work as well as it ever did, and not be allowed when using +atlas, as of r74567.

Note: See TracTickets for help on using tickets.