Memoize Test Failures on Mac OS X #5762

p5pRT · 2002-07-21T16:02:29Z

Migrated from rt.perl.org#15272 (status was 'stalled')

Searchable as RT15272$

p5pRT · 2002-07-21T16:02:29Z

From David@Wheeler.net

Created by david@wheeler.net

This is a bug report for perl from david@wheeler.net,
generated with the help of perlbug 1.33 running under perl v5.8.0.

While installing Perl 5.8.0 on Mac OS X, in addition to the usual expected
test failures, I got this *unexpected* test failure:

lib/Memoize/t/errors.................dyld: ./perl multiple definitions of
symbol __gdbm_alloc
..../lib/auto/GDBM_File/GDBM_File.bundle definition of __gdbm_alloc
..../lib/auto/NDBM_File/NDBM_File.bundle definition of __gdbm_alloc
FAILED at test 8

I took a quick look at lib/Memoize/t/errors, and on a hunch, I tried
commenting out the GDBM_File test. All tests then passed. Then I put the
GDBM_File test back in, and removed the NDBM_File test. Again all tests
passed. It appears that something's wonky when both of those libraries are
loaded at once, but not one at a time. Since I'm unlikely ever to load both
at once, I too worried, but I thought I should mention it, anwyay.

AFAIK, no other OS X user has experienced this particular test failure. The
only reason that I can guess that it's happening to me is because I compiled
and installed GDBM myself. It's possible that that has unexpected
consequences. The method I used to compile gdbm is described here:

http://david.wheeler.net/

I'd be interested to hear if anyone has any ideas about this, and I will
gladly be willing to try some experiments to figure it out.

Thanks for a great new Perl!

David

Perl Info


Flags:
    category=library
    severity=low

This perlbug was built using Perl v5.6.1 - Thu Mar 28 12:02:38 PST 2002
It is being executed now by  Perl v5.8.0 - Fri Jul 19 14:56:29 CET 2002.

Site configuration information for perl v5.8.0:

Configured by david at Fri Jul 19 14:56:29 CET 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=darwin, osvers=5.5, archname=darwin-thread-multi
    uname='darwin mercury.kineticode.com 5.5 darwin kernel version 5.5: thu
may 30 14:51:26 pdt 2002; root:xnuxnu-201.42.3.obj~1release_ppc power
macintosh powerpc '
    config_args='-des -Dusethreads'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-pipe -fno-common -no-cpp-precomp
-fno-strict-aliasing -I/usr/local/include',
    optimize='-O3',
    cppflags='-no-cpp-precomp -pipe -fno-common -no-cpp-precomp
-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.2 19991024 (release)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -flat_namespace -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib
    libs=-lgdbm -ldbm -ldl -lm -lc
    perllibs=-ldl -lm -lc
    libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true,
libperl=libperl.dylib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' -flat_namespace -bundle -undefined suppress
-L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /sw/lib/perl5
    /sw/lib/perl5
    /usr/local/bricolage/lib
    /Users/david/dev/perl/myco/classes
    /usr/local/bricolage/lib
    /Users/david/dev/perl/myco/classes
    /Library/Perl/darwin-thread-multi
    /Library/Perl
    /Library/Perl/darwin-thread-multi
    /Library/Perl
    /Library/Perl
    /Network/Library/Perl/darwin-thread-multi
    /Network/Library/Perl
    /Network/Library/Perl
    .


Environment for perl v5.8.0:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/david
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    
PATH=/usr/bin:/bin:/Users/david:/sbin:/usr/sbin:/Developer/Tools:/sw/bin:/sw
/sbin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/pgsql/bin:/usr/local/jakarta
-ant-1.4.1/bin
    
PERL5LIB=/sw/lib/perl5:/sw/lib/perl5:/usr/local/bricolage/lib:/Users/david/d
ev/perl/myco/classes:/usr/local/bricolage/lib:/Users/david/dev/perl/myco/cla
sses
    PERL_BADLANG (unset)
    SHELL=/bin/zsh

-- 
David Wheeler                                     AIM: dwTheory
david@wheeler.net                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                               Jabber: Theory@jabber.org

p5pRT · 2002-07-22T22:00:25Z

From @nwc10

On Sun, Jul 21, 2002 at 04:02:30PM -0000, David Wheeler wrote:

lib/Memoize/t/errors.................dyld: ./perl multiple definitions of
symbol __gdbm_alloc
....../lib/auto/GDBM_File/GDBM_File.bundle definition of __gdbm_alloc
....../lib/auto/NDBM_File/NDBM_File.bundle definition of __gdbm_alloc
FAILED at test 8

I took a quick look at lib/Memoize/t/errors, and on a hunch, I tried
commenting out the GDBM_File test. All tests then passed. Then I put the
GDBM_File test back in, and removed the NDBM_File test. Again all tests
passed. It appears that something's wonky when both of those libraries are
loaded at once, but not one at a time. Since I'm unlikely ever to load both
at once, I too worried, but I thought I should mention it, anwyay.

