setup.py --prefix should not be overriden

[GoogleCodeExporter]

Currently, the setup.py overrides --prefix to specify where to find libraries 
like GMP, MPFR or MPC. However, the --prefix is already used by distutils to 
specify where things should be installed. By overriding it, the user can't use 
it anymore for this purpose.

One solution is to use --library-prefix or some other name for the current 
purpose of --prefix, and leave --prefix for distutils to use.

Original issue reported on code.google.com by ondrej.c...@gmail.com on 11 Feb 2015 at 11:55

[GoogleCodeExporter]

Hi,

I started using --prefix when gmpy2 relied on very recent versions of GMP, 
MPFR, and MPC and gmpy2 didn't support static linking. Since most Linux 
distributions provide recent versions of GMP, MPFR, and MPC and gmpy2 now 
supports static linking, what do you think of the following?

Use --static=<<path>> to specify the location for static files and use 
--shared=<<path>> to specify the location for shared libraries in a 
non-standard location.

Is a patch sufficient for the short-term or do you want me create a new release?

Original comment by casevh on 12 Feb 2015 at 3:30

• Changed state: Accepted

[GoogleCodeExporter]

I've committed a patch to the gmpy2_maint branch in r1030.

https://code.google.com/p/gmpy/source/browse/tags/gmpy2_maint/setup.py

Can you test it?

Original comment by casevh on 12 Feb 2015 at 6:19

[GoogleCodeExporter]

I am testing it. Another problem is that on my other system the GMP, MPFR and 
MPC libraries are installed in separate locations, so a single --static or 
--shared option doesn't help. I need --mpfr-lib-root, --gmp-lib-root and 
--mpc-lib-root options at least.

Original comment by ondrej.c...@gmail.com on 12 Feb 2015 at 11:29

[GoogleCodeExporter]

So it doesn't seem to work. On Sage math cloud:

~/repos/gmpy-read-only$ python setup.py install --shared=~/repos/hashstack/gmpy 
--prefix=xx
running install
running build
running build_ext
----------------------------------------------------------------
setup.py was not able to detect the required versions of MPFR
and/or MPC. gmpy2 requires MPFR version 3.1.0 or greater and
MPC version 1.0.0 or greater. To specify a directory prefix that
contains the proper versions, use the --prefix=<dir> option.

In some circumstances, the correct versions may be present and
this warning can be ignored. If you have difficulties compiling
or running gmpy2, please try compiling with the --prefix option.

setup.py will still continue and attempt to compile gmpy2.
-----------------------------------------------------------------
building 'gmpy2' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC -I./src -I/usr/include/python2.7 -c src/gmpy2.c -o
 build/temp.linux-x86_64-2.7/src/gmpy2.o
In file included from src/gmpy2.c:399:0:
src/gmpy2.h:225:17: fatal error: mpc.h: No such file or directory
 #include "mpc.h"
                 ^
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
~/repos/gmpy-read-only$ vim setup.py
~/repos/gmpy-read-only$ ls ~/repos/hashstack/gmpy/include
bzlib.h  gmpxx.h  mpf2mpfr.h  mpi_base.mod       mpicxx.h  mpi.h    mpiof.h  
mpi_sizeofs.mod  opa_config.h      opa_queue.h  openssl     python2.7  
sqlite3ext.h  zconf.h  zmq.h
gmp.h    mpc.h    mpfr.h      mpi_constants.mod  mpif.h    mpi.mod  mpio.h   
ncurses          opa_primitives.h  opa_util.h   primitives  readline   
sqlite3.h     zlib.h   zmq_utils.h

As you can see, the path is correct and it contains mpc.h, but gmpy can't find 
it.

Original comment by ondrej.c...@gmail.com on 12 Feb 2015 at 11:46

[GoogleCodeExporter]

Thanks for the tests. Regarding the need to specify multiple source 
directories, I'll change --shared and --static to accept multiple directories 
separated by colons.

For the other issue, I did not call os.path.expanduser() on the input so if 
failed on the ~ character.

It may be a couple of days before I have a new version to test.

Original comment by casevh on 13 Feb 2015 at 5:20

[GoogleCodeExporter]

Hi,

I've committed a newer version in r1034 that should work better. 

The expansion of ~ should be fixed.

--shared and --static both accept multiple directory names separated by colons. 

Using --shared=<dir list> is just shorthand for using:

--include-dirs=<dir_list> --library-dirs=<dir_list> --rpath=<dir_list>

If someone is using the system provided GMP, MPFR, and MPC libraries, then 
--shared is not needed. If you are using locally compiled versions, then I also 
set --rpath to specify where the libraries should be found at runtime. If you 
modify ldconfig and don't want --rpath set, you can just use --include-dirs and 
--library-dirs.

Original comment by casevh on 15 Feb 2015 at 7:05

[GoogleCodeExporter]

I have released 2.0.6 which should fix the issue.

Original comment by casevh on 6 Jul 2015 at 6:09

• Changed state: Fixed