OtherModule.so -- Dependency
[4] SONAME ThisModule.so -- Name of this module
[5] RUNPATH $ORIGIN/.. -- Where to search
[6] RPATH $ORIGIN/..
Hope this might help somebody sometime - it may be possible to pull a
similar stunt on other platforms.
Alan Burlison
can't spot
what is wrong. Can someone spare me a clue?
Thanks,
--
Alan Burlison
--
$ head -1 /dev/bollocks
risk manage three-tier high-volume price performance
of having DSO at all then?
The question was 'How do I build on Solaris with DSO?', the answer was
'Build perl to use the system malloc', I don't see what the problem with
that is.
--
Alan Burlison
--
$ head -1 /dev/bollocks
repurpose collaborative focus groups, going forwards
to compile mod_perl
statically on Solaris because it will core otherwise.
Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine.
Alan Burlison
Vasily S. Petrushin wrote:
Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine.
Fine, point us please to documentation how to do it.
http://cpan.valueclick.com/authors/Doug_MacEachern/mod_perl-1.26.tar.gz
Alan Burlison
to Configure), then apache, mod_perl and
perl all agree on who manages memory.
Humbly,
And no need for that either! :-)
Regards,
--
Alan Burlison
--
$ head -1 /dev/bollocks
drive proximal infomediaries, going forwards
Ged Haywood wrote:
Well OK, read What Compiler Should Be Used to Build mod_perl? in the
install section of Stas' new book if you want to use different compilers
- but don't say I didn't warn you! :)
By all means, please feel free to buy our compiler.
Alan Burlison
as a DSO.
--
Alan Burlison
Solaris Kernel Development, Sun Microsystems
Stas Bekman wrote:
Here is the output of 'make install'
I don't think it logs the install of these headers. Please check the
created Makefile. Does it include the mod_perl.h in one of the targets?
No.
Alan Burlison
/Apache, but it isn't
there.
Alan Burlison
/perllocal.pod
No header files installed.
Alan Burlison
. Everything else is
the latest available from CPAN. The INSTALL file is less than helpful, and
a search of the modperl archives didn't find anything.
Anyone have any suggestions?
thanks,
Alan Burlison
it breaks. If you want to use APXS
you have to build Apache to be largefile aware yourself. On Solaris at
least the way to do this is to set CFLAGS='-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64' in your environment before invoking the Apache
configure.
--
Alan Burlison
od_perl's Makefile.PL to check that the
largefile-ness of both perl and apache agree when using APXS. On
Solaris you can do this by using nm and looking to see if the normal or
largefile versions of routines are in use, e.g. fstat or fsta64. I
don't know how portable to other platforms this is though.
--
Alan Burlison
e. Apache built with no errors, and as far as I can tell up
until now it works just fine, including mod_perl. Obviously you are on
a different platform, but perhaps building Apache with the Linux
incantation needed to make it largefile aware will solve the problem for
you?
Alan Burlison
] main(0x8f800, 0x8f800, 0x2, 0x88400, 0x0, 0x0), at 0x3e348
Alan Burlison
-per_dir_config and perl_module.
r-per_dir_config is a void*, and has the value 8, which sure doesn't
look like a valid address to me. perl_module on the other hand all
looks sane. I'm not sure where to look next - any suggestions?
--
Alan Burlison
s
probably to put an END handler in DynaLoader to unload the XS modules,
but I'm not familiar enough with the perl interpreter cleanup processing
to know if this is the best way.
It might add some weight if you could add your comments to the bug
preport in P5P - after all, the know who you are
using perl 5.004...
This is unfortunately true. However, the next version of perl is
imminent (ish) so it would be nice if the fix could be in it.
Alan Burlison
Can someone please explain why Apache does all the dlclosing and
dlopening of shared files on startup and a restart? I can think of no
reson why this would ever be necessary - why on earth is it done?
Alan Burlison
what seems to be a common
linker bug.
Alan Burlison
Daniel Jacobowitz wrote:
On Tue, Jan 18, 2000 at 08:03:42PM +, Alan Burlison wrote:
The current fix is to forcibly unload the perl XS modules during the
unload. However, on reflection I'm not at all sure this is the correct
thing to do. Although you can unload the .so component
the modules, it won't hurt.
I think they should be persuaded - this is a very insiduous bug and
extremely hard to find.
P.S. Does you get any feedback from your post to p5p about the unload
function in Dynaloader?
No. Nothing meaningful.
Alan Burlison
a chance to know what you do in your
programm. As soon as you use such things (and Dynloader uses them), the
linker doesn't have chance!
Nope, that's not how it works. Take a look at
http://docs.sun.com:80/ab2/coll.45.10/LLM/@Ab2PageView/5121
*All* symbols in a shared library are known by ld.so
Alan
Alan Burlison wrote:
AB from mod_perl - perl libperl.so). Unfortunately the perl XS modules
AB loaded in during startup via dlopen are *not* unloaded, nor do they
AB succeed in locking the perl libperl.so into memory (you could construe
AB this as a linker bug). Then Apache reloads
ase. Your description of the sequence leading up to the crash
fits well with what I observed when trying to trace the problem with
gcc.
It looks like Alan Burlison is on to a different dynamic linking
problem that also needs to be fixed.
No, it's the exactly the same problem, and the fix works
been shot to hell. If you can find and fix this bug, you
will be awarded the mod_perl Nobel prize.
Many thanks - that exactly matches my symptoms. I'll keep on digging,
but don't hold your breath. Has anyone tried purify on this?
Alan Burlison
of this binary (from libperl):
Built under solaris
Compiled at Jan 12 2000 11:44:51
@INC:
/usr/local/lib/perl5/5.00503/sun4-solaris
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris
/usr/local/lib/perl5/site_perl/5.005
.
Thanks,
Alan Burlison
28 matches
Mail list logo
