Just found another thing.

$ perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_vars(libs, perllibs);"\n";'
libs='-lpthread -lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat';
perllibs='-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc';

Looks like libnsl can be removed from above list because on Linux this library contains NIS/YP ABI functions (not like on Solaris for example gethostbyname())

Theoretically list of those libraries offered in perllibs should be empty because only if exact compiled module will be using some routines from those libraries ABI it should take care of detecting it and include in module lining options.
This theoretically may break some perl modules build but defilitelly -lc and -lnsl can be removed without impact.

if you agree with above please hold commiting this patch and I'll try prepare second part to at least remove libnsl from libs and perllibs Config variables.

Corrected not finished second paragraph from this ticket description:

Currently perl-devel requires libdb-devel and gddb-devel.
in reality those packages are completly not needed and what was reported in https://bugzilla.redhat.com/show_bug.cgi?id=905482 was kind of incorrect fix as looks like -lgdbm ave been on the list of libraries with which been present at this time in perrlib Config variables.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Your suggestions contradicts with bug #905482. I won't add or remove the dependencies in each release to please the contemporary more loudly camp of proponents or opponents of requiring libraries listed in the Perl's configuration. Please find consensus first.

In my opinion, the dependencies should not be there because %Config contains data about how the perl was configured and built. Many of them have only an informational purpose and are not intended to be thrown to compiler or linker.

E.g. $Config{locincpth} lists /opt/GNU/include directory. Should perl-devel package depend on the (nonexitent!) directory? I guess everybody agrees it shouldn't.

E.g. $Config{libs} lists -lgdbm library. Should perl-devel package depend on gdbm-devel? Some people think it should.

I don't have strong opinion one way or another. I believe consistency is king. OTOH, you've pointed out that it should likely be perllibs, not libs which should be used by XML::LibXSLT.

1) $Config{libs} does not lists -lgdbm library.
Did you try to test it by execute "perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_vars(perllibs);"\n";'"

[tkloczko@domek SPECS]$ perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_vars(perllibs);"\n";'; rpm -q perl perl-devel 
perllibs='-lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc';
perl-5.26.0-398.fc27.x86_64
perl-devel-5.26.0-398.fc27.x86_64

Please try to check what this commend returns on your system.

2) Please have look that bug #905482 is 4 years old and in mean time perl changes dramatically.

3) nothing in XML::LibXSLT is using libgdbm or libdb and only reason which this build failed was because "perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_vars(perllibs);"\n";'" has been returning -lgdbm in the list of the libraries. This was bug in perl because in this list where all libraries with which libperl.so has been linked. *Not because some other modules during linking may need the same list of libraries*. Do you see this?

4) Look on what I've included in in above report that NOW XML::LibXSLT is building correctly because $Config variables have completely different list of libraries.Just try to remove gdbm-devel with --nodep and try to build XML::LibXSLT. What was reported in bug #905482 is no longer truth and three years ago solution was incorrect because instead adding do perl-devel Requires perl-devel should be fixed. Looks like 4 years ago someone made wrong decision without even rising question "why DSO linked in XML::LibXSLT is trying to link with -lgdbm if nothing in this module code is using single routine from gdbm?"

5) issue with /opt/GNU/include director is another part of the story and it should be fixed as well.

6) the same is with other libraries. For example -lc is part of the standard gcc specs:

$ gcc -dumpspecs | grep -- -lc
%{!mandroid|tno-android-ld:%{pthread:-lpthread} %{shared:-lc}    %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}};:%{shared:-lc}    %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}} %{!static: -ldl}}

it is provided by perl $Config only because on some non-linux platform perl everything was linked using gcc passing to ld 

in other words: -lc is added to linked libraries even if someone is not specifying this library in list of libraries.

7) the same is wit all other libraries offered in perllib. They should be removed but I'm not going to offer this because perl modules usually are not doing any libraries detentions and libresolve or libutil may be needed by several peel modules. This should be fixed as well but it will take much more time. Because gdbm and libdb is very rarely used this is why I've proposed to remove gdbm-devel and libdb-devel because liking on list of modules in Fedora nothing should be broken instantly by this.

8) as radical change on begin of F28 maybe it should be applied emptying perrlib variable to expose all modules which should take care of detecting any libraries which other modules may need to fix those modules bit now is IMO not good time to do this.

> Because gdbm and libdb is very rarely used this is why I've proposed to remove gdbm-devel and libdb-devel because liking on list of modules in Fedora nothing should be broken instantly by this.

