| Subject: | Compile fails with "x86_64-pc-linux-gnu-ranlib: mod_perl.so: file format not recognized" when perl built with -Dranlib |
We've been testing some changes to layouts and availability of various "defaults" for binutils/gcc stuff, such that:
- There is no gcc, ranlib, etc in $PATH
- $CHOST-$util should be used instead ( eg: x86_64-pc-linux-gnu-ranlib , x86_64-pc-linux-gnu-gcc )
And this combo is somewhat important when trying to ensure cross-compile stuff works, and helps replicate what things will look like platforms which don't have any of the standard tools in $PATH ( or there are tools in $PATH that look like the right ones, but they are the wrong ones) , and configuration *must* be done to get it work properly.
To get this working, perl autodetection has to be subverted, because it detects wrong, and everything uses perl's autodetection.
eg:
-Dcc="$(tc-getCC)" \
-Dar="$(tc-getAR)" \
-Dnm="$(tc-getNM)" \
-Dcpp="$(tc-getCPP)" \
-Dranlib="$(tc-getRANLIB)" \
Where tc-getFOO is our build toolchain function for returning the right values.
Nothing else that I know of has yet tripped up from doing this, and for the most part, it fixes a lot of build problems
But mod_perl hits a bit of a roadbump:
https://bugs.gentoo.org/728554
--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
- There is no gcc, ranlib, etc in $PATH
- $CHOST-$util should be used instead ( eg: x86_64-pc-linux-gnu-ranlib , x86_64-pc-linux-gnu-gcc )
And this combo is somewhat important when trying to ensure cross-compile stuff works, and helps replicate what things will look like platforms which don't have any of the standard tools in $PATH ( or there are tools in $PATH that look like the right ones, but they are the wrong ones) , and configuration *must* be done to get it work properly.
To get this working, perl autodetection has to be subverted, because it detects wrong, and everything uses perl's autodetection.
eg:
-Dcc="$(tc-getCC)" \
-Dar="$(tc-getAR)" \
-Dnm="$(tc-getNM)" \
-Dcpp="$(tc-getCPP)" \
-Dranlib="$(tc-getRANLIB)" \
Where tc-getFOO is our build toolchain function for returning the right values.
Nothing else that I know of has yet tripped up from doing this, and for the most part, it fixes a lot of build problems
But mod_perl hits a bit of a roadbump:
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'And its really not clear to me why this is happening.
https://bugs.gentoo.org/728554
--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )