Bug 905482 - perl's Config libs contains -lgdbm but it is not in perl-devel
perl's Config libs contains -lgdbm but it is not in perl-devel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: perl (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Petr Pisar
Martin Kyral
: EasyFix
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-29 08:53 EST by Jan Pazdziora
Modified: 2013-12-09 02:55 EST (History)
7 users (show)

See Also:
Fixed In Version: perl-5.10.1-133.el6
Doc Type: Bug Fix
Doc Text:
Cause: Building XML-LibXSLT Perl library without installed libgdm-devel package. Consequence: Linking the library fails on missing libgdbm.so. Fix: glibc-devel, gdbm-devel, and db4-devel have been added to perl-devel list of run-time dependencies. Result: It's possible to build native Perl libraries whose build-scripts add $Config{libs} value to linker arguments.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-20 23:40:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1534 normal SHIPPED_LIVE perl bug fix and enhancement update 2013-11-20 16:40:56 EST

  None (edit)
Description Jan Pazdziora 2013-01-29 08:53:33 EST
Description of problem:

Hello, XML::LibXSLT's Makefile.PL uses $Config{libs} to add libs to gcc. However, running make fails even if perl-devel package is installed.

Version-Release number of selected component (if applicable):

# rpm -q perl
perl-5.10.1-127.el6.i686

How reproducible:

Deterministic.

Steps to Reproduce:
1. Download XML::LibXSLT.
2. Run perl Makefile.PL and make
  
Actual results:

# perl Makefile.PL 
running xslt-config... failed
using fallback values for LIBS and INC
options:
  LIBS='-L/usr/local/lib -L/usr/lib -lxslt -lxml2 -lz -lm'
  INC='-I/usr/local/include -I/usr/include'
If this is wrong, Re-run as:
  $ /usr/bin/perl Makefile.PL LIBS='-L/path/to/lib' INC='-I/path/to/include'

looking for -lxslt... yes
looking for -lexslt... yes
running pkg-config libexslt... ok
Checking if your kit is complete...
Looks good
Writing Makefile for XML::LibXSLT
# make
cp LibXSLT.pm blib/lib/XML/LibXSLT.pm
/usr/bin/perl /usr/share/perl5/ExtUtils/xsubpp  -typemap /usr/share/perl5/ExtUtils/typemap -typemap typemap  LibXSLT.xs > LibXSLT.xsc && mv LibXSLT.xsc LibXSLT.c
gcc -c  -I/usr/local/include -I/usr/include -I/usr/include/libxml2   -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -DVERSION=\"1.80\" -DXS_VERSION=\"1.80\" -fPIC "-I/usr/lib/perl5/CORE"  -DHAVE_BLANK -DHAVE_BLANK -DHAVE_EXSLT LibXSLT.c
LibXSLT.xs: In function ‘LibXSLT__function’:
LibXSLT.xs:252: warning: pointer targets in passing argument 1 of ‘xmlNewDoc’ differ in signedness
/usr/include/libxml2/libxml/tree.h:735: note: expected ‘const xmlChar *’ but argument is of type ‘char *’
LibXSLT.xs: In function ‘LibXSLT_context_element’:
LibXSLT.xs:518: warning: unused variable ‘ent’
LibXSLT.xs: In function ‘LibXSLT_init_functions’:
LibXSLT.xs:916: warning: suggest parentheses around assignment used as truth value
LibXSLT.xs: In function ‘LibXSLT_init_elements’:
LibXSLT.xs:948: warning: suggest parentheses around assignment used as truth value
gcc -c  -I/usr/local/include -I/usr/include -I/usr/include/libxml2   -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables   -DVERSION=\"1.80\" -DXS_VERSION=\"1.80\" -fPIC "-I/usr/lib/perl5/CORE"  -DHAVE_BLANK -DHAVE_BLANK -DHAVE_EXSLT perl-libxml-mm.c
Running Mkbootstrap for XML::LibXSLT ()
chmod 644 LibXSLT.bs
rm -f blib/arch/auto/XML/LibXSLT/LibXSLT.so
gcc  -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -L/usr/local/lib LibXSLT.o perl-libxml-mm.o  -o blib/arch/auto/XML/LibXSLT/LibXSLT.so 	\
	   -L/usr/local/lib -L/usr/lib -lxslt -lxml2 -lz -lm -lexslt -lgcrypt -ldl -lgpg-error -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc  	\
	  