Clarification: in the past perrlib had on the -lgdbm and as temporary solution it was maybe acceptable to add gdbm-devel and libdb-devel to perl-devel dependencies. However NOW this is not he case because none of those two libraries are offered in perrlib Config variable.

Tomasz, three things:

(1) Past perllibs did not have -lgdbm. There has nothing changed in last four years.

(2) I don't buy the argument with less and more frequent libraries. That was exactly the subject of bug #905482. The consistency.

(3) All the unneeded libraries you see in the values (-lc etc.) are matter of build script developed and maintained by upstream. Fedora is not the right place do deal with it. Please discuss your findings with Perl authors <https://rt.perl.org/>. They are the most competent people in improving Perl's configuration script.

> (2) I don't buy the argument with less and more frequent libraries. That was exactly the subject of bug #905482. The consistency.

Just unpacked one more time perl-XML-LibXSLT and done experiment:

[tkloczko@domek XML-LibXSLT-1.95]$ grep -r gdbm *
[tkloczko@domek XML-LibXSLT-1.95]$ 

If none of the files in this module has anything about gdbm it must be logical conclusion that this library in the past was offered by perl-devel.
there is only few packages in whole distribution which requires and uses gdbm-devel and of these packages is perl -> in the past perl-devel incorrectly have been offering this library.

Do you see any other explanation why in the past -lgdbm was used during linking DSO of perl-XML-LibXSLT?

>(3) All the unneeded libraries you see in the values (-lc etc.) are matter of build script developed and maintained by upstream. Fedora is not the right place do deal with it. Please discuss your findings with Perl authors <https://rt.perl.org/>. They are the most competent people in improving Perl's configuration script.

Hmm .. but perl is not able to compile any perl scripts to DSOs (?? !!!)

Please .. did you try to build perl-XML-LibXSLT to check that effect in  bug #905482 is no longer the case?
This has nothing to do with Perl authors. I have no idea about that is the connection between exact case which we are discussing now.

if in the past perl-XML-LibXSLT have been linking with gdbm now it is no longer the case. Another proof:

# dnf repoquery --whatrequires 'libgdbm.so.4()(64bit)' | grep perl
Last metadata expiration check: 2:26:14 ago on Tue 15 Aug 2017 06:59:42 BST.
perl-eperl-0:2.2.14-37.fc27.x86_64
perl-interpreter-4:5.26.0-398.fc27.x86_64

I have no idea how it was before last mass rebuild but now affected perl-XML-LibXSLT by (seems) bug in perl-devel is not linking with this library.

If any of the perl modules really needs to link with gdbm build of those modules is failing now or will fail during next try. Such cases should be not handled by adding to perl-devel gdbm-devel or libdb-devel but by adding BuildRequires to those packages.

Again: nothing which is now using perl-devel should be even trying to link with libbd or gdbm. If something is trying it is not the perl-devel problem or it should be not treated as anything to fix in perl-devel.

(In reply to Tomasz Kłoczko from comment #9)
> 
> Do you see any other explanation why in the past -lgdbm was used during
> linking DSO of perl-XML-LibXSLT?

The explanation per bug 905482 at least as I understand it is that XML::LibXSLT use(s/d) $Config{libs} in buildtime.

And final argument. Here is quite fresh latest perl-XML-LibXSLT build log:

https://kojipkgs.fedoraproject.org//packages/perl-XML-LibXSLT/1.95/6.fc27/data/logs/x86_64/build.log

As you can see there is nothing about -lgdbm in this build log.

> The explanation per bug 905482 at least as I understand it is that XML::LibXSLT use(s/d) $Config{libs} in buildtime.

No it is not using it :)

