Hello,
I have an extension module that uses math.h. In order to compile it on Linux with gcc, it needs to link with libm. However, using libraries=['m'] leads to a linker error when using mingw32 on Windows.
At the moment my setup.py contains something like:
libraries = [] if not 'win' in sys.platform: libraries.append('m')
This works for the two cases I user personally. I'm guessing, though, that I should really be checking for something more specific, perhaps to do with the compiler that is being used. I guess that using math.h and wanting cross-platform compilation is probably quite a common case. So I wondered if anyone who knows more than me about c-compilers and distutils has a better suggestion for this.
Apologies if this is mentioned somewhere already. The only thing I could find in the docs was instructions for adding linker options when installing python modules. Ideally, I'd like to be able to handle this in my setup.py without needing the setup.py user to manually alter the linker settings.
Thanks, Oscar.
Oscar Benjamin oscar.benjamin@bristol.ac.uk writes:
Hello,
I have an extension module that uses math.h. In order to compile it on Linux with gcc, it needs to link with libm. However, using libraries=['m'] leads to a linker error when using mingw32 on Windows.
At the moment my setup.py contains something like:
libraries = [] if not 'win' in sys.platform: libraries.append('m')
that fails on OS X - if I remember correctly
This works for the two cases I user personally. I'm guessing, though, that I should really be checking for something more specific, perhaps to do with the compiler that is being used. I guess that using math.h and wanting cross-platform compilation is probably quite a common case. So I wondered if anyone who knows more than me about c-compilers and distutils has a better suggestion for this.
Apologies if this is mentioned somewhere already. The only thing I could find in the docs was instructions for adding linker options when installing python modules. Ideally, I'd like to be able to handle this in my setup.py without needing the setup.py user to manually alter the linker settings.
I'm not quite sure if it's the right way to do it, but I solved that with the following code:
,---- | from distutils import sysconfig | | if sysconfig.get_config_var("LIBM") == "-lm": | libraries = ["m"] | else: | libraries = [] `----
(e.g. in https://github.com/pediapress/timelib/commit/70a8a9c42ff005fbb3547cc6b300da0...)
,---- | from distutils import sysconfig | | if sysconfig.get_config_var("LIBM") == "-lm": | libraries = ["m"] | else: | libraries = [] `----
Thanks, that does look better. If I understand correctly that snippet will check to see if python was linked with libm and ensure that my extension module will also be only if python was. I tested it with Linux and Windows and it works and seems a lot more robust than what I had before.
Would it be slightly better to test just for the existence of the LIBM configuration variable rather than its value? I don't know of an example, but I guess a system could have libm but use a compiler with a different linker argument format.
e.g. if 'libm' in sysconfig.get_config_vars()
Is there a more general way to discover if the compiler that is going to be used knows of a library with a specified name? Something like
if get_compiler_type().library_exists(libname)
Thanks, Oscar.
On Wed, Nov 23, 2011 at 01:22:00PM +0100, Ralf Schmitt wrote:
Oscar Benjamin oscar.benjamin@bristol.ac.uk writes:
Hello,
I have an extension module that uses math.h. In order to compile it on Linux with gcc, it needs to link with libm. However, using libraries=['m'] leads to a linker error when using mingw32 on Windows.
At the moment my setup.py contains something like:
libraries = [] if not 'win' in sys.platform: libraries.append('m')
that fails on OS X - if I remember correctly
This works for the two cases I user personally. I'm guessing, though, that I should really be checking for something more specific, perhaps to do with the compiler that is being used. I guess that using math.h and wanting cross-platform compilation is probably quite a common case. So I wondered if anyone who knows more than me about c-compilers and distutils has a better suggestion for this.
Apologies if this is mentioned somewhere already. The only thing I could find in the docs was instructions for adding linker options when installing python modules. Ideally, I'd like to be able to handle this in my setup.py without needing the setup.py user to manually alter the linker settings.
I'm not quite sure if it's the right way to do it, but I solved that with the following code:
,---- | from distutils import sysconfig | | if sysconfig.get_config_var("LIBM") == "-lm": | libraries = ["m"] | else: | libraries = [] `----
(e.g. in https://github.com/pediapress/timelib/commit/70a8a9c42ff005fbb3547cc6b300da0...)
-- Cheers Ralf
Oscar Benjamin oscar.benjamin@bristol.ac.uk writes:
Would it be slightly better to test just for the existence of the LIBM configuration variable rather than its value? I don't know of an example, but I guess a system could have libm but use a compiler with a different linker argument format.
e.g. if 'libm' in sysconfig.get_config_vars()
No, the following is from OS X: ,---- | >>> from distutils import sysconfig | >>> sysconfig.get_config_var("LIBM") | '' `----
Is there a more general way to discover if the compiler that is going to be used knows of a library with a specified name? Something like
if get_compiler_type().library_exists(libname)
It's probably possible with some custom distutils command, but it's also not worth it IMHO.
On 11/23/11 10:07, Ralf Schmitt wrote:
Oscar Benjaminoscar.benjamin@bristol.ac.uk writes:
Would it be slightly better to test just for the existence of the LIBM configuration variable rather than its value? I don't know of an example, but I guess a system could have libm but use a compiler with a different linker argument format.
e.g. if 'libm' in sysconfig.get_config_vars()
No, the following is from OS X: ,---- |>>> from distutils import sysconfig |>>> sysconfig.get_config_var("LIBM") | '' `----
It may not matter. On my Mac (Snow Leopard), it wants to use built-in functions provided by gcc for everything that I've tried that is in -lm on other machines. There is a /usr/lib/libm.dylib, but a little searching (/bin, /usr/bin, my own custom python install) did not find anything on my machine that actually uses it.
"cc c.c" and "cc c.c -lm" produce identical a.out files.
participants (3)
-
Mark Sienkiewicz -
Oscar Benjamin -
Ralf Schmitt