Description of problem: The Apache2::Request Perl module can not be loaded as it can not find the apreq_handle_apache2 symbol in libapreq2: $ perl -MApache2::Request -e 1 Can't load '/usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so' for module APR::Request::Apache2: /usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 at /usr/lib64/perl5/DynaLoader.pm line 193. at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. Compilation failed in require at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. Compilation failed in require. BEGIN failed--compilation aborted. Version-Release number of selected component (if applicable): $ rpm -q libapreq2-libs perl-libapreq2 libapreq2-libs-2.13-29.fc27.x86_64 perl-libapreq2-2.13-29.fc27.x86_64
I also have this exact same problem, which is a showstopper on our production system ldd -r /usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so linux-vdso.so.1 (0x00007ffc5d1cc000) libapreq2.so.3 => /usr/lib/libapreq2.so.3 (0x00007feff81f8000) libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007feff7fcb000) libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007feff7d94000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007feff7b75000) libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007feff7971000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007feff773f000) libperl.so.5.26 => /usr/lib64/libperl.so.5.26 (0x00007feff7339000) libc.so.6 => /usr/lib64/libc.so.6 (0x00007feff6f56000) libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007feff6d51000) libcrypt.so.1 => /usr/lib64/libcrypt.so.1 (0x00007feff6b1b000) /lib64/ld-linux-x86-64.so.2 (0x00007feff860a000) libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007feff6901000) libnsl.so.1 => /usr/lib64/libnsl.so.1 (0x00007feff66e7000) libm.so.6 => /usr/lib64/libm.so.6 (0x00007feff6392000) libutil.so.1 => /usr/lib64/libutil.so.1 (0x00007feff618f000) libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007feff5f8c000) undefined symbol: apreq_handle_apache2 (/usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so) undefined symbol: modperl_xs_sv2request_rec (/usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so) and OK in Apache 2.4 LoadModule apreq_module modules/mod_apreq2.so
It might be a problem with a newer perl version (5.20.3 versus 5.26.1) perl -MApache2::Request -e 1 is compiling without problems using 5.20.3 However ldd -r /usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so is displaying the same output as above on a working Fedora 22 system but otherwise not causing problems on an Apache 2.2 After also installing mod_apreq2.so and mod_perl on Apache 2.4 it apparently is working. Summary of my perl5 (revision 5 version 20 subversion 3) configuration: ----------------------------------------------------------------------- Platform: osname=linux, osvers=4.4.9-300.fc23.x86_64, archname=x86_64-linux-thread-multi uname='linux buildvm-10.phx2.fedoraproject.org 4.4.9-300.fc23.x86_64 #1 smp wed may 4 23:56:27 utc 2016 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.20.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic', cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='5.3.1 20160406 (Red Hat 5.3.1-6)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib libs=-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.21.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.21' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API USE_SITECUSTOMIZE Locally applied patches: Fedora Patch1: Removes date check, Fedora/RHEL specific Fedora Patch3: support for libdir64 Fedora Patch4: use libresolv instead of libbind Fedora Patch5: USE_MM_LD_RUN_PATH Fedora Patch6: Skip hostname tests, due to builders not being network capable Fedora Patch7: Dont run one io test due to random builder failures Fedora Patch15: Define SONAME for libperl.so Fedora Patch16: Install libperl.so to -Dshrpdir value Fedora Patch22: Document Math::BigInt::CalcEmu requires Math::BigInt (CPAN RT#85015) Fedora Patch25: Use stronger algorithm needed for FIPS in t/op/crypt.t (RT#121591) Fedora Patch26: Make *DBM_File desctructors thread-safe (RT#61912) Fedora Patch27: Report inaccesible file on failed require (RT#123270) Fedora Patch28: Use stronger algorithm needed for FIPS in t/op/taint.t (RT#123338) Fedora Patch29: Fix debugger y command scope level Fedora Patch30: Fix CVE-2016-2381 (ambiguous environment variables handling) Fedora Patch31: Fix CVE-2015-8853 (regexp matching hangs on illegal UTF-8) Fedora Patch32: Fix duplicating PerlIO::encoding when spawning threads (RT#31923) Fedora Patch33: Do not let XSLoader load relative paths (RT#115808) Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux Built under linux Compiled at Jul 7 2016 14:37:25 @INC: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . Summary of my perl5 (revision 5 version 26 subversion 1) configuration: ----------------------------------------------------------------------- Platform: osname=linux osvers=4.14.11-300.fc27.x86_64 archname=x86_64-linux-thread-multi uname='linux buildvm-26.phx2.fedoraproject.org 4.14.11-300.fc27.x86_64 #1 smp wed jan 3 13:52:28 utc 2018 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=none -Dccflags=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Dldflags=-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Dlddlflags=-shared -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.26.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize -Duse64bitint' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='gcc' ccflags ='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' optimize=' -g' cppflags='-D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fwrapv -fno-strict-aliasing -I/usr/local/include' ccversion='' gccversion='7.2.1 20170915 (Red Hat 7.2.1-2)' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='gcc' ldflags ='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib libs=-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.26.so so=so useshrplib=true libperl=libperl.so gnulibc_version='2.26' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,--enable-new-dtags -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' cccdlflags='-fPIC' lddlflags='-shared -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_OP_PARENT PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API USE_SITECUSTOMIZE Locally applied patches: Fedora Patch1: Removes date check, Fedora/RHEL specific Fedora Patch3: support for libdir64 Fedora Patch4: use libresolv instead of libbind Fedora Patch5: USE_MM_LD_RUN_PATH Fedora Patch6: Provide MM::maybe_command independently (bug #1129443) Fedora Patch7: Dont run one io test due to random builder failures Fedora Patch15: Define SONAME for libperl.so Fedora Patch16: Install libperl.so to -Dshrpdir value Fedora Patch22: Document Math::BigInt::CalcEmu requires Math::BigInt (CPAN RT#85015) Fedora Patch26: Make *DBM_File desctructors thread-safe (RT#61912) Fedora Patch27: Make PadlistNAMES() lvalue again (CPAN RT#101063) Fedora Patch30: Replace EU::MakeMaker dependency with EU::MM::Utils in IPC::Cmd (bug #1129443) Fedora Patch31: Make File::Glob more resistant against degenerative matching (RT#131211) Fedora Patch34: Fix cloning :via handles on thread creation (RT#131221) Fedora Patch36: Fix glob UTF-8 flag on a glob reassignment (RT#131263) Fedora Patch38: Fix handling backslashes in PATH environment variable when executing "perl -S" (RT#129183) Fedora Patch45: Fix File::Glob rt131211.t test random failures Fedora Patch46: Fix t/op/hash.t test random failures Fedora Patch47: Parse caret variables with subscripts as normal variables inside ${...} escaping (RT#131664) Fedora Patch49: Do not display too many bytes when reporting malformed UTF-8 character Fedora Patch51: Fix error message for "our sub foo::bar" (RT#131679) Fedora Patch52: Fix executing arybase::_tie_it() in Safe compartement (RT#131588) Fedora Patch54: Fix splitting non-ASCII strings if unicode_strings feature is enabled (RT#130907) Fedora Patch55: Fix compiler warnings in code generated by ExtUtils::Constant (CPAN RT#63832) Fedora Patch56: Fix compiler warnings in code generated by ExtUtils::Constant (CPAN RT#101487) Fedora Patch58: Fix unreliable Time-HiRes tests (CPAN RT#122819) Fedora Patch59: Fix an overflow in the lexer when reading a new line (RT#131793) Fedora Patch60: Fix Term::ReadLine not to create spurious &STDERR files (RT#132008) Fedora Patch63: Fix a crash when a match for inversely repeated group fails (RT#132017) Fedora Patch64: Fix an overflow when parsing a character range with no preceding character (RT#132245) Fedora Patch65: Fix walking symbol table for ISA in Carp Fedora Patch66: Fix handling file names with null bytes in stat and lstat functions (RT#131895) Fedora Patch67: Fix a crash when untying an object witout a stash Fedora Patch68: Fix deparsing of transliterations with unprintable characters (RT#132405) Fedora Patch69: Fix error reporting on do() on a directory (RT#125774) Fedora Patch70: Fix stack manipulation when a lexical subroutine is defined in a do block in a member of an iteration list (RT#132442) Fedora Patch71: Fix setting $! when statting a closed filehandle (RT#108288) Fedora Patch72: Fix tainting of s/// with overloaded replacement (RT#115266) Fedora Patch73: Expand system() arguments before a fork (RT#121105) Fedora Patch76: Avoid undefined behavior when copying memory in Glob and pp_caller (RT#131746) Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux Built under linux Compiled at Jan 10 2018 14:12:39 @INC: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(cannot change the release numbber) This problem is also present in Fedora 28 with Apache 2.4 rpm -q libapreq2-libs perl-libapreq2 libapreq2-libs-2.13-31.fc28.x86_64 perl-libapreq2-2.13-31.fc28.x86_64 ldd -r /usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so ldd -r /root/.local/share/.cpan/build/libapreq2-2.13-0/glue/perl/blib/arch/auto/APR/Request/Apache2/Apache2.so ldd -r /usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so all display undefined symbol: apreq_handle_apache2 (/usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so) undefined symbol: modperl_xs_sv2request_rec (/usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so) perl -MApache2::Request -e 1 Can't load '/usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so' for module APR::Request::Apache2: /usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 at /usr/lib64/perl5/DynaLoader.pm line 193. at /usr/local/lib64/perl5/Apache2/Request.pm line 3. Compilation failed in require at /usr/local/lib64/perl5/Apache2/Request.pm line 3. -r-xr-xr-x. 1 root root 74632 2018-02-19 12:04 /usr/local/lib64/perl5/auto/APR/Request/Apache2/Apache2.so perl5 (revision 5 version 26 subversion 2)
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
*** Bug 1281944 has been marked as a duplicate of this bug. ***
Still valid for: perl-libapreq2-2.13-35.fc30.x86_64
I guess these symbols are in places where Dynaloader.pm isn't looking: $ LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so:/usr/sbin/httpd:/usr/lib64/httpd/modules/mod_perl.so perl -MApache2::Request -e 1 $ echo $? 0 No idea whether this is something that you can use or whether all this is supposed to be somehow looked up automatically.
*** Bug 1765157 has been marked as a duplicate of this bug. ***
I believe this was solved by some of patches by Lubomir Rintel [1], however the links [2] and [3] there are dead. They contain bug ids, so you might be able to find them somehow. [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573062 [2]http://cvs.fedoraproject.org/viewvc/rpms/libapreq2/devel/libapreq2-2.12-install.patch?view=markup [3]http://cvs.fedoraproject.org/viewvc/rpms/libapreq2/devel/libapreq2.spec?view=markup
I am still not quite certain why this would even be considered a bug (see comment #9). The missing symbol is in the binary that is not a library - it's an Apache module. So, expecting Perl to find it by default sounds weird to me. Just because some other OS may have that kind of behaviour, doesn't mean Fedora/RHEL should mimic the same thing.
I believe it's a regression - it works on EPEL7: [dominik.sauer@dsa-2019-09-04-rt-01:~] uname -a Linux dsa-2019-09-04-rt-01 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux 19/10/24 16:14:43 rack-na/rat (rest-pg-minimal) [dominik.sauer@dsa-2019-09-04-rt-01:~] rpm -q libapreq2 libapreq2-2.13-12.el7.x86_64 19/10/24 16:15:29 rack-na/rat (rest-pg-minimal) [dominik.sauer@dsa-2019-09-04-rt-01:~] rpm -q perl-libapreq2 perl-libapreq2-2.13-12.el7.x86_64 19/10/24 16:15:44 rack-na/rat (rest-pg-minimal) [dominik.sauer@dsa-2019-09-04-rt-01:~] perl -MApache2::Request -e '1' 19/10/24 16:16:04 rack-na/rat (rest-pg-minimal) [dominik.sauer@dsa-2019-09-04-rt-01:~]
I don't think what you've show there is a valid regression test. You are supposed to use this module within Apache, where there is a request_rec structure, for instance. Once in Apache, with mod_perl and mod_apreq2 loaded, the symbols will be there just fine. Does this module not work when called within Apache?
(In reply to Bojan Smojver from comment #14) > I don't think what you've show there is a valid regression test. My website testsuite has regressed due to this Bug: PERL5LIB=$PWD ./html-test.pl ............................................................Can't load '/usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so' for module APR::Request::Apache2: /usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 at /usr/lib64/perl5/DynaLoader.pm line 193, <F> line 45. at /usr/lib64/perl5/vendor_perl/Apache2/Cookie.pm line 5. Compilation failed in require at /usr/lib64/perl5/vendor_perl/Apache2/Cookie.pm line 5, <F> line 45. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/Apache2/Cookie.pm line 5, <F> line 45. Compilation failed in require at /home/lace/src/www.jankratochvil.net/project/captive/DriverSurvey.pm line 27, <F> line 45. BEGIN failed--compilation aborted at /home/lace/src/www.jankratochvil.net/project/captive/DriverSurvey.pm line 27, <F> line 45. Compilation failed in require at ./html-test.pl line 45, <F> line 45. https://git.jankratochvil.net/?p=www.jankratochvil.net.git;a=blob;f=project/captive/DriverSurvey.pm;h=5e20ff36a185dda90245b3eb2c41d868c53d8ba5;hb=HEAD#l27 https://git.jankratochvil.net/?p=www.jankratochvil.net.git;a=blob;f=html-test.pl;h=4f86344884949125f183dc185f7f7b27d85d8279;hb=HEAD#l45 I do not remember exactly why the code was doing what it is doing as I wrote it some 15 years ago but it is true it works in CentOS-7 but not in Fedora 30.
And you tried what I suggested in comment #9?
(In reply to Bojan Smojver from comment #16) > And you tried what I suggested in comment #9? That crashes for me: $ gdb -ex 'set env LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so:/usr/sbin/httpd' -ex 'set startup-with-shell off' -ex r date Program received signal SIGSEGV, Segmentation fault. show_date (format=0x7fffeabd2ba5 "%a %d %b %Y %r %Z", when=..., tz=0x555555572b50) at ../src/date.c:587 587 fputc ('\n', stdout); (gdb) _ I admit I should be able to debug it but I do not see the reason off hand. Is httpd designed to be usable as a library - not affecting global state of glibc/process from its global initializers?
I am pretty sure httpd itself will not be usable without initialisation. That's kind of one of the problems here - this is an Apache module. However, I needed mod_perl in preload there as well. Did you try adding that? I don't know the gdb syntax off the top of my head, but how is running date relevant here? Weren't you running Perl?
My use case for having the Apache2::* and APR::* loadable without mod_perl loaded is to run set of unit tests. They are being mocked there, but I need the module itself to load correctly, not to crash on me.
And you preloaded all 3 binaries where the missing symbols lead and it's still crashing, correct?
- When I preload them, it works. - The root cause seems to be harderning all packages [1], causing dlopen to replace RTLD_LAZY with RTLD_NOW - that's why it worked in - I believe the Apache.so (as well as all other libs) should specify all dependencies (i.e. libs providing external symbols) as NEEDED. [1]https://fedoraproject.org/wiki/Changes/Harden_All_Packages
(In reply to Bojan Smojver from comment #20) > And you preloaded all 3 binaries where the missing symbols lead and it's > still crashing, correct? It is crashing whether the 3rd binary is there or not. It is not reproducible for you? F-30 x86_64: $ LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so:/usr/sbin/httpd:/usr/lib64/httpd/modules/mod_perl.so date Segmentation fault $ LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so:/usr/sbin/httpd date Segmentation fault
I only tried running Perl like that and that didn't crash. I thought the whole problem was with running a Perl module, so I am not sure why you are testing with date program.
(In reply to Bojan Smojver from comment #23) > I only tried running Perl like that and that didn't crash. I thought the > whole problem was with running a Perl module, so I am not sure why you are > testing with date program. Because the Perl testsuite script also runs various other child programs by shell. So when you set LD_PRELOAD for the parent Perl program its child shell programs will crash. This is why I do not see how to use LD_PRELOAD as a solution for this regression.
I can try making a build with %global _hardened_build 0 and see whether that makes what you want work. No idea how that going to go down with the rest of the distro.
I just kicked this scratch build off. When/if it finishes, please give it a try. https://koji.fedoraproject.org/koji/taskinfo?taskID=38555780
Actually, defining _hardened_build 0 does not help. The proper way is to undefine it [1]. So, please try: https://koji.fedoraproject.org/koji/taskinfo?taskID=38555826 [1] https://src.fedoraproject.org/rpms/redhat-rpm-config/c/3bf139f6467d9cad77ff309a2c1bcf79560c95e5?branch=master
To be honest, I don't think that worked either, but do give it a try anyway.
(In reply to Bojan Smojver from comment #27) > https://koji.fedoraproject.org/koji/taskinfo?taskID=38555826 I see no change.
Thanks for testing. I was expecting as much. We can try playing with hosing some of the linker options which appear to be coming from other libraries. Not sure whether that's the right thing to do. The distribution was hardened for a reason, I guess.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
libapreq2-libs-2.13-38.fc31.x86_64 perl-libapreq2-2.13-38.fc31.x86_64 Comment 15 is still valid. Comment 22 workaround behavior has changed but it is still not useful: $ LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so:/usr/sbin/httpd:/usr/lib64/httpd/modules/mod_perl.so date ERROR: ld.so: object '/usr/sbin/httpd' from LD_PRELOAD cannot be preloaded (cannot dynamically load position-independent executable): ignored. date: symbol lookup error: /usr/lib64/httpd/modules/mod_perl.so: undefined symbol: ap_server_config_defines $ LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so:/usr/sbin/httpd date ERROR: ld.so: object '/usr/sbin/httpd' from LD_PRELOAD cannot be preloaded (cannot dynamically load position-independent executable): ignored. date: symbol lookup error: /usr/lib64/httpd/modules/mod_apreq2.so: undefined symbol: ap_hook_post_config $ LD_PRELOAD=/usr/lib64/httpd/modules/mod_apreq2.so date date: symbol lookup error: /usr/lib64/httpd/modules/mod_apreq2.so: undefined symbol: ap_hook_post_config
This is still an issue in FC32 and in EPEL for RHEL/CentOS 8. It is a regression from RHEL/CentOS 7 EPEL, where it works with no problem. It is a show stopper for any app that wants to use the Perl Apache2::Request module in Fedora or RHEL/CentOS. In particular, it is preventing us from migrating WebWork (a widely deployed open-source system for managing math and science homework) to a current Linux distribution. The library version hasn't changed, although the RPM spec file has some changes. The EPEL 7 version is libapreq2-2.13-13.el7.x86_64 and the EPEL 8 one is libapreq2-2.13-38.el8.x86_64. (The Fedora 32 one is libapreq2-2.13-39.fc32.x86_64). The symbol reported as undefined in /usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so (apreq_handle_apache2) is actually defined in /lib64/httpd/modules/mod_apreq2.so, also part of this package, but apparently isn't properly linked in the FC32/EPEL 8 RPM. Perl in RHEL 7 is perl-5.16.3-295.el7.x86_64 and in RHEL 8 is perl-5.26.3-416.el8.x86_64. In FC32, it's perl-5.30.3-453.fc32.x86_64. Hope this can be resolved soon. Thanks. $ perl -MApache2::Request -e 1 Can't load '/usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so' for module APR::Request::Apache2: /usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 at /usr/lib64/perl5/DynaLoader.pm line 193. at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. Compilation failed in require at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. Compilation failed in require. BEGIN failed--compilation aborted.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
libapreq2-libs-2.13-41.fc33.x86_64 perl-libapreq2-2.13-41.fc33.x86_64
libapreq2-libs-2.16-1.fc34.x86_64 perl-libapreq2-2.16-1.fc34.x86_64
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 32 with its results is still valid: libapreq2-libs-2.16-4.fc36.x86_64 perl-libapreq2-2.16-4.fc36.x86_64
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
$ perl -MApache2::Request -e 1 Can't load '/usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so' for module APR::Request::Apache2: /usr/lib64/perl5/vendor_perl/auto/APR/Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 at /usr/lib64/perl5/DynaLoader.pm line 206. at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. Compilation failed in require at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. BEGIN failed--compilation aborted at /usr/lib64/perl5/vendor_perl/Apache2/Request.pm line 3. Compilation failed in require. BEGIN failed--compilation aborted. $ rpm -q libapreq2-libs perl-libapreq2 libapreq2-libs-2.17-2.fc38.x86_64 perl-libapreq2-2.17-2.fc38.x86_64