Created attachment 645086 [details] mod_perl-2.0.11:20200616-151915.log.gz I *really* don't understand this one. x86_64-pc-linux-gnu-gcc -shared -O2 -pipe -mtune=native -march=native -fstack-protector-strong -fno-stack-protector -Wl,-O1 -Wl,--as-needed -fstack-protector-strong -fno-stack-protector \ \ mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_apache_compat.lo modperl_error.lo modperl_debug.lo modperl_common_util.lo modperl_common_log.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo modperl_exports.lo -Wl,-E -Wl,-O1 -Wl,--as-needed -fstack-protector-strong -fno-stack-protector -L/usr/lib64/perl5/5.30.3/x86_64-linux/CORE -lperl -ldl -lm -lcrypt -lutil -lc \ -o mod_perl.so x86_64-pc-linux-gnu-ranlib mod_perl.so x86_64-pc-linux-gnu-ranlib: mod_perl.so: file format not recognized make[1]: *** [Makefile:157: mod_perl.so] Error 1 make[1]: Leaving directory '/var/tmp/portage/www-apache/mod_perl-2.0.11/work/mod_perl-2.0.11/src/modules/perl' make: *** [Makefile:445: modperl_lib] Error 2 * ERROR: www-apache/mod_perl-2.0.11::gentoo failed (compile phase): * emake failed
(In reply to Kent Fredric (IRC: kent\n) from comment #0) > > I *really* don't understand this one. I don't either, but... I know what introduced it: + -Dranlib="$(tc-getRANLIB)" \ Removing just that part of the change to perl-5.30.2-r2 or perl-5.30.3-r1 and rebuilding perl makes it possible to emerge mod_perl again. Probably that's not the right fix because you added the tc-getRANLIB call for a reason, but one that I've not run into.
(In reply to Hank Leininger from comment #1) > (In reply to Kent Fredric (IRC: kent\n) from comment #0) > > > > I *really* don't understand this one. > > I don't either, but... I know what introduced it: > > + -Dranlib="$(tc-getRANLIB)" \ > > Removing just that part of the change to perl-5.30.2-r2 or perl-5.30.3-r1 > and rebuilding perl makes it possible to emerge mod_perl again. > > Probably that's not the right fix because you added the tc-getRANLIB > call for a reason, but one that I've not run into. Yeah. The question is, what happens when: a. You don't have that parameter b. And you don't have 'ranlib' in PATH c. And You've built dev-lang/perl under that configuration d. And you then build mod_perl My bets are on either "dev-lang/perl fails" or "mod_perl fails in a different way"
Created attachment 668999 [details, diff] Remove call to ranlib for dynamic library It's trying to run ranlib on a dynamic library, even though that tool is designed to work on static libraries. I wonder if this used to work with older binutils. It would appear that it's Apache2::Build that generates the Makefile with that call to ranlib – except on Darwin or OpenBSD. If I patch it to unconditionally omit that call, then the build succeeds.
(In reply to Chris Hall from comment #3) > Created attachment 668999 [details, diff] [details, diff] > Remove call to ranlib for dynamic library Thank you, this worked for me and was far simpler than my earlier workaround which was patching the perl ebuild (which of course, meant that the mod_perl problem returned after upgrading to 5.32).
Hi. What is the plan here? Are we going to update the ebuild with the patch? Report this upstream? Asking, as I just ran into this bug when trying to rebuild packages after upgrading perl from 5.30 to 5.32 on what I believe is an up to date system: x86_64-pc-linux-gnu-gcc -shared -march=ivybridge -O2 -pipe -Wl,-O1 -Wl,--as-needed \ \ mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_apache_compat.lo modperl_error.lo modperl_debug.lo modperl_common_util.lo modperl_common_log.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo modperl_exports.lo -Wl,-E -Wl,-O1 -Wl,--as-needed -L/usr/lib64/perl5/5.32/x86_64-linux-thread-multi/CORE -lperl -ldl -lm -lcrypt -lutil -lpthread -lc \ -o mod_perl.so x86_64-pc-linux-gnu-ranlib mod_perl.so x86_64-pc-linux-gnu-ranlib: mod_perl.so: file format not recognized make[1]: *** [Makefile:157: mod_perl.so] Error 1 make[1]: Leaving directory '/var/tmp/portage/www-apache/mod_perl-2.0.11/work/mod_perl-2.0.11/src/modules/perl' make: *** [Makefile:447: modperl_lib] Error 2 make: *** Waiting for unfinished jobs.... Yes, the patch fixes the issue for me, but I assume it is desired for mod_perl to work in Gentoo OOTB.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=27cca9bf1fd1d36ae3a736de7b7c9df00751604b commit 27cca9bf1fd1d36ae3a736de7b7c9df00751604b Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-05-08 13:02:25 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-05-08 13:03:09 +0000 www-apache/mod_perl: Fix build, bug 728554 Patch by Chris Hall Closes: https://bugs.gentoo.org/728554 Package-Manager: Portage-3.0.18, Repoman-3.0.2 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> www-apache/mod_perl/files/mod_perl-2.0.11-ranlib.patch | 11 +++++++++++ www-apache/mod_perl/mod_perl-2.0.11.ebuild | 3 ++- 2 files changed, 13 insertions(+), 1 deletion(-)