AFAIK, no other OS X user has experienced this particular test failure. The
only reason that I can guess that it's happening to me is because I compiled
and installed GDBM myself. It's possible that that has unexpected
consequences. The method I used to compile gdbm is described here:

http://david.wheeler.net/

I'd be interested to hear if anyone has any ideas about this, and I will
gladly be willing to try some experiments to figure it out.

I am unfamiliar with OS X - I assume from the above description that it
ships ndbm by default (or at least that building 5.8.0 on a default OS
X will build NDBM_File). Do I take it that on this default system there is
no gdbm, and GDBM_File would not get built?

Whereas on your system, you did install the C gdbm library, and now when
you Configure 5.8.0 it detects gdbm and ndbm, and therefore opts to build
NDBM_File and GDBM_File.

IIRC gdbm has the ability to emulate the interface of ndbm (or at least
provide an ndbm.h which in turn has cause "fun" on some or other platform)

Could it be that OS X by default has a "ndbm" that is actually really
gdbm's implementation of gdbm, but Apple have chosen not to ship the gdbm
header? In which case, is OS X's "interesting" dynamic linking system now
biting you? (I don't know much about OS X's dynamic linking system, except
that it seems to cause a lot more trouble when you try to have multiple
versions of the same library than other Unixes. Such as FreeBSD. Which as
OS X is based on FreeBSD really doesn't make sense to me. They took something
working and made it broken? That's not clever)

Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/

p5pRT · 2002-07-30T01:21:39Z

From David@Wheeler.net

On Monday, July 22, 2002, at 03:00 PM, Nicholas Clark (via RT) wrote:

I am unfamiliar with OS X - I assume from the above description that it
ships ndbm by default (or at least that building 5.8.0 on a default OS
X will build NDBM_File). Do I take it that on this default system there is
no gdbm, and GDBM_File would not get built?

I honestly don't know. I installed gdbm because something else I was
installing couldn't find a dbm library. But maybe it was bogus.

Whereas on your system, you did install the C gdbm library, and now when
you Configure 5.8.0 it detects gdbm and ndbm, and therefore opts to build
NDBM_File and GDBM_File.

Yeah, that would be my guess.

IIRC gdbm has the ability to emulate the interface of ndbm (or at least
provide an ndbm.h which in turn has cause "fun" on some or other platform)

Could it be that OS X by default has a "ndbm" that is actually really
gdbm's implementation of gdbm, but Apple have chosen not to ship the gdbm
header? In which case, is OS X's "interesting" dynamic linking system now
biting you?

I don't think so. I just found what appears to be the default nbdm.h on my
system, and it's (c) Apple computer, and Regents of the UC. That doesn't
sound like gdbm, which is under the GPL.

Regards,

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org

p5pRT · 2002-08-12T19:13:13Z

From @gbarr

As you have noticed OS X ships with ndbm. I downloaded gdbm
and played a little. configure does not notice that the system
has ndbm, so it is building its ndbm over gdbm emulation.

From this I assume that the OS X ndbm and the ndbm built with
gdbm are causing name clashes when both are loaded.

I would suggest rebuilding gdbm but without the ndbm layer

p5pRT · 2002-08-12T20:08:11Z

From David@Wheeler.net

[gbarr - Mon Aug 12 12:13:13 2002]:

From this I assume that the OS X ndbm and the ndbm built with
gdbm are causing name clashes when both are loaded.

I would suggest rebuilding gdbm but without the ndbm layer

Yes, that makes sense. I originally installed gdbm because something
else I installed required a dbm, and couldn't find it. I didn't think OS
X had *any* dbm lib, but I guess that's wrong -- configure just doesn't
know where to find it.

I can't find any documentation in the gdbm sources for how to compile
w/o ndbm support. The README document says to run make installcompat to
install gdbm with dbm and ndbm support, but I didn't do that, and it
installed ndbm support, anyway, as you note.

Any suggestions on how to compile gdbm w/o ndbm would be welcome.

Thanks!

David

p5pRT · 2003-04-28T13:15:15Z

arthur@contiller.se - Status changed from 'new' to 'open'

p5pRT · 2003-04-28T13:36:58Z

From arthur@contiller.se

This bug is actually two.

First of all, under OSX we should not be building everything useing -flatnamespace

However more importantly, if GDBM is installed with NDBM compat mode, we never use
the NDBM that apple provides, this I guess is a bug.

I assume there is configure magic that needs to be done so I am ccing this to you
Jarkko.

Arthur

p5pRT · 2003-04-28T13:52:49Z

From @jhi

This bug is actually two.

First of all, under OSX we should not be building everything useing
-flatnamespace

I *think* the last time this issue was raised Fred Sanchez explained
that "yes, we should". Please search the p5p archives.

However more importantly, if GDBM is installed with NDBM compat
mode, we never use the NDBM that apple provides, this I guess is
a bug.

Please. Explain. More. Slowly.

I assume there is configure magic that needs to be done so I am
ccing this to you Jarkko.

--
Jarkko Hietaniemi <jhi@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen

p5pRT · 2003-04-28T15:27:38Z

From sky@nanisky.com

On måndag, apr 28, 2003, at 15:52 Europe/Stockholm, Jarkko Hietaniemi
wrote:

However more importantly, if GDBM is installed with NDBM compat
mode, we never use the NDBM that apple provides, this I guess is
a bug.

Please. Explain. More. Slowly.

Currently it seems like if GDBM is installed with NDBM compat mode we
pick that NDBM (GDBM/NDBM) instead of the real NDBM.

Which means that when you load GDBM and NDBM you end up loading the
same library twice through two different bundles and you end up with a
error.

Arthur

p5pRT · 2003-04-28T22:25:48Z

From david@kineticode.com

Sorry about the pointless reply a minute ago. Getting used to Pine on a
terminal again while I'm at a client site.

On 28 Apr 2003, Jarkko Hietaniemi wrote:

This bug is actually two.

First of all, under OSX we should not be building everything useing
-flatnamespace

I *think* the last time this issue was raised Fred Sanchez explained
that "yes, we should". Please search the p5p archives.

IIRC, and I admit to knowing little about this, the rules changed in
Jaguar. I seem to recall seeing something about it on an TIL article or
something.

However more importantly, if GDBM is installed with NDBM compat
mode, we never use the NDBM that apple provides, this I guess is
a bug.

Please. Explain. More. Slowly.

See the full bug report.

http://rt.perl.org/rt2/Ticket/Display.html?id=15272

FWIW, I've stopped compiling GDBM on my OS X box once I figured out how to
get Apache to find Mac OS X's DBM:

http://www.macdevcenter.com/pub/a/mac/2002/12/18/apache_modssl.html
http://david.wheeler.net/macosx/apache_dbm.patch

Regards,

David

--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Settiong knowledge in motion.[sm]

p5pRT · 2003-04-28T22:26:37Z

From david@kineticode.com

On 28 Apr 2003, Jarkko Hietaniemi wrote:

This bug is actually two.

First of all, under OSX we should not be building everything useing
-flatnamespace

I *think* the last time this issue was raised Fred Sanchez explained
that "yes, we should". Please search the p5p archives.

However more importantly, if GDBM is installed with NDBM compat
mode, we never use the NDBM that apple provides, this I guess is
a bug.

Please. Explain. More. Slowly.

I assume there is configure magic that needs to be done so I am
ccing this to you Jarkko.

--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Settiong knowledge in motion.[sm]

p5pRT · 2004-12-13T22:22:08Z

From @schwern

Do you still experience these problems with 5.8.6?

p5pRT · 2004-12-13T22:22:10Z

@schwern - Status changed from 'open' to 'stalled'

p5pRT · 2004-12-13T23:20:25Z

From david@kineticode.com

On Dec 13, 2004, at 2:22 PM, Michael G Schwern via RT wrote:

Do you still experience these problems with 5.8.6?

I don't know if it's a problem; I stopped installing GDBM once I
figured out how to make mod_ssl use Apple's default (and on Jaguar,
broken) Berkeley DB install. But if you know of someone with GDBM
installed, it should be easy to test. IIRC, it just seemed to get
confused about the two separate dbm installs, but only in tests. I
never had a problem with production code or applications...

