#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 14 years ago by corwin.amber@…
comment:2 Changed 14 years ago by skymoo (Adam Mercer)
Cc: | ram@… removed |
---|---|
Owner: | changed from macports-tickets@… to ram@… |
Port: | py27-numpy added; py27-scipy removed |
Status: | new → assigned |
comment:3 Changed 14 years ago by jmroot (Joshua Root)
Cc: | mcalhoun@… added |
---|---|
Port: | py26-numpy added |
This was no doubt inherited from py26-numpy.
comment:4 Changed 14 years ago by skymoo (Adam Mercer)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
fixed in r74507, thanks
comment:5 Changed 14 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 follow-up: 7 Changed 14 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 Changed 14 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 14 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 14 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.
(typo: 'port' should be py27-numpy)