/usr/bin/ld: cannot find -lgdbm
collect2: ld returned 1 exit status
make: *** [blib/arch/auto/XML/LibXSLT/LibXSLT.so] Error 1
#

Expected results:

The make should pass. Either the -lgdbm should not be in $Config{libs}, or perl-devel should require gdbm-devel.

Additional info:

Related to OpenShift bug 905369.

Please note that perl-XML-LibXSLT-1.70-1.1.el6's .spec file specifically does

BuildRequires: gdbm-devel

That shouldn't be necessary, IMO.
Comment 2 Jan Pazdziora 2013-01-29 09:29:59 EST
Petr P. has suggested that XML::LibXSLT should in fact use perllibs, not libs. I've filed a ticket against upstream now: https://rt.cpan.org/Ticket/Display.html?id=83028
Comment 3 RHEL Product and Program Management 2013-02-02 01:47:55 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 4 Petr Pisar 2013-04-02 12:17:53 EDT
perl-devel could run-depend gdbm-devel.
Comment 6 Petr Pisar 2013-06-06 04:44:21 EDT
If we decides to run-requires gdbm-devel, we should run-require all providers of the libraries:

# perl -MConfig -e 'print $Config{libs}, qq{\n}'
-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc

I.e.: glibc-devel, gdbm-devel, db4-devel.
Comment 13 Vitaly Kuznetsov 2013-10-21 05:07:34 EDT
This fix broke our AWS EC2 AMIs as it introduced a bunch of extra -devel packages into minimal package set, https://bugzilla.redhat.com/show_bug.cgi?id=1017339
Comment 16 errata-xmlrpc 2013-11-20 23:40:55 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1534.html
Comment 17 Chris 2013-12-04 15:30:04 EST
Applications like spamassassin, and amavisd-new have dependencies on perl-ExtUtils-ParseXS and perl-ExtUtils-MakeMaker to work.

