As an experiment, I tried to build 5.002b1f with NDBM_File (& Fcntl &
Socket) loaded statically on our DEC alpha. [*]
This fails t/lib/ndbm.t with
Program received signal SIGSEGV, Segmentation fault.
I tracked it down to the static build of perl ("\"s added for formatting)
gcc -L/usr/local/lib \
-o perl \
perlmain.o libperl.a \
lib/auto/DynaLoader/DynaLoader.a \
lib/auto/Fcntl/Fcntl.a \
lib/auto/NDBM_File/NDBM_File.a \
lib/auto/Socket/Socket.a \
`cat ext.libs` \
-ldbm -ldb -lm -lc -lbsd -lPW
What is happening is that the "-ldb" is supplying the "dbm_open()"
routines out of its compatibility library rather than leaving it for
the "-lc" to supply the traditional NDBM code. I confirmed this by
building with/without the "-ldb" argument.
The "NDBM_File.a" was built with reference to the traditional NDBM
include files.
I'm not sure precisely what causes the core dump. All that perl does
is throw around opaque "DBM *"s which should act much like "DB *"s.
However, even if it didn't crash it would be using the wrong library
routines.
What to do about it? We need to avoid using the "libdb" compatibility
routines, but still allow the raw "libdb" routines to be used if we
want *both* DB_File and NDBM_File linked statically.
I don't have a solution. Perhaps, supply our own libdb without the
ndbm routines, or grab the existing libdb.a and "ar d ndbm.o"?
What is the "-ldbm -ldb" doing for us on the build line? The
"`ext.libs`" should pick up the necessary static ext libraries. Is it
just historical? It wouldn't help my problem to remove them because
we'd still have the problem of wanting both static modules.
Anyone? [.Actually, I'd quite like a reply from anyone who sees this
to confirm that my messages are getting through]
Andrew
--
ajv@comp.vuw.ac.nz
[*] I guess one answer is "so don't do that!"
Summary of my perl5 (patchlevel 2) configuration:
Platform:
osname=dec_osf, osver=3.0, archname=alpha-dec_osf
uname='osf1 bats.comp.vuw.ac.nz v3.0 358 alpha '
hint=recommended
Compiler:
cc='gcc', optimize='-O -g', ld='ld'
cppflags='-DSTANDARD_C -DDEBUGGING -I/usr/local/include -D__LANGUAGE_C__ -D_NO_PROTO'
ccflags ='-DSTANDARD_C -DDEBUGGING -I/usr/local/include -D__LANGUAGE_C__ -D_NO_PROTO'
ldflags =' -L/usr/local/lib'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
voidflags=15, castflags=0, d_casti32=define, d_castneg=define
intsize=4, alignbytes=8, usemymalloc=y, randbits=15
Libraries:
so=so
libpth=/usr/local/lib /usr/shlib /lib /usr/lib /usr/ccs/lib
libs=-ldbm -ldb -lm -lc -lbsd -lPW
libc=/usr/shlib/libc.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef
cccdlflags='-fpic', ccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -s -hidden -L/usr/local/lib'
Socket) loaded statically on our DEC alpha. [*]
This fails t/lib/ndbm.t with
Program received signal SIGSEGV, Segmentation fault.
I tracked it down to the static build of perl ("\"s added for formatting)
gcc -L/usr/local/lib \
-o perl \
perlmain.o libperl.a \
lib/auto/DynaLoader/DynaLoader.a \
lib/auto/Fcntl/Fcntl.a \
lib/auto/NDBM_File/NDBM_File.a \
lib/auto/Socket/Socket.a \
`cat ext.libs` \
-ldbm -ldb -lm -lc -lbsd -lPW
What is happening is that the "-ldb" is supplying the "dbm_open()"
routines out of its compatibility library rather than leaving it for
the "-lc" to supply the traditional NDBM code. I confirmed this by
building with/without the "-ldb" argument.
The "NDBM_File.a" was built with reference to the traditional NDBM
include files.
I'm not sure precisely what causes the core dump. All that perl does
is throw around opaque "DBM *"s which should act much like "DB *"s.
However, even if it didn't crash it would be using the wrong library
routines.
What to do about it? We need to avoid using the "libdb" compatibility
routines, but still allow the raw "libdb" routines to be used if we
want *both* DB_File and NDBM_File linked statically.
I don't have a solution. Perhaps, supply our own libdb without the
ndbm routines, or grab the existing libdb.a and "ar d ndbm.o"?
What is the "-ldbm -ldb" doing for us on the build line? The
"`ext.libs`" should pick up the necessary static ext libraries. Is it
just historical? It wouldn't help my problem to remove them because
we'd still have the problem of wanting both static modules.
Anyone? [.Actually, I'd quite like a reply from anyone who sees this
to confirm that my messages are getting through]
Andrew
--
ajv@comp.vuw.ac.nz
[*] I guess one answer is "so don't do that!"
Summary of my perl5 (patchlevel 2) configuration:
Platform:
osname=dec_osf, osver=3.0, archname=alpha-dec_osf
uname='osf1 bats.comp.vuw.ac.nz v3.0 358 alpha '
hint=recommended
Compiler:
cc='gcc', optimize='-O -g', ld='ld'
cppflags='-DSTANDARD_C -DDEBUGGING -I/usr/local/include -D__LANGUAGE_C__ -D_NO_PROTO'
ccflags ='-DSTANDARD_C -DDEBUGGING -I/usr/local/include -D__LANGUAGE_C__ -D_NO_PROTO'
ldflags =' -L/usr/local/lib'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
voidflags=15, castflags=0, d_casti32=define, d_castneg=define
intsize=4, alignbytes=8, usemymalloc=y, randbits=15
Libraries:
so=so
libpth=/usr/local/lib /usr/shlib /lib /usr/lib /usr/ccs/lib
libs=-ldbm -ldb -lm -lc -lbsd -lPW
libc=/usr/shlib/libc.so
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef
cccdlflags='-fpic', ccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -s -hidden -L/usr/local/lib'