php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #50990 gmp extension doesn't compile with gmp 5.0.1
Submitted: 2010-02-10 08:59 UTC Modified: 2010-02-23 11:10 UTC
Votes:5
Avg. Score:4.8 ± 0.4
Reproduced:5 of 5 (100.0%)
Same Version:4 (80.0%)
Same OS:3 (60.0%)
From: php-bugs-2010 at ryandesign dot com Assigned:
Status: Closed Package: GNU MP related
PHP Version: 5.3.2RC1 OS: Mac OS X 10.6.2
Private report: No CVE-ID: None
View Developer Edit
 [2010-02-10 08:59 UTC] php-bugs-2010 at ryandesign dot com 
Description:
------------
The gmp extension doesn't compile with gmp 5.0.1. This used to work with 
gmp 4.3.2.

Reproduce code:
---------------
1. cd /path/to/php-5.3.2RC1
2. ./configure --disable-all --with-gmp=/opt/local
3. make

Expected result:
----------------
successful compile

Actual result:
--------------
/bin/sh /path/to/php-5.3.2RC1/libtool --silent --preserve-dup-deps --
mode=compile gcc  -Iext/gmp/ -I/path/to/php-5.3.2RC1/ext/gmp/ -
DPHP_ATOM_INC -I/path/to/php-5.3.2RC1/include -I/path/to/php-
5.3.2RC1/main -I/path/to/php-5.3.2RC1 -I/path/to/php-
5.3.2RC1/ext/date/lib -I/path/to/php-5.3.2RC1/ext/ereg/regex -
I/opt/local/include -I/path/to/php-5.3.2RC1/TSRM -I/path/to/php-
5.3.2RC1/Zend  -no-cpp-precomp  -g -O2 -fvisibility=hidden  -c 
/path/to/php-5.3.2RC1/ext/gmp/gmp.c -o ext/gmp/gmp.lo 
/path/to/php-5.3.2RC1/ext/gmp/gmp.c: In function ?zif_gmp_random?:
/path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: 
?__GMP_BITS_PER_MP_LIMB? undeclared (first use in this function)
/path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: (Each undeclared 
identifier is reported only once
/path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: for each function it 
appears in.)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-10 09:31 UTC] pajoye@php.net 
I would suggest to go with MPIR instead. GMP 5.x breaks ABI badly and is also not compatible with PHP, from a license point of view.
 [2010-02-10 10:23 UTC] juri dot saltbacka at gmail dot com 
It is important because ZendFramework depends on GMP. At least on Mac OS 
X
 [2010-02-10 10:56 UTC] pajoye@php.net 
ZF depends on the gmp php extension, which can be built against MPIR instead of gmplib. See http://www.mpir.org/. It is a rock solid gmp compatible library with much better support for modern architecture and optimizations, without the (l)gpl v3 license madness.
 [2010-02-17 15:52 UTC] susan dot smith dot dev at gmail dot com 
Don't be silly! MPIR gives better support for Windows, not for "modern architecture", on POSIX systems GMP (http://gmplib.org/) is usually better... and LGPL v3 is as compatible with the licence of PHP as LGPL v2 is.

I solved replacing the outdated __GMP_BITS_PER_MP_LIMB defined constant with GMP_LIMB_BITS. The latter is present in all previous versions, and MPIR define it too.
 [2010-02-18 18:11 UTC] vikingjs at mac dot com 
Thanks, Susan - that substitution (in gmp.c on line 1362 for those 
following at home) got me over this hurdle as well.
 [2010-02-18 22:52 UTC] pajoye@php.net 
@susan dot smith dot dev at gmail dot com 

Please stay pollite. 

MPIR has more maintainers, more open and active. Yes, GMP is still under development, but that's about it. Now about lgpl v3, we are certainly not on the same line.
 [2010-02-19 08:26 UTC] susan dot smith dot dev at gmail dot com 
@ pajoye at php dot net

I should probably ignore your comment, simply...

Was I not polite? Why?
Did I say that someone choice are "madness"? Or I simply said that different libraries give different support to different systems? Users should be free to make their own choice, shouldn't they?

Some PHP users asked for a very small compatibility issue, and someone here suggested them to change the library they are using... This is not respect for users choices, is it?

I suggested a very simple change. With it, PHP will be compatible with old GMP versions, with the last GMP version, with old MPIR versions and with the last MPIR version. You may say that suggesting such a small change is not polite, maybe... but it solved the problems to the users.
Is there someone that is using this ticket for propaganda? Instead of using it for bug-tracking? Read the entire thread and guess who :-)

I suggest to close this discussion this way: verify if the suggested change breaks anything, apply it, and close the ticket. Sorry if you feel this last suggestion as not polite.

I'll not answer any more, the bug was solved.
 [2010-02-23 11:10 UTC] pajoye@php.net 
@susan dot smith dot dev at gmail dot com 

Thing is your emotional replies have simply little to do with the actual issues (the technical one is indeed easy to fix).

We have to be careful that no viral (no bad meaning here) licensed code got in or is used with php, to avoid troubles. We have met issues already with the same kind of license changes and we really don't want this mess again. 

That has nothing to do with propaganda or any other pollitical discussions. PHP is known to have a very liberal license and what we provide usually have no limitation for commercial/closed source/free softwares usage. 

Now, about the issue, I applied a fix that should work with (very) old versions as well.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 22:01:28 2024 UTC