ExtUtils-ParseXS and perl-ExtUtils-MakeMaker depend on perl-devel for a few of the tools provided in /usr/bin/* by the devel package and the Encode modules?

Anyway... now people who run a small mail server upgrading their perl libraries to accommodate the 'CVE-' security updates now have to haul in all of glib and compiling libraries which in turn pull in kernel headers too.

All because one person didn't like adding 3 more packages to their 'yum install' line?

I'd really like to request this be rolled back and the people who are installing the perl-devel library to build the same specific modules the original poster was building. Get rid of 'Requires: glibc-devel, gdbm-devel, db4-devel' in it's entirety.

If you just install gdbm-devel, it doesn't in turn grab glibc-devel, so why should perl-devel do this? Try installing python-devel,  You'll see you don't haul in any of these glibc-devel libraries and kernel headers either. You'll JUST pull in the package alone allowing you to work with it as you need to.

The soul purpose of the 'perl-devel' package should not depend on these other packages at all. Heck that's what configure.ac scripts are for. If you're a developer building with required packages, you specify in your documentation, your prepare/configure scripts. Your configure script can check for them and fail your install if they're missing... Tell your user their missing packages like everyone else does. Heck, make it even easier on them, do it the RedHat way and package it through RPMs. Then you can put: 'Requires: glibc-devel  gdbm-devel  db4-devel' in your own spec file but it should not be in 'perl-devel' at all.


Chris
Comment 18 Jan Pazdziora 2013-12-04 20:17:20 EST
(In reply to Chris from comment #17)
> Applications like spamassassin, and amavisd-new have dependencies on
> perl-ExtUtils-ParseXS and perl-ExtUtils-MakeMaker to work.

Why have those applications a run-dependency on something which judging by its name should primarily be used for build?

> ExtUtils-ParseXS and perl-ExtUtils-MakeMaker depend on perl-devel for a few
> of the tools provided in /usr/bin/* by the devel package and the Encode

That sounds expected -- they are build tools/modules, unlike spamassassin and amavisd-new.

> Anyway... now people who run a small mail server upgrading their perl
> libraries to accommodate the 'CVE-' security updates now have to haul in all
> of glib and compiling libraries which in turn pull in kernel headers too.
> 
> All because one person didn't like adding 3 more packages to their 'yum
> install' line?

The reason why the one person (me) filed this bugzilla was not because they were lazy but because there was an inconsistency between what packaged perl ships in Config and what was in perl and perl-devel packages. Please see comment 0, Expected results:

   The make should pass. Either the -lgdbm should not be in $Config{libs},
   or perl-devel should require gdbm-devel.

Please note that the use case is about building another module, for which I assume the dependency on perl-devel is justified.

Please also note that it was this inconsistency which prevented some operation (installation of the package) in contexts when running that 'yum install' line is not easy or outright not possible, like OpenShift.

> I'd really like to request this be rolled back and the people who are
> installing the perl-devel library to build the same specific modules the
> original poster was building. Get rid of 'Requires: glibc-devel, gdbm-devel,
> db4-devel' in it's entirety.
> 
> If you just install gdbm-devel, it doesn't in turn grab glibc-devel, so why
> should perl-devel do this?

Because 

  # perl -MConfig -le 'print $Config{libs}'
  -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc

> Try installing python-devel,  You'll see you
> don't haul in any of these glibc-devel libraries and kernel headers either.
> You'll JUST pull in the package alone allowing you to work with it as you
> need to.

Work with what? The purpose to X-devel packages seems to be to build libraries/extensions on top of/using X. If it works for python, fine. But it does not seem to work for perl.

> The soul purpose of the 'perl-devel' package should not depend on these
> other packages at all. Heck that's what configure.ac scripts are for. If
> you're a developer building with required packages, you specify in your
> documentation, your prepare/configure scripts. Your configure script can
> check for them and fail your install if they're missing... Tell your user
> their missing packages like everyone else does. Heck, make it even easier on
> them, do it the RedHat way and package it through RPMs. Then you can put:
> 'Requires: glibc-devel  gdbm-devel  db4-devel' in your own spec file but it
> should not be in 'perl-devel' at all.

True. As long as it's not in %Config either.
Comment 19 Jan Pazdziora 2013-12-04 20:20:59 EST
(In reply to Chris from comment #17)
> 
> I'd really like to request this be rolled back and the people who are

Please work with your Red Hat support contact to have your request tracked by Red Hat support and engineering -- this bugzilla is now closed since the errata went out and if any other change is to be made (like revert), it needs to be tracked as completely new issue from start to end.

Thank you, Jan
Comment 20 Chris 2013-12-06 09:25:02 EST
'make' is a build tool as well and it doesn't haul in the glibc-devel modules because this tool can be used for other things as well.

You can also install the gdbm-devel and db4-devel without hauling in all of the glibc-devel and it's dependencies as well.

Perhaps the solution is to separate the dependencies within perl-devel (required by perl-ExtUtils-ParseXS and perl-ExtUtils-MakeMaker) into a different module?

Anyway, I'm not going to argue with a RedHat representative of the perl library.  If you strongly feel this was the right decision then by all means keep it.  I'll just recompile it with those lines missing for myself. Thank you for justifying your reasoning more.

In addition to that, I also am sorry for my rant above.  It was a heat of the moment thing when I preformed a simple 'yum update' on my system and all these development modules wanted to be installed too.  I traced it back to this package and got frustrated. I should have waited a day and made a more mature post instead of what I wrote.

Note You need to log in before you can comment on or make changes to this bug.