Please try to build perl-XML-LibXSLT without make package (just "rpmbuild -bc perl-XML-LibXSLT.spec" and after this go to build root and check can you find any traces of gdbm in his module build tree.

(In reply to Tomasz Kłoczko from comment #9)
> > (2) I don't buy the argument with less and more frequent libraries. That was exactly the subject of bug #905482. The consistency.
> 
> Just unpacked one more time perl-XML-LibXSLT and done experiment:
> 
> [tkloczko@domek XML-LibXSLT-1.95]$ grep -r gdbm *
> [tkloczko@domek XML-LibXSLT-1.95]$ 
> 
> If none of the files in this module has anything about gdbm it must be
> logical conclusion that this library in the past was offered by perl-devel.
> there is only few packages in whole distribution which requires and uses
> gdbm-devel and of these packages is perl -> in the past perl-devel
> incorrectly have been offering this library.
> 
> Do you see any other explanation why in the past -lgdbm was used during
> linking DSO of perl-XML-LibXSLT?
> 
The explanation is I patched perl-XML-LibXSLT's Makefile.PL to use $Config{perllibs} instead of $Config{libs}. The original upstream code is still affected.

You can see <http://grep.cpan.me/?q=%5C%24Config%5C%7Blibs%5C%7D> for all CPAN distributions that uses the $Config{libs} value. Maybe they are wrong.

> (2) I don't buy the argument with less and more frequent libraries. That was exactly the subject of bug #905482. The consistency.

I showed you last build log which proves that what was the case with bug #905482 is *no longer truth today*.
I've showed you current current perl-XML-LibXSLT is not linked with gdbm and it not uses it during any stages of build time (build log).
As long 4 years ago it was not the same version of the perl module I've checked even old package by downloading from http://vault.centos.org/6.9/os/Source/SPackages/perl-XML-LibXSLT-1.70-1.1.el6.src.rpm affected package and there is no any traces of gdmb in source tree.

In Makefile.PL you can find line:

$config{LIBS}.=' '.$Config{perllibs};

Which adds use $Config{perllibs} not as you suggesting $Config{libs} !!!
Did you had a look on this perl module code before replying that it use(s/d) $Config{libs} ???

From you side I have only "I don't buy the" and something about contacting perl developers. So what kind of question I should as them or what I should discuss?
Really I have no idea how can I reply on this "I don't buy the argument " :(

What do you want me to prove or show you?



One a side of the subject about remove {gdbm,libdb}-devel ..
Why Fedora perl should have in perllibs all those libraries if bu default none of the modules without using any routines from those libraries ABIs are using them?
Do you have some kind of working knowledge how linker is working? I can understand that without such knowledge you may have some doubts about emptying perllib however I'm not suggesting this in this ticket and this should be not discussed in scope of this ticket).

> The explanation is I patched perl-XML-LibXSLT's Makefile.PL to use
> $Config{perllibs} instead of $Config{libs}. The original upstream code is
> still affected.
> 
> You can see <http://grep.cpan.me/?q=%5C%24Config%5C%7Blibs%5C%7D> for all
> CPAN distributions that uses the $Config{libs} value. Maybe they are wrong.

So look on this.

[tkloczko@domek XML-LibXSLT-1.95]$ rm blib/arch/auto/XML/LibXSLT/LibXSLT.so; make
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- LibXSLT.bs blib/arch/auto/XML/LibXSLT/LibXSLT.bs 644
rm -f blib/arch/auto/XML/LibXSLT/LibXSLT.so
gcc  -shared -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong  LibXSLT.o perl-libxml-mm.o  -o blib/arch/auto/XML/LibXSLT/LibXSLT.so  \
   -L/usr/lib64 -lxslt -lxml2 -lz -llzma -ldl -lm -lexslt -llzma -lgcrypt -ldl -lgpg-error -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc -lperl   \
  
chmod 755 blib/arch/auto/XML/LibXSLT/LibXSLT.so
Manifying 1 pod document

so you have here all gcc command with all params and this is generating DSO object which according to elf header uses libraries:

[tkloczko@domek XML-LibXSLT-1.95]$ objdump -x blib/arch/auto/XML/LibXSLT/LibXSLT.so | grep NEEDED
  NEEDED               libxslt.so.1
  NEEDED               libxml2.so.2
  NEEDED               libz.so.1
  NEEDED               liblzma.so.5
  NEEDED               libdl.so.2
  NEEDED               libm.so.6
  NEEDED               libexslt.so.0
  NEEDED               libgcrypt.so.20
  NEEDED               libgpg-error.so.0
  NEEDED               libpthread.so.0
  NEEDED               libresolv.so.2
  NEEDED               libnsl.so.1
  NEEDED               libcrypt.so.1
  NEEDED               libutil.so.1
  NEEDED               libc.so.6
  NEEDED               libperl.so.5.26

Now I'll try exactly the same gcc command but with -Wl,--as-needed to allow pass gcc to linker --as-needed whic removed from ELF header all SONAME libraries which in reality are not used by this binary:

[tkloczko@domek XML-LibXSLT-1.95]$ gcc  -shared -Wl,--as-needed -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -fstack-protector-strong  LibXSLT.o perl-libxml-mm.o  -o blib/arch/auto/XML/LibXSLT/LibXSLT.so     -L/usr/lib64 -lxslt -lxml2 -lz -llzma -ldl -lm -lexslt -llzma -lgcrypt -ldl -lgpg-error -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc -lperl; objdump -x blib/arch/auto/XML/LibXSLT/LibXSLT.so | grep NEEDED
  NEEDED               libxslt.so.1
  NEEDED               libxml2.so.2
  NEEDED               libexslt.so.0
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6
  NEEDED               libperl.so.5.26

Do you see the difference? Do you see that except libc which is added by standard gcc spec NONE of the perllib libraries are used by this module?

(In reply to Tomasz Kłoczko from comment #14)
> As long 4 years ago it was not the same version of the perl module I've
> checked even old package by downloading from
> http://vault.centos.org/6.9/os/Source/SPackages/perl-XML-LibXSLT-1.70-1.1.
> el6.src.rpm affected package and there is no any traces of gdmb in source
> tree.
> 
> In Makefile.PL you can find line:
> 
> $config{LIBS}.=' '.$Config{perllibs};
> 
> Which adds use $Config{perllibs} not as you suggesting $Config{libs} !!!
> Did you had a look on this perl module code before replying that it use(s/d)
> $Config{libs} ???

You asked for a reason why in the past the module used -lgdbm. I gave you the reason based on the situation back in RHEL 6, as I remembered it. That was the technical reason.

Petr furthermore commented that Fedora has patched XML::LibXSLT, and you can see the patch here:

  http://pkgs.fedoraproject.org/rpms/perl-XML-LibXSLT/blob/master/f/XML-LibXSLT-1.95-Do-not-link-against-perl-extension-libraries.patch

If things have changed since the RHEL 6 days and -lgdbm has been removed from $Config{libs} / $Config{perllibs} in the mean time, I guess it makes sense under the consistency umbrella to remove the Requires form perl-devel as well.

[..]
> Petr furthermore commented that Fedora has patched XML::LibXSLT, and you can
> see the patch here:
> 
>  
> http://pkgs.fedoraproject.org/rpms/perl-XML-LibXSLT/blob/master/f/XML-
> LibXSLT-1.95-Do-not-link-against-perl-extension-libraries.patch
> 
> If things have changed since the RHEL 6 days and -lgdbm has been removed
> from $Config{libs} / $Config{perllibs} in the mean time, I guess it makes
> sense under the consistency umbrella to remove the Requires form perl-devel
> as well.

Thank you. Now I'm not sure who is able to make final decision :)
I see on https://admin.fedoraproject.org/pkgdb/package/rpms/perl/ that perl maintainer is Jitka Plesnikova.
Is she around or someone else can make decision about commintg my patch and commit it? (I have no admin access to perl .. should I request it to commit this patch?)

PS. Maybe I should not mention this old ticket on the beginning of this ticket but please understand on submitting my patch I've been trying to prove that I've traced original reason why those Requires lines has been added, that I understand those reasons and present as well that those manually added dependencies can be now removed :)

(In reply to Jan Pazdziora from comment #16)
> If things have changed since the RHEL 6 days and -lgdbm has been removed
> from $Config{libs} / $Config{perllibs} in the mean time,

That's not true and won't be for any foreseenable future. Changing the values is task for Perl authors, not Fedora or any other GNU/Linux distribution. Therefore I pointed Tomasz to upstream.

> I guess it makes sense under the consistency umbrella to remove the Requires
> form perl-devel as well.

The implication is fine. The problem what if we remove the dependency even if 
$Config{libs} contains -lgdbm. That's the root of the problem we talk about.

It's not a problem for me because in my opinion the variables are not supposed to be used for linking (non-core/any) Perl modules. But that was not your opinion. Therefore I raised the question to you.

If I understand you correctly, you has not changed you opinion.

My plan is to ask Perl authors for the $Config{libs} / $Config{perllibs} semantics, whether they are supposed to be used like XML-LibXSLT does. If I get negative or no answer, I will remove the dependency from perl-devel package.

(In reply to Petr Pisar from comment #18)
> 
> > I guess it makes sense under the consistency umbrella to remove the Requires
> > form perl-devel as well.
> 
> The implication is fine. The problem what if we remove the dependency even
> if 
> $Config{libs} contains -lgdbm. That's the root of the problem we talk about.
> 
> It's not a problem for me because in my opinion the variables are not
> supposed to be used for linking (non-core/any) Perl modules. But that was
> not your opinion. Therefore I raised the question to you.
> 
> If I understand you correctly, you has not changed you opinion.

I haven't changed my opinion WRT the consistency and no bad surprises for people who try to build modules. But of course, if the culprit was XML::LibXSLT's use of libs and perl-devel should be consistent with perllibs rather than libs, going with that would make sense.

> My plan is to ask Perl authors for the $Config{libs} / $Config{perllibs}
> semantics, whether they are supposed to be used like XML-LibXSLT does. If I
> get negative or no answer, I will remove the dependency from perl-devel
> package.

Thanks.

With the patch to perl-XML-LibXSLT that you did, perllibs will be used so from the

(In reply to Jan Pazdziora from comment #19)
> I haven't changed my opinion WRT the consistency and no bad surprises for
> people who try to build modules. But of course, if the culprit was
> XML::LibXSLT's use of libs and perl-devel should be consistent with perllibs
> rather than libs, going with that would make sense.

So .. for example now Fedora perl is replacing libbind by libresolve (perl-5.10.0-libresolv.patch).
Should I ask "why this libresolve change was not pushed back to perl source code?" or "why after many changes in perl code in mean time still this patch is maintained in Fedora?" :)

Because libswanted is present in $Config someone may use it as list of libraries to link perl module DSO. Someone may relay on some part  of libbind which are not common with libresolve. Isn't it?
It was calculated risk .. and this change IMO is OK because is fixing completely useless part of the dependencies. An I right? :)

Problem with perl development resources like $Config is that this variable have no well defined propose. In most cases it simple preserves what was detected during perl build.
Propose all those variables is store state of the build system on which perl is build. In other words $Config is not only extensions API interface.It preserves many things on which none of the extensions should rely.
Isn't it?

IMO none of the external perl modules should blindly use those perl build stages states to build own executable code like DSOs.
In mean time many people started using some bits only because full $Config is installed by perl install procedures.

Theoretically modules should rely only on libperl and when this library is shared form building/linking your own extensions should not be a problem.

On many system libperl is installed as static library and this makes things much more complicated to implement in perl extensions build frameworks.
Things are even more complicated because as you know the same code is used by many OSes.
If you need something line gethistbyname() you should check is this routine is on you system where you are building perl extension in libc or libnsl like it is on Solaris which is affection libs and perllibs on Linux. On some *BSDs many glibc libm routines are in system libc.
Problem is that perl modules build frameworks are very primitive. Mentioned here XML::LibXSLT uses for example additionally pkgconfig because standard perl framework would make checking availability of the devel resources of libxstl library quite hard (and of course it is nothing wrong with this).

I'm not trying to discover the wheel but only underline some exact context.

Again: problem is that perl provides not so sophisticated base frameworks to do such detection during perl extensions build time.
By this many extensions developers are using what they are able to use and by this they are using part of the $Config which are not been designed for such proposes as something like platform for such proposes. This "s*t already happened" ;) and people like you must deal with this :(

So current Fedora perl-5.10.0-libresolv.patch falsificates your statement about preserving some fixed level of the consistency or at last it makes not as strong as it was in your comment :)

Again: IMO best would be drop or even try to remove something like libs, libswanted or perllib variables from $Config as at least kind of experiment to identify/expose by experiment those perl modules which are relaying on what perl detected on own executables build stage or how widely those bits are used now.

However all above is completely off the scope of this ticket and does not need to be discussed here longer.
So guys please focus on the ticket  :)


Going back to the subject of this thicket:

gdbm-devel and libdb-devel can be removed NOW from Fedora perl-devel dependencies because original not patched perl source code is not using those libraries in $Config variables which could be used bu some extensions.
The same is with perl header files.

If some extensions are (still) using those libraries presence in $Config perl developers *already made the decision* that if someone will be expecting those libraries in $Config this is not ThePerlProblem(tm).

I posted this question to the upstream <http://www.nntp.perl.org/group/perl.perl5.porters/2017/08/msg245955.html>.

There was one upstream's answer that use the the values for linking XS modules is wrong. Therefore I'm removing the dependencies now.

Thank you for this discussion. It makes Fedora's Perl better.

Thank you :)