https://bugzilla.novell.com/show_bug.cgi?id=771559
https://bugzilla.novell.com/show_bug.cgi?id=771559#c2
L. A. Walsh changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |REOPENED
Resolution|INVALID |
--- Comment #2 from L. A. Walsh 2012-07-31 19:56:59 PDT ---
Simply asserting that the library is in db-devel doesn't mean that it works...
Did you try to build it? Could you include the build log?
I have db_devel installed.
Part of the issue stems from the build procedure for Perl using a broken script
to generate Perl. I don't know why it works for some people and not others --
I've tried MANY variations -- I've built perl up until I installed Suse 12.1.
Since then I've had multiple build issues because more and more, the builds in
open suse aren't being tested on any development system to see if they might
possible work.
I have seen builds fail due to broken packages suse requires for other packages
(libunwind being one that comes to mind -- causing a samba build to fail as it
can't build if libunwind is present, as it autoconfigs for stack traceback (A
GOOD THING, but unsupported by SUSE) as suse only builds shared libs and
doesn't provide a shared version of one of the libunwind modules
(libunwind-ptrace is only in an ".la".)
But if you try to build any smb related file system features like:
gvfsd-smb,gvfsd-smb-browser, fusesmb fusesmb.cache -- they require you load
libunwind. So you can't build all of samba and it's related features at once.
But samba is ANOTHER story...
the Perl procedure uses something called "configure.gnu" with a bunch of
options -- but at some point, (I DO remember it being a real configure script
at one point -- maybe in a a different reality), but right now, if you type
configure.gnu, you'll see that non of the options passed to it are supported --
including the options to include building of the DBM systems.
So when perl builds, it doesn't see that any of the DBM systems are needed and
thus doesn't build them (!!)... thus the test cases (~8 out of 15k+ tests)
involving the DB stuff fail and and the build fails.
So I want to know how you can get it to build with your script, when the
configure.gnu script in the perl.tar ignores those options....
Ishtar:home/packages/build/perl-5.14.2# configure.gnu --help
Usage: configure.gnu [options]
This is GNU configure-like front end for a metaconfig-generated Configure.
It emulates the following GNU configure options (must be fully spelled out):
--help
--no-create
--prefix=PREFIX
--cache-file (ignored)
--quiet
--silent
--verbose
--version
----
Yet the build script tries to use that bogus script to build in DBM
support:
chmod 755 ./configure.gnu
./configure.gnu --prefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl
-Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open
-Duseshrplib=\'true\' $options
make %{?_smp_mflags}
--
mv savelib lib
./configure.gnu --prefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl
-Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open $options
make %{?_smp_mflags}
uses incorrect/unsupported options -- almost all related to dbm support, in 2
places.
So, how does this build pass the perl tests that include testing of dbm
support?
During the configure run I see:
dbmclose() NOT found.
Hmm. Based on the hints in hints/linux.sh,
the recommended value for $i_dbm on this machine was "define"!
Keep the recommended value? [y] ]
...
found.
NOT found.
NOT found.
dbm_open() NOT found.
Hmm. Based on the hints in hints/linux.sh,
the recommended value for $d_dbm_open on this machine was "define"!
Keep the recommended value? [y]
Checking if your uses prototypes...
getaddrinfo() found.
found.
gdbm_open() NOT found.
Hmm. Based on the hints in hints/linux.sh,
the recommended value for $i_gdbm on this machine was "define"!
Keep the recommended value? [y]
-----
The comment *seemed* to indicate it was the responsibility of the loaded plugin
to load the loadable library (i.e. if you 'use *db*', that loads a .so which
should have some ref to...
But there is code in the config script specifically to remove any attempts to
define -Ddbm on the default build line, --- expecting that the libs will be
passed to to the plugins -- and maybe the dbm plugin is -- bug then the magick
one that is needed on suse 'gdbm-compat' isn't -- and it's the only one that
really defines the refs to the others..
It's screwed up, and I really don't know how you got it to build.
I haven't been able to rebuild perl in anyway shape or form (using their
configure scripts, using perl-brew--- nada... due to this problem).
Why it only cropped up on suse12.1... dunno...
But rather than just telling me db-devel is installed, I'd ask you to show me
the build logs which include the perl-test suite that run the db tests -- as
I'd like to find out why it build in factory (at some point) but I can't build
it trying any which way (and while I and others CAN, with hoops, build samba,
no one has yet claimed to be able to build perl...(5.14.2 or 5.16.0 -- the
latter having been my primary target, to check to see if some perl bugs were
fixed... but having no luck with that, I tried 5.14.2 -- then the rpmbuild...
.. and about 87 other things as well...
sigh...
thanks
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.