From @ppisar

Hello,

I got a report <https://bugzilla.redhat.com/show_bug.cgi?id=1666033#c2> that
when ExtUtils​::Emebd​::ldopts is used for linking a Perl interpreter to an
application, the application is linked to irrelevant libraries (-lresolv -ldl
-lm -lcrypt -lutil -lc)​:

$ perl -MExtUtils​::Embed -e ldopts
-Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil -lc

That's because ExtUtils​::Embed adds $Config{perllibs} to ldopts​:

$ perl -MConfig -e 'print qq{$Config{perllibs}\n}'
-lpthread -lresolv -ldl -lm -lcrypt -lutil -lc

and perllibs is documented as​:

  The list of libraries needed by Perl only (any libraries needed by
  extensions only will by dropped, if using dynamic loading).

The perllibs documentation is not clear (as always) whether the flags are for
linking with Perl or linking the Perl.

The perllibs value suggests its for linking the Perl.

ExtUtils​::Embed documents ldopts like this​:

  Output arguments for linking the Perl library and extensions to your
  application.

I conclude that either ExtUtils​::Embed should not use $Config{perllibs} or
Config should omit the flags from perllibs in case Perl is built dynamically.

Which of the two (Config or ExtUtils​::Embed) is wrong?

-- Petr

PS​: I wanted to report it to CPAN's RT, but ExtUtils-Embed seems not be
abandoned there.

From @jkeenan

On Tue, 15 Jan 2019 06​:56​:50 GMT, ppisar wrote​:

-- Petr

PS​: I wanted to report it to CPAN's RT, but ExtUtils-Embed seems not
be
abandoned there.

It won't have an upstream bugtracker because it's maintained in blead (i.e., by Perl 5 Porters) under the lib/ directory. So this is the correct place to report the problem.

--
James E Keenan (jkeenan@​cpan.org)

The RT System itself - Status changed from 'new' to 'open'

From @Leont

On Tue, Jan 15, 2019 at 7​:57 AM Petr Pisar (via RT)
<perlbug-followup@​perl.org> wrote​:

Hello,

I got a report <https://bugzilla.redhat.com/show_bug.cgi?id=1666033#c2> that
when ExtUtils​::Emebd​::ldopts is used for linking a Perl interpreter to an
application, the application is linked to irrelevant libraries (-lresolv -ldl
-lm -lcrypt -lutil -lc)​:

$ perl -MExtUtils​::Embed -e ldopts
-Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil -lc

That's because ExtUtils​::Embed adds $Config{perllibs} to ldopts​:

$ perl -MConfig -e 'print qq{$Config{perllibs}\n}'
-lpthread -lresolv -ldl -lm -lcrypt -lutil -lc

and perllibs is documented as​:

The list of libraries needed by Perl only \(any libraries needed by
extensions only will by dropped\, if using dynamic loading\)\.

The perllibs documentation is not clear (as always) whether the flags are for
linking with Perl or linking the Perl.

The perllibs value suggests its for linking the Perl.

ExtUtils​::Embed documents ldopts like this​:

Output arguments for linking the Perl library and extensions to your
application\.

I conclude that either ExtUtils​::Embed should not use $Config{perllibs} or
Config should omit the flags from perllibs in case Perl is built dynamically.

Which of the two (Config or ExtUtils​::Embed) is wrong?

-- Petr

PS​: I wanted to report it to CPAN's RT, but ExtUtils-Embed seems not be
abandoned there.

The logic makes sense and is correct on the 1996 operating systems it
was written for. This was before unices all around switched from
various variations of COFF to ELF (except AIX, which stubbornly holds
out on XCOFF).

You're correct to observe it is not necessary when doing shared
linking to libperl on most ELF based platforms. It is always necessary
when statically linking libperl (which is the default, but not how
most vendors build it for obvious reasons).

So it's not entirely broken, it just needs to be smarter.

Leon