Bug#573062: Apache2::Request fails to load (/usr/lib/perl5/auto/APR/Request/Request.so: undefined symbol: apreq_hook_disable_uploads)
Damyan Ivanov
Version: 2.12-1
Severity: normal
Trying to load Apache2::Request outside of apache fails:
$ perl -MApache2::Request -e1
Can't load '/usr/lib/perl5/auto/APR/Request/Request.so' for module
APR::Request: /usr/lib/perl5/auto/APR/Request/Request.so: undefined symbol:
apreq_hook_disable_uploads at /usr/lib/perl/5.10/DynaLoader.pm line 193.
at /usr/lib/perl5/APR/Request/Param.pm line 27
Compilation failed in require at /usr/lib/perl5/APR/Request/Param.pm line 27.
BEGIN failed--compilation aborted at /usr/lib/perl5/APR/Request/Param.pm line 27.
Compilation failed in require at /usr/lib/perl5/Apache2/Request.pm line 2.
BEGIN failed--compilation aborted at /usr/lib/perl5/Apache2/Request.pm line 2.
Compilation failed in require.
BEGIN failed--compilation aborted.
Previous versions worked fine.
I use out-of-apache-loading for testing if my application modules compile.
Thanks for considering.
-- System Information:
Debian Release: squeeze/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.33-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libapache2-request-perl depends on:
ii libapache2-mod-apreq2 2.12-1 generic Apache request library - A
ii libapache2-mod-perl2 2.0.4-6 Integration of perl with the Apach
ii libapreq2 2.12-1 generic Apache request library
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii perl 5.10.1-11 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.10.1] 5.10.1-11 minimal Perl system
libapache2-request-perl recommends no packages.
libapache2-request-perl suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steinar H. Gunderson
> Trying to load Apache2::Request outside of apache fails:
Hm. I'm actually unsure if this is supported or not -- I'll take a look and
see if it's something in my packaging, or something upstream changed.
/* Steinar */
--
Homepage: http://www.sesse.net/
Damyan Ivanov
> On Mon, Mar 08, 2010 at 06:01:24PM +0200, Damyan Ivanov wrote:
> > Trying to load Apache2::Request outside of apache fails:
>
> Hm. I'm actually unsure if this is supported or not -- I'll take a look and
> see if it's something in my packaging, or something upstream
> changed.
It is probably upstream. My strongest argument for supporting this is
that it used to work before.
Damyan Ivanov
thanks
-=| Steinar H. Gunderson, Mon, Mar 08, 2010 at 05:09:45PM +0100 |=-
> On Mon, Mar 08, 2010 at 06:01:24PM +0200, Damyan Ivanov wrote:
> > Trying to load Apache2::Request outside of apache fails:
>
> Hm. I'm actually unsure if this is supported or not -- I'll take a look and
> see if it's something in my packaging, or something upstream
> changed.
According to the comment from Lubomir Rintel[1], this is a side effect
of an upstream change about rpath handling.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573062#28
The commit is here: http://svn.apache.org/viewvc?view=revision&revision=733406
I am raising the severity as it is clear that a library is not
specified during linking. I tried Lubomir's patch, but it didn't work
out. Perhaps the additional .pc file is needed (I wasn't sure where to
put it).
I'll also try to just revert the change and see what happens.
Steinar H. Gunderson
> I am raising the severity as it is clear that a library is not
> specified during linking.
I'm not entirely sure if the severity is warranted, though -- the main part
of the library works quite fine.
> I tried Lubomir's patch, but it didn't work out. Perhaps the additional .pc
> file is needed (I wasn't sure where to put it).
>
> I'll also try to just revert the change and see what happens.
I'm afraid this is mostly just black magic to me, so I can't do much except
cheer on whoever wants to find a workable solution for this. :-)
Sebastian Podjasek
Below you can find patch against whole debian/ directory to fix this
problem.
--
Sebastian Podjasek @ morenet.pl
Damyan Ivanov
> I've applied modified patch from Lubomir and now it works....
>
> Below you can find patch against whole debian/ directory to fix this
> problem.
Not here :(
I still get the same error message with I run
perl -MApache2::Request -e1
And ldd /usr/lib/perl5/auto/APR/Request/Request.so doesn't show a link
with libapreq2.
BTW, your patch has some tabs replaces with spaces in glue/Makefile.am
which causes the patch not to apply.
Sebastian Podjasek
> -=| Sebastian Podjasek, Fri, Apr 30, 2010 at 03:11:41PM +0200 |=-
> I still get the same error message with I run
It worked for me and it's still working...
> perl -MApache2::Request -e1
$ perl -MAPR::Request -e1
$ perl -MApache2::Request -e1
no errors reported
>
> And ldd /usr/lib/perl5/auto/APR/Request/Request.so doesn't show a link
> with libapreq2.
$ ldd /usr/lib/perl5/auto/APR/Request/Request.so
linux-vdso.so.1 => (0x00007fff469ff000)
libapreq2.so.3 => /usr/lib/libapreq2.so.3 (0x00007fc3df0d4000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007fc3deeb1000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007fc3dec78000)
libdb-4.8.so => /usr/lib/libdb-4.8.so (0x00007fc3de8fe000)
libc.so.6 => /lib/libc.so.6 (0x00007fc3de5aa000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007fc3de3a5000)
librt.so.1 => /lib/librt.so.1 (0x00007fc3de19d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007fc3ddf66000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc3ddd49000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fc3ddb45000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fc3dd91d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc3df4fc000)
> BTW, your patch has some tabs replaces with spaces in glue/Makefile.am
> which causes the patch not to apply.
Possibly I had 'replace tabs with spaces' switched on somewhere, sorry
for that.
Below you can find more details on my testing machine, I hope something
is going to help you:
*** mod_perl version 2.000004
*** using /usr/lib/perl5/Apache2/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB => aprext
MP_APXS => /usr/bin/apxs2
MP_CCOPTS => -g -Wall
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_INCLUDE_DIR => /usr/include/apache2 /usr/include/apr-1.0
MP_LIBNAME => mod_perl
MP_TRACE => 0
MP_USE_DSO => 1
MP_USE_GTOP => 1
MP_USE_STATIC => 0
*** The httpd binary was not found
*** (apr|apu)-config linking info
-L/usr/lib -laprutil-1 -ldb
-L/usr/lib -lapr-1
*** /usr/bin/perl -V
Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
Platform:
osname=linux, osvers=2.6.32-3-amd64, archname=x86_64-linux-gnu-thread-multi
uname='linux madeleine 2.6.32-3-amd64 #1 smp wed feb 24 18:07:42 utc 2010 x86_64 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.1 -Dsitearch=/usr/local/lib/perl/5.10.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.1 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.4.3', 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='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.10.2.so, so=so, useshrplib=true, libperl=libperl.so.5.10.1
gnulibc_version='2.10.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_REENTRANT_API
Locally applied patches:
DEBPKG:debian/arm_thread_stress_timeout - http://bugs.debian.org/501970 Raise the timeout of ext/threads/shared/t/stress.t to accommodate slower build hosts
DEBPKG:debian/cpan_config_path - Set location of CPAN::Config to /etc/perl as /usr may not be writable.
DEBPKG:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS default for modules installed from CPAN.
DEBPKG:debian/db_file_ver - http://bugs.debian.org/340047 Remove overly restrictive DB_File version check.
DEBPKG:debian/doc_info - Replace generic man(1) instructions with Debian-specific information.
DEBPKG:debian/enc2xs_inc - http://bugs.debian.org/290336 Tweak enc2xs to follow symlinks and ignore missing @INC directories.
DEBPKG:debian/errno_ver - http://bugs.debian.org/343351 Remove Errno version check due to upgrade problems with long-running processes.
DEBPKG:debian/extutils_hacks - Various debian-specific ExtUtils changes
DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to the binary targets.
DEBPKG:debian/instmodsh_doc - Debian policy doesn't install .packlist files for core or vendor.
DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as per Debian policy.
DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable.
DEBPKG:debian/m68k_thread_stress - http://bugs.debian.org/495826 Disable some threads tests on m68k for now due to missing TLS.
DEBPKG:debian/mod_paths - Tweak @INC ordering for Debian
DEBPKG:debian/module_build_man_extensions - http://bugs.debian.org/479460 Adjust Module::Build manual page extensions for the Debian Perl policy
DEBPKG:debian/perl_synopsis - http://bugs.debian.org/278323 Rearrange perl.pod
DEBPKG:debian/prune_libs - http://bugs.debian.org/128355 Prune the list of libraries wanted to what we actually need.
DEBPKG:debian/use_gdbm - Explicitly link against -lgdbm_compat in ODBM_File/NDBM_File.
DEBPKG:fixes/assorted_docs - http://bugs.debian.org/443733 [384f06a] Math::BigInt::CalcEmu documentation grammar fix
DEBPKG:fixes/net_smtp_docs - http://bugs.debian.org/100195 [rt.cpan.org #36038] Document the Net::SMTP 'Port' option
DEBPKG:fixes/processPL - http://bugs.debian.org/357264 [rt.cpan.org #17224] Always use PERLRUNINST when building perl modules.
DEBPKG:debian/perlivp - http://bugs.debian.org/510895 Make perlivp skip include directories in /usr/local
DEBPKG:fixes/pod2man-index-backslash - http://bugs.debian.org/521256 Escape backslashes in .IX entries
DEBPKG:debian/disable-zlib-bundling - Disable zlib bundling in Compress::Raw::Zlib
DEBPKG:fixes/kfreebsd_cppsymbols - http://bugs.debian.org/533098 [3b910a0] Add gcc predefined macros to $Config{cppsymbols} on GNU/kFreeBSD.
DEBPKG:debian/cpanplus_definstalldirs - http://bugs.debian.org/533707 Configure CPANPLUS to use the site directories by default.
DEBPKG:debian/cpanplus_config_path - Save local versions of CPANPLUS::Config::System into /etc/perl.
DEBPKG:fixes/kfreebsd-filecopy-pipes - http://bugs.debian.org/537555 [16f708c] Fix File::Copy::copy with pipes on GNU/kFreeBSD
DEBPKG:fixes/anon-tmpfile-dir - http://bugs.debian.org/528544 [perl #66452] Honor TMPDIR when open()ing an anonymous temporary file
DEBPKG:fixes/abstract-sockets - http://bugs.debian.org/329291 [89904c0] Add support for Abstract namespace sockets.
DEBPKG:fixes/hurd_cppsymbols - http://bugs.debian.org/544307 [eeb92b7] Add gcc predefined macros to $Config{cppsymbols} on GNU/Hurd.
DEBPKG:fixes/autodie-flock - http://bugs.debian.org/543731 Allow for flock returning EAGAIN instead of EWOULDBLOCK on linux/parisc
DEBPKG:fixes/archive-tar-instance-error - http://bugs.debian.org/539355 [rt.cpan.org #48879] Separate Archive::Tar instance error strings from each other
DEBPKG:fixes/positive-gpos - http://bugs.debian.org/545234 [perl #69056] [c584a96] Fix \G crash on first match
DEBPKG:debian/devel-ppport-ia64-optim - http://bugs.debian.org/548943 Work around an ICE on ia64
DEBPKG:fixes/trie-logic-match - http://bugs.debian.org/552291 [perl #69973] [0abd0d7] Fix a DoS in Unicode processing [CVE-2009-3626]
DEBPKG:fixes/hppa-thread-eagain - http://bugs.debian.org/554218 make the threads-shared test suite more robust, fixing failures on hppa
DEBPKG:fixes/crash-on-undefined-destroy - http://bugs.debian.org/564074 [perl #71952] [1f15e67] Fix a NULL pointer dereference when looking for a DESTROY method
DEBPKG:fixes/tainted-errno - http://bugs.debian.org/574129 [perl #61976] [be1cf43] fix an errno stringification bug in taint mode
DEBPKG:patchlevel - http://bugs.debian.org/567489 List packaged patches for 5.10.1-12 in patchlevel.h
Built under linux
Compiled at Apr 11 2010 20:11:00
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/etc/perl
/usr/local/lib/perl/5.10.1
/usr/local/share/perl/5.10.1
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.10
/usr/share/perl/5.10
/usr/local/lib/site_perl
.
*** Packages of interest status:
Apache2 : -
Apache2::Request : 2.12
CGI : 3.43
ExtUtils::MakeMaker: 6.55_02
LWP : 5.834
mod_perl : -
mod_perl2 : 2.000004
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libapache2-mod-perl2 depends on:
ii apache2 2.2.15-5 Apache HTTP Server metapackage
ii apache2-mpm-prefork [apache 2.2.15-5 Apache HTTP Server - traditional n
ii apache2.2-common 2.2.15-5 Apache HTTP Server common files
ii libapr1 1.4.2-3 The Apache Portable Runtime Librar
ii libaprutil1 1.3.9+dfsg-3 The Apache Portable Runtime Utilit
ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib
ii libdb4.8 4.8.26-3 Berkeley v4.8 Database Libraries [
ii libdevel-symdump-perl 2.08-3 Perl module for inspecting perl's
ii libperl5.10 5.10.1-12 shared Perl library
ii liburi-perl 1.54-1 module to manipulate and access UR
ii libwww-perl 5.834-1 Perl HTTP/WWW client/server librar
ii netbase 4.41 Basic TCP/IP networking system
ii perl [libmime-base64-perl] 5.10.1-12 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.10.1] 5.10.1-12 minimal Perl system
Versions of packages libapache2-mod-perl2 recommends:
ii libapache2-reload-perl 0.10-2 Reload Perl modules when changed o
ii libbsd-resource-perl 1.2904-1 BSD process resource limit and pri
libapache2-mod-perl2 suggests no packages.
Versions of packages libapreq2 depends on:
ii libapr1 1.4.2-3 The Apache Portable Runtime Librar
ii libaprutil1 1.3.9+dfsg-3 The Apache Portable Runtime Utilit
ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib
ii libdb4.8 4.8.26-3 Berkeley v4.8 Database Libraries [
Versions of packages libapreq2 recommends:
ii libapache2-mod-apreq2 2.12-2~mn generic Apache request library - A
Versions of packages libapache2-request-perl depends on:
ii libapache2-mod-apreq2 2.12-2~mn generic Apache request library - A
ii libapache2-mod-perl2 2.0.4-7 Integration of perl with the Apach
ii libapr1 1.4.2-3 The Apache Portable Runtime Librar
ii libapreq2 2.12-2~mn generic Apache request library
ii libaprutil1 1.3.9+dfsg-3 The Apache Portable Runtime Utilit
ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib
ii libdb4.8 4.8.26-3 Berkeley v4.8 Database Libraries [
ii perl 5.10.1-12 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.10.1] 5.10.1-12 minimal Perl system
libapache2-request-perl recommends no packages.
libapache2-request-perl suggests no packages.
--
Damyan Ivanov
> On 2010-05-01 10:30, Damyan Ivanov wrote:
>> Strange. Can you share the complete build log?
>
> Strange indeed. It seems that including modules works now, but trying to
> do anyting with them ends up in undefined symbols:
>
>
> perl -MApache2::Request -e 'my $apr = Apache2::Request->new();'
> perl: symbol lookup error:
> /usr/lib/perl5/auto/APR/Request/Apache2/Apache2.so: undefined symbol:
> modperl_xs_sv2request_rec
This is also trye in Lenny and I think it is normal as creating the
object requiress some assistance by a running apache process.
> /usr/sbin/apache2: symbol lookup error:
> /usr/lib/perl5/auto/APR/Request/Apache2/Apache2.so: undefined
> symbol: apreq_handle_apache2
Not sure about this. Is this within mod_perl?
Sorry for not having found the time to compare the build logs yet.
Sebastian Podjasek
> Strange indeed. It seems that including modules works now, but trying to
> do anyting with them ends up in undefined symbols:
>
> /usr/lib/perl5/auto/APR/Request/Apache2/Apache2.so: undefined symbol:
> apreq_handle_apache2
After enabling apreq2_mod (some bad ghost had to disable it ;)
LoadModule apreq_module /usr/lib/apache2/modules/mod_apreq2.so
no more undefined symbols on running apache and at least POST parsing
with Apache2::Request->param() works.
Steinar H. Gunderson
thanks
On Sat, May 01, 2010 at 09:42:56AM +0300, Damyan Ivanov wrote:
> I still get the same error message with I run
>
> perl -MApache2::Request -e1
>
> And ldd /usr/lib/perl5/auto/APR/Request/Request.so doesn't show a link
> with libapreq2.
I see the same problem. I guess this is related to the fact that the patch
doesn't update Makefile.in, only Makefile.am (and doesn't regenerate).
In any case, I don't consider this RC. Downgrading.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
Damyan Ivanov
> On Sat, May 01, 2010 at 09:42:56AM +0300, Damyan Ivanov wrote:
> > I still get the same error message with I run
> >
> > perl -MApache2::Request -e1
> >
> > And ldd /usr/lib/perl5/auto/APR/Request/Request.so doesn't show a link
> > with libapreq2.
>
> I see the same problem. I guess this is related to the fact that the patch
> doesn't update Makefile.in, only Makefile.am (and doesn't
> regenerate).
Tried that, but it didn't help.
What did help is building the package with libapreq2-dev installed. Of
course, I usualy build in clean chroots (similarly to buildds),
perhaps this is why I still suffer from the original problem even with
the patch.
Sebastian, can you try a package built in a clean chroot using
pbuilder/cowbuilder/sbuild?
Sebastian Podjasek
> What did help is building the package with libapreq2-dev installed. Of
> course, I usualy build in clean chroots (similarly to buildds),
> perhaps this is why I still suffer from the original problem even with
> the patch.
BTW. It's strange, libapreq2-dev is built from the same source
package...
> Sebastian, can you try a package built in a clean chroot using
> pbuilder/cowbuilder/sbuild?
I've used sbuild. After successfully building and installing error
appears - even made second patch against Makefile.in, no change.
(Build logs are here: http://sandbox.morenet.pl/debian/bug-573062/logs/)
Damyan Ivanov
> Dnia 2010-05-18, wto o godzinie 17:09 +0300, Damyan Ivanov pisze:
> > What did help is building the package with libapreq2-dev installed. Of
> > course, I usualy build in clean chroots (similarly to buildds),
> > perhaps this is why I still suffer from the original problem even with
> > the patch.
>
> BTW. It's strange, libapreq2-dev is built from the same source
> package...
It appears the build needs some file in /usr/lib in order to make the
linkage right.
> > Sebastian, can you try a package built in a clean chroot using
> > pbuilder/cowbuilder/sbuild?
>
> I've used sbuild. After successfully building and installing error
> appears - even made second patch against Makefile.in, no change.
> (Build logs are here: http://sandbox.morenet.pl/debian/bug-573062/logs/)
Thanks for testing. Same experience here. We are back to square one :|
(but at least we are on the same square again :) )
It seems to me that it is all a matter of setting an
environment/configuration variable to the right value during build.
I'll delve more in the following days.
Damyan Ivanov
thanks
-=| Damyan Ivanov, Wed, May 19, 2010 at 07:53:33AM +0300 |=-
> It seems to me that it is all a matter of setting an
> environment/configuration variable to the right value during build.
> I'll delve more in the following days.
I finally have a working patch. Standalone patch and debdiff attached.
Steinar, I really think this issue is RC. Loading a Perl module
outside a running apache is quite normal operation. I won't play
ping-pong with the bug severity, but would very much apprecate if you
release a package with this patch applied.
Thanks to all who helped!
Steinar H. Gunderson
> I finally have a working patch. Standalone patch and debdiff attached.
How is this supposed to work? You remove the Makefile.PL calls, and that's
it? Can you explain why this helps?
> Steinar, I really think this issue is RC. Loading a Perl module
> outside a running apache is quite normal operation. I won't play
> ping-pong with the bug severity, but would very much apprecate if you
> release a package with this patch applied.
The definition of “important” severity level, according to reportbug:
“A bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.” This fits quite nicely
into my assessment of this bug.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
Damyan Ivanov
> On Thu, May 20, 2010 at 10:10:04AM +0300, Damyan Ivanov wrote:
> > I finally have a working patch. Standalone patch and debdiff attached.
>
> How is this supposed to work? You remove the Makefile.PL calls, and that's
> it? Can you explain why this helps?
Note the place of the calls. They are in the 'perl_install' target,
invoked by 'make install'. Building here seems unnecessary in the
first place, since the main 'make' call has built (and linked)
everything already. AIUI, it was added to fix a problem on windows,
but seems to break linking on Debian.
Upstream log about the change:
http://svn.apache.org/viewvc?view=revision&revision=733406
The perl modules were linked against
the build location of libapreq2.so.
That's obviously broken, so we now
rebuild them during make install to
link against the installed location.
Maybe it makes sense when using rpaths or installing directly (without
destdir=), neigher of which is true for the Debian package building.
> > Steinar, I really think this issue is RC. Loading a Perl module
> > outside a running apache is quite normal operation. I won't play
> > ping-pong with the bug severity, but would very much apprecate if
> > you release a package with this patch applied.
>
> The definition of “important” severity level, according to reportbug:
> “A bug which has a major effect on the usability of a package,
> without rendering it completely unusable to everyone.” This fits quite nicely
> into my assessment of this bug.
Hm, this motivated me to find some 'normative' backing of my claim.
And I've found one :)
Squeeze RC policy:[1]
-----------------
The purpose of this document is to be a correct, complete and
canonical list of issues that merit a "serious" bug under the clause
"a severe violation of Debian policy".
...
5. General
...
(f) Libraries
...
Shared libraries must normally be linked with all libraries
they use symbols from.
[1] http://release.debian.org/squeeze/rc_policy.txt
I think that 'perl -MApache2::Request' can be classified as 'normal'
in the above sense.