Compile Issues w/Perlbal-XS-HTTPHeaders
Logan Bowers
In doing some perf testing of Perlbal with an without Perlbal-XS-
HTTPHeaders, I ran into some issues using the XS module. It would
compile fine, but fail to load at startup, unable to locate symbol
__gxx_personality_v0. It appears to be caused by linking the code with
gcc instead of g++, I made a small tweak to Makefile.PL and all
appears to be well again (see http://github.com/loganb/Perlbal-XS-HTTPHeaders/commit/fda30c826cd9f512e22895d5c34272900bb9e236)
. It looks like the module hasn't been updated in forever and the CVS
tree is long gone. Can someone with more CPAN experience than I (and/
or access) comment on how to push a bug fix? Thanks!
Logan Bowers
Mark Smith
over to a generic module HTTP::HeaderParser::XS, but I never updated
Perlbal itself to use the new module...
Anyway, I think this is a platform dependent issue. What were you
trying to compile it on?
-Mark
On Mon, Jul 6, 2009 at 4:26 PM, Logan Bowers<lo...@datacurrent.com> wrote:
>
> Hello all,
>
> In doing some perf testing of Perlbal with an without
> Perlbal-XS-HTTPHeaders, I ran into some issues using the XS module. It
> would compile fine, but fail to load at startup, unable to locate symbol
> __gxx_personality_v0. It appears to be caused by linking the code with gcc
> instead of g++, I made a small tweak to Makefile.PL and all appears to be
> well again (see
> http://github.com/loganb/Perlbal-XS-HTTPHeaders/commit/fda30c826cd9f512e22895d5c34272900bb9e236).
> It looks like the module hasn't been updated in forever and the CVS tree is
> long gone. Can someone with more CPAN experience than I (and/or access)
> comment on how to push a bug fix? Thanks!
>
> Logan Bowers
>
--
Mark Smith / xb95
ma...@dreamwidth.org
Martin Atkins
>
> Hello all,
>
> In doing some perf testing of Perlbal with an without
> __gxx_personality_v0. It appears to be caused by linking the code with
> gcc instead of g++, I made a small tweak to Makefile.PL and all appears
> to be well again (see
> http://github.com/loganb/Perlbal-XS-HTTPHeaders/commit/fda30c826cd9f512e22895d5c34272900bb9e236).
> It looks like the module hasn't been updated in forever and the CVS tree
> is long gone. Can someone with more CPAN experience than I (and/or
> access) comment on how to push a bug fix? Thanks!
>
I'm unable to recreate your issue on my system here, though applying
your patch didn't actually stop it working.
Do you know why your system might be failing here while mine isn't? I
don't mind applying your patch if it'll improve portability, but I'd
like to know what we're incompatible with right now rather than just
blindly making this change without understanding what's being fixed.
Logan Bowers
Apple build 5566, Intel).
Logan Bowers
Logan Bowers
Check the build logs and see what your system uses to link the
library. On my OS X machine I see: "env MACOSX_DEPLOYMENT_TARGET=10.3
cc -bundle -undefined dynamic_lookup headers.o HTTPHeaders.o -o blib/
arch/auto/Perlbal/XS/HTTPHeaders/HTTPHeaders.bundle" without my patch
applied. With it, I see "g++ -bundle -undefined dynamic_lookup
headers.o HTTPHeaders.o -o blib/arch/auto/Perlbal/XS/HTTPHeaders/
HTTPHeaders.bundle". I also get the following message when running
`perl Makefile.PL`:
Note (probably harmless): No library found for -lstdc++
Writing Makefile for Perlbal::XS::HTTPHeaders
Getting increasingly speculative, I believe everything will link
properly if you have a stdc++ compat library available to gcc, but
gentoo doesn't provide one by default. I'm guessing if your system
shows the warning when generating the Makefile, it will fail at
runtime. It seems that on some systems, `g++` will link properly but
`gcc -lstdc++` will not.
Logan Bowers
Martin Atkins
>
> Martin,
>
> Check the build logs and see what your system uses to link the library.
> On my OS X machine I see: "env MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle
> -undefined dynamic_lookup headers.o HTTPHeaders.o -o
> headers.o HTTPHeaders.o -o
>
> Note (probably harmless): No library found for -lstdc++
> Writing Makefile for Perlbal::XS::HTTPHeaders
>
> Getting increasingly speculative, I believe everything will link
> properly if you have a stdc++ compat library available to gcc, but
> gentoo doesn't provide one by default. I'm guessing if your system
> shows the warning when generating the Makefile, it will fail at
> runtime. It seems that on some systems, `g++` will link properly but
> `gcc -lstdc++` will not.
>
Okay. I'm on Ubuntu 8.10 here. The link was done as follows before your
patch:
cc -shared -L/usr/local/lib headers.o HTTPHeaders.o \
-o blib/arch/auto/Perlbal/XS/HTTPHeaders/HTTPHeaders.so \
-lstdc++
After applying your patch, it did:
g++ -shared -L/usr/local/lib headers.o HTTPHeaders.o \
-o blib/arch/auto/Perlbal/XS/HTTPHeaders/HTTPHeaders.so \
-lstdc++
I'm far from a GCC expert, but I assume that stdc++ is always available
to g++. Is that right? In which case, applying this patch ought to
improve portability without breaking anyone. I'd guess that it's pretty
unlikely that someone would have stdc++ available to gcc and not to g++,
and we're already requiring g++ in the CC argument.
(I idly wonder what effect having g++ hard-coded into CC and LD has when
building this module on a Windows system with Microsoft's compiler. In
that case cl.exe is used in place of gcc or g++, and I believe normally
(in the absence of an explicit override) MakeMaker will generate a
makefile suitable for Microsoft's toolchain. However, I guess Perlbal
probably doesn't work on Windows anyway, so maybe it's a moot point.)
Logan Bowers
"Undefined references to internal run-time library functions, such as
__gxx_personality_v0, are also a symptom of linking C++ object files
with gcc instead of g++. Linking the same object file with g++
supplies all the necessary C++ libraries and will produce a working
executable" (http://www.network-theory.co.uk/docs/gccintro/gccintro_54.html
).
Logan Bowers