Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat
William A. Rowe, Jr. wrote: Bianca Taylor wrote: /bin/ld: /tmp/unisolve/perl/lib/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoader.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /tmp/unisolve/perl/lib/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [mod_perl.so] Error 1 make[1]: Leaving directory `/home/unisolve/mod_perl-2.0.4/src/modules/perl' make: *** [modperl_lib] Error 2 Perl itself makes several bad calls w.r.t. CFLAGS, LDFLAGS, SHLDFLAGS etc, that are propagated also into config_heavy.pl. On several platforms I've noted that -fPIC is ignored, on others I've noted that specific flag values are dropped for the building of shared libs. It's a matter of working backwards from modperl's build into the config script of perl to determine where perl went wrong. The solution should be as easy as recompiling perl with -fPIC. Here's a link to the list archives where this has been discussed in detail. http://www.gossamer-threads.com/lists/engine?list=modperl;do=search_results;search_forum=forum_8;search_string=fpic;search_type=ANDsb=post_time
Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat
Fred Moyer wrote: William A. Rowe, Jr. wrote: Bianca Taylor wrote: /bin/ld: /tmp/unisolve/perl/lib/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoader.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /tmp/unisolve/perl/lib/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [mod_perl.so] Error 1 make[1]: Leaving directory `/home/unisolve/mod_perl-2.0.4/src/modules/perl' make: *** [modperl_lib] Error 2 Perl itself makes several bad calls w.r.t. CFLAGS, LDFLAGS, SHLDFLAGS etc, that are propagated also into config_heavy.pl. On several platforms I've noted that -fPIC is ignored, on others I've noted that specific flag values are dropped for the building of shared libs. It's a matter of working backwards from modperl's build into the config script of perl to determine where perl went wrong. The solution should be as easy as recompiling perl with -fPIC. Here's a link to the list archives where this has been discussed in detail. http://www.gossamer-threads.com/lists/engine?list=modperl;do=search_results;search_forum=forum_8;search_string=fpic;search_type=ANDsb=post_time Of course, that's what it says above. My point is, I've had perl yank -fPIC from my demands on the build on PPC arch. Mighty kind of it, eh?
Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat
Hello again, ... The solution should be as easy as recompiling perl with -fPIC. Here's a link to the list archives where this has been discussed in detail. http://www.gossamer-threads.com/lists/engine?list=modperl;do=search_results ;search_forum=forum_8;search_string=fpic;search_type=ANDsb=post_time Of course, that's what it says above. My point is, I've had perl yank -fPIC from my demands on the build on PPC arch. Mighty kind of it, eh? We attempted to compile perl with: ccflags='-fPIC' sh Configure -de (yes, make clean first) but unfortunately to no avail. Like you said, Perl didn't seem to care -fPIC is not used when Perl is built. Next, we changed config.sh from -fpic to -fPIC and did the make again. In this case Perl did use -fPIC but we get the same error, mod_perl is not happy with the DynaLoader. Also tried to clean everything out with 'make cleandist' first and run ./Configure with -Doptimize='-g' to really make sure the -fPIC is passed in. I definitely see the -fPIC option, for example: ...cc -c -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -g -DVERSION=\0.94\ -DXS_VERSION=\0.94\ -fPIC -I../../.. shared.c... Everything seems happy until the make step in mod_perl, where I still get: ..lib/perl5/5.8.8/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc \ -o mod_perl.so /bin/ld: /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoa der.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a: could not read symbols: Bad value collect2: ld returned 1 exit status... So at this point, I am confident that I compile Perl with -fPIC. I read all the ducumentation you pointed me to and that I could find, but it keeps coming back to the same error. Thanks again Bianca -- Unisolve Pty Ltd - Melbourne Australia
Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat
Bianca Taylor wrote: So at this point, I am confident that I compile Perl with -fPIC. I read all the ducumentation you pointed me to and that I could find, but it keeps coming back to the same error. You aren't... please review your shared cc flags from perl. The flag you looked at was not a shlib cflag, but a program cflag.
Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat
Bianca Taylor wrote: So at this point, I am confident that I compile Perl with -fPIC. I read all the ducumentation you pointed me to and that I could find, but it keeps coming back to the same error. On Wednesday 17 September 2008 12:08, William A. Rowe, Jr. wrote: You aren't... please review your shared cc flags from perl. The flag you looked at was not a shlib cflag, but a program cflag. Here the whole snip for attrs.c whilst 'make' cc -c -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -g -DVERSION=\1.02\ -DXS_VERSION=\1.02\ -fPIC -I../.. attrs.c Running Mkbootstrap for attrs () chmod 644 attrs.bs rm -f ../../lib/auto/attrs/attrs.so cc -shared -L/usr/local/lib attrs.o -o ../../lib/auto/attrs/attrs.so \ \ chmod 755 ../../lib/auto/attrs/attrs.so cp attrs.bs ../../lib/auto/attrs/attrs.bs chmod 644 ../../lib/auto/attrs/attrs.bs make[1]: Leaving directory `/home/unisolve/perl-5.8.8/ext/attrs' ok, so how do I do it? where do I go wrong? Thanks again
Why load two modules to call methods on the same object?
For the following to work I must load Apache2RequestRec as well as
Apache2::RequestIO.
package GS;
use Apache2::Const -compile = ':common';
use Apache2::RequestRec ();# $r-content_type
use Apache2::RequestIO (); # $r-print
sub handler {
my $r = shift;
print $r-content_type('text/plain');
print $r-print(hello, world);
return Apache2::Const::OK;
}
1;
There must be a reason we have it this way. Any clues?
Thanks,
Himanshu
Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat
On Wednesday 17 September 2008 12:08, you wrote: Bianca Taylor wrote: So at this point, I am confident that I compile Perl with -fPIC. I read all the ducumentation you pointed me to and that I could find, but it keeps coming back to the same error. You aren't... please review your shared cc flags from perl. The flag you looked at was not a shlib cflag, but a program cflag. Ok I see now what you mean. I added -fPIC to the definitions of ccflags and cppflags in config.sh and now I can successfully build mod_perl. Since the makefile is being build incorrectly by the Perl installation process, who can I report this bug to? Kind regards Bianca -- Unisolve Pty Ltd - Melbourne Australia
Re: Why load two modules to call methods on the same object?
--- On Tue, 9/16/08, Himanshu [EMAIL PROTECTED] wrote:
From: Himanshu [EMAIL PROTECTED]
Subject: Why load two modules to call methods on the same object?
To: modperl@perl.apache.org
Date: Tuesday, September 16, 2008, 9:00 PM
For the following to work I must load Apache2RequestRec as
well as
Apache2::RequestIO.
package GS;
use Apache2::Const -compile = ':common';
use Apache2::RequestRec ();# $r-content_type
use Apache2::RequestIO (); # $r-print
sub handler {
my $r = shift;
print $r-content_type('text/plain');
print $r-print(hello, world);
return Apache2::Const::OK;
}
1;
There must be a reason we have it this way. Any clues?
Thanks,
Himanshu
rant
I've been coding with mod_perl since 2000 (IIRC) and I don't have a
straightforward answer for you.
I suppose it's possible that rather than load up all the non-core behaviors
(like, you know, really strange ones that nobody ever uses, like print) you
have to load those modules yourself.
Just keep repeating to yourself, This is to make mod_perl faster.
/rant
One advantage you get by having to load up those modules yourself is that you
can (in theory) shave off an extra millisecond or two. Somehow magickally.
I wish mod_perl handlers were a bit more intuitive myself. The whole thing
just seems very un-Perlish. Probably because it's just a very thin layer
around the Apache API.
Go figure.
