Created attachment 616556 [details] requested information Upgrading gmp-ecm from v7.0.4-r1 to r2 fails in configuration phase: active compiler doesn't support openmp, which is required. This is wrong as use-flag "openmp" is *not* activated, so there is no need for gcc to support it... Attached you'll find the requested information files. CU Tom
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=960d8a87276d41050e18b644d6b4409c23ba2bdc commit 960d8a87276d41050e18b644d6b4409c23ba2bdc Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-02-29 16:02:02 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-02-29 16:03:28 +0000 sci-mathematics/gmp-ecm: fix openmp check. I screwed up the openmp check during translation from a manual tc-has-openmp() check to tc-check-openmp(). Fixed now, sorry! Closes: https://bugs.gentoo.org/711078 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/gmp-ecm/gmp-ecm-7.0.4-r2.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Now it compiles cleanly - THX for the fast fix. But there is another bug compiling this library: even though the use-flag "custom-tune" is set, the file ecm-params.h is *not* generated and tuned for the specific machine, resulting in poor performance, as the parameters for a i686 is used. When use-flag "custom-tune" is set, the command sequence needs to be: make -C athlon && make ecm-params && make Tuning phase will run for a few minutes (time used for smoking a cigarette), but the improvement in performance is more than noticeable. Personally I'm using this library to compute "home primes" (HP) for a given number: the number is factorized to it's prime factors, sorted in ascending order and concatenated forming a bigger number and factorized again, until only one prime factor is found - this is the so-called "home prime". Below you'll find the timings for a core-i5 for computing the HP for 112: - your setup: 9 minutes 7 seconds - tuned setup: 7 minutes 59 seconds The attached TAR holds the following files: - x86-ecm-params.h: default and slow parameter file - corei5-ecm-params.h: tuned parameters - hp-x86-112.log: log file with the default setup - hp-i5-112.log: log file with tuned setup - emerge.pqv: output of emerge -pqv gmp-ecm - emerge.info: output of emerge --info I guess the timings speek for itself, so please fix the compilation phase, when use-flag "custom-tune" is set. THX in advance. CU Tom
Created attachment 616702 [details] the TAR mentioned above
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01fa816214124421eb411b4fe0136af92cdc314a commit 01fa816214124421eb411b4fe0136af92cdc314a Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-03-01 13:28:15 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-03-01 13:58:34 +0000 sci-mathematics/gmp-ecm: fix USE=custom-tune. I overzealously removed the series of steps needed to build gmp-ecm with custom parameters in the -r2. We need to build, find the custom parameters, and then build again to reap the benefits. I left a comment in the ebuild to explain that to other, future mes. Bug: https://bugs.gentoo.org/711078 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/gmp-ecm/gmp-ecm-7.0.4-r2.ebuild | 10 ++++++++++ 1 file changed, 10 insertions(+)
Big THX for the speedy fix. Now ecm-params.h is generated, but *not* used - have a look at the attached info.broken, generated using "ecm -printconfig". I've aborted compilation during the installation phase - file build.log will show you, that after ecm-params.h has been generated, nothing is re-compiled using this file. The procedure is the same as for ecm v5 and ecm v6: after ecm-params.h has been generated, you'll need to clean up everything and compile it again, now using the tuned parameters... Speaking in terms of src_compile() inside the ebuild: default if use custom-tune; then emake ecm-params && emake clean && emake fi After the above procedure, "ecm -printinfo" will show the tuned parameters - see file info.tuned CU Tom
Created attachment 616768 [details] build.log and output of ecm -printinfo
Oof, did the custom-tuning work in 7.0.4-r1? I thought I put it back the way it was. In any case, I'll add the "emake clean" and wait for you to tell me it's OK before closing this again.
(In reply to Michael Orlitzky from comment #7) > Oof, did the custom-tuning work in 7.0.4-r1? I thought I put it back the way > it was. Obviously it didn't work for -r1 either, OTOH I don't watch emerge updating packages, unless only a single and small package needs to be updated... ;) But I was wondering why execution was significantly slower than using an older library version of ecm, which I built by hand... > In any case, I'll add the "emake clean" and wait for you to tell me it's OK > before closing this again. An eix-sync run wasn't able to fetch you're update, so I'll have to wait for replication to servers here in Germany. As I'll be busy this week, I'll find time to check it again at Saturday, so you've to be patient... In the meantime THX for your efforts so far. :) CU Tom
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f503f4650237eee281e0fb2b1afab795af2b21c5 commit f503f4650237eee281e0fb2b1afab795af2b21c5 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-03-02 14:03:40 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-03-02 17:20:46 +0000 sci-mathematics/gmp-ecm: add "emake clean" to force a rebuild. Taking another shot at making USE=custom-tune do what it's supposed to do. The project's targets don't depend on ecm-params.h, so after we generate them, we need to "emake clean" and rebuild everything manually in order to use the custom parameters. Bug: https://bugs.gentoo.org/711078 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/gmp-ecm/gmp-ecm-7.0.4-r2.ebuild | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Okay, now it works as expected, so you're able to finally close this bug. Again THX for your efforts. :) CU Tom
Thank you for making sure that it got fixed!
