[Numpy-discussion] Is numpy ignoring CFLAGS?
Dr. David Kirkby
Mon Jun 28 10:50:32 CDT 2010
On 06/28/10 02:54 PM, David Cournapeau wrote:
> On Mon, Jun 28, 2010 at 9:28 PM, Dr. David Kirkby
> <email@example.com> wrote:
>> On 06/28/10 11:28 AM, David Cournapeau wrote:
>>> On Mon, Jun 28, 2010 at 6:56 PM, Dr. David Kirkby
>>>> Many other parts of Sage seem to inherit the flags ok from Python, but not numpy.
>>> Are you saying that OPT is not taken into account ? It seems to work
>>> for me, e.g.
>>> OPT="-m64" python setup.py build_ext
>>> does put -m64 somewhere in CFLAGS. When using numpy.distutils, CFLAGS
>>> should never be overriden unless you are ready to set up the whole set
>>> of options manually. By default, CFLAGS is the concatenation of
>>> BASECFLAGS, OPT and CCSHARED (in that order), and only OPT should be
>>> tweaked in general.
>>> NumPy-Discussion mailing list
>> OPT is not being totally ignored, but some part of numpy is trying to build
>> without taking -m64 into account.
>> Note in the output below that as numpy is compiled, -m64 is shown on some lines,
>> which is what I expect. But note also the messages about "wrong ELF class:
>> ELFCLASS64" from the linker, indicating to me the linker is not expecting to
>> find 64-bit objects.
> Ah, that makes the issue much clearer: the linker is not passed the
> -m64 option. It works with distutils because CFLAGS is appended to
> LDFLAGS if CFLAGS is in os.environ,but we use CFLAGS differently.
> I am not sure how to fix that issue...
I've tried adding -m64 to LDFLAGS before exporting that. That does not help.
Also, the Sun linker has this option -64 (note, no letter 'm').
drkirkby@hawk:~$ man ld
Reformatting page. Please Wait... done
User Commands ld(1)
ld - link-editor for object files
ld [-32 | -64] [-a | -r] [-b] [-Bdirect | nodirect]
[-B dynamic | static] [-B eliminate] [-B group] [-B local]
[-B reduce] [-B symbolic] [-c name] [-C] [-d y | n]
[-D token,...] [-e epsym] [-f name | -F name] [-G] [-h name]
[-i] [-I name] [-l x] [-L path] [-m] [-M mapfile]
[-N string] [-o outfile] [-p auditlib] [-P auditlib]
[-Q y | n] [-R path] [-s] [-S supportlib] [-t]
[-u symname] [-V] [-Y P,dirlist] [-z absexec]
[-z allextract | defaultextract | weakextract ]
[-z altexec64] [-z combreloc | nocombreloc ] [-z defs | nodefs]
[-z direct | nodirect] [-z endfiltee] [-z finiarray=function]
[-z globalaudit] [-z groupperm | nogroupperm] [-z help ]
[-z ignore | record] [-z initarray=function] [-z initfirst]
[-z interpose] [-z lazyload | nolazyload]
[-z ld32=arg1,arg2,...] [-z ld64=arg1,arg2,...]
[-z loadfltr] [-z muldefs] [-z nocompstrtab] [-z nodefaultlib]
[-z nodelete] [-z nodlopen] [-z nodump] [-z noldynsym]
[-z nopartial] [-z noversion] [-z now] [-z origin]
[-z preinitarray=function] [-z redlocsym] [-z relaxreloc]
[-z rescan-now] [-z recan] [-z rescan-start ... -z rescan-end]]
[-z target=sparc|x86] [-z text | textwarn | textoff]
[-z verbose] [-z wrap=symbol] filename...
The link-editor, ld, combines relocatable object files by
resolving symbol references to symbol definitions, together
The following options are supported.
-32 | -64
Creates a 32-bit, or 64-bit object.
By default, the class of the object being generated is
determined from the first ELF object processed from the
command line. If no objects are specified, the class is
determined by the first object encountered within the
first archive processed from the command line. If there
are no objects or archives, the link-editor creates a
The -64 option is required to create a 64-bit object
solely from a mapfile.
The -32 or -64 options can also be used in the rare case
of linking entirely from an archive that contains a mix-
ture of 32 and 64-bit objects. If the first object in
the archive is not the class of the object that is
required to be created, then the -32 or -64 option can
be used to direct the link-editor.
SunOS 5.11 Last change: 3 Dec 2009 3
User Commands ld(1)
I tried adding that to LDFLAGS. Again it did not help. The *only* solution I can
find to date is to create a script which invokes gcc with the -m64 option, but
that is a horrible hack.
More information about the NumPy-Discussion