During test phase, we see: error while loading shared libraries: ../lib/auto/NDBM_File/NDBM_File.so: undefined symbol: dbm_open From linked thread: > Looking at the hints in ext/NDBM_File/hints/linux.pl, it seems that > perl is of the opinion that the libndbm.a library is to be avoided and > the compatibility routines in libgdbm.a used instead. > > However, I thought that as of gdbm-1.8.1, the compatibility routines > were moved to a separate library libgdbm_compat.a. I see no sign of > perl's configuration process checking for or using this library > (except with cygwin), but I do see several linux bug reports where the > library is being linked; this implies to me that some linux > distributions are getting Configure to do so. gdbm 1.8.3 is the first post 1.8.0 version that has been made available to my Portage configuration. The linked thread contains a patch which I will attach and which appears to fix the problem.
Created attachment 32433 [details, diff] perl-5.8.4-NDBM-GDBM-compat.patch
Thanks, this will make it into 5.8.4-r1 and beyond.
Well, perl doesn't work that well on AMD64 this way. Why don't you mark perl 5.8.4-r1 stabel an all platforms where gdbm-1.8.3 is stable. Your are in a duty to do that, or something similar like including the patch in 5.8.4 (without r1) etc.
*** Bug 63096 has been marked as a duplicate of this bug. ***
Isn't this bug resolved now? I looked over the ebuilds, and perl-5.8.5-r3.ebuild for instance is flaged stable for all arcs including even ppc64
Marking fixed since this hasn't been commented on as a problem since 2 stables ago (5.8.5)