HTH,

David

p5pRT added Severity Low distro-darwin type-library labels Oct 18, 2019

xenu removed the affects-5.8 label Nov 19, 2021

xenu removed the Severity Low label Dec 29, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Memoize Test Failures on Mac OS X #5762

Memoize Test Failures on Mac OS X #5762

p5pRT commented Jul 21, 2002

p5pRT commented Jul 21, 2002

p5pRT commented Jul 22, 2002

p5pRT commented Jul 30, 2002

p5pRT commented Aug 12, 2002

p5pRT commented Aug 12, 2002

p5pRT commented Apr 28, 2003

p5pRT commented Apr 28, 2003

p5pRT commented Apr 28, 2003

p5pRT commented Apr 28, 2003

p5pRT commented Apr 28, 2003

p5pRT commented Apr 28, 2003

p5pRT commented Dec 13, 2004

p5pRT commented Dec 13, 2004

p5pRT commented Dec 13, 2004

Memoize Test Failures on Mac OS X #5762

Memoize Test Failures on Mac OS X #5762

Comments

p5pRT commented Jul 21, 2002

p5pRT commented Jul 21, 2002

From David@Wheeler.net

Created by david@wheeler.net

p5pRT commented Jul 22, 2002

From @nwc10

p5pRT commented Jul 30, 2002

From David@Wheeler.net

p5pRT commented Aug 12, 2002

From @gbarr

p5pRT commented Aug 12, 2002

From David@Wheeler.net

p5pRT commented Apr 28, 2003

p5pRT commented Apr 28, 2003

From arthur@contiller.se

p5pRT commented Apr 28, 2003

From @jhi

p5pRT commented Apr 28, 2003

From sky@nanisky.com

p5pRT commented Apr 28, 2003

From david@kineticode.com

p5pRT commented Apr 28, 2003

From david@kineticode.com

p5pRT commented Dec 13, 2004

From @schwern

p5pRT commented Dec 13, 2004

p5pRT commented Dec 13, 2004

From david@kineticode.com