From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: bug: configuration problem in perl with gcc libs
Date: Sun, 05 Jun 2016 22:28:00 -0000 [thread overview]
Message-ID: <785ef8ef-4335-2d25-284e-6ece02fbd427@cornell.edu> (raw)
In-Reply-To: <20160603161419.GA5300@karasik2>
On 6/3/2016 12:14 PM, Dmitry Karasik wrote:
> Hello,
>
> I'd like to report a configuration bug in perl. The problem arises when a 3-rd
> party module tries to build an extension using perl configuration with a
> gcc-specific library.
>
> Generally perl extensions don't have a way to specify library to link with
> directly, they do that through ExtUtils::MakeMaker, the standard tool for that.
> Which in turn tries to resolve '-llibname' using its own
> compile-time-configured internal list of lib paths. Everything works so far
> libraries are found in perl's libpth (see by running 'perl -V:libpth') which is
> /usr/lib on my machine. The problem arises when I need to link together with
> libgomp, which is not found there, being a gcc-version-specific library.
>
> For example, the following minimal Makefile.PL configure script
>
> use ExtUtils::MakeMaker;
> WriteMakefile(NAME => 'foo', LIBS => '-lgomp');
>
> will emit a warning
>
> Warning (mostly harmless): No library found for -lgomp
>
> and removes -lgomp from the linker command, resulting in perl extension not
> being able to compile.
>
> The problem is confirmed, when, if I edit perl configuration file
> /usr/lib/perl5/5.22/i686-cygwin-threads-64int/Config.pm, everything works:
>
> ldlibpthname => 'PATH',
> - libpth => '/usr/lib',
> + libpth => '/usr/lib /usr/lib/gcc/i686-pc-cygwin/5.3.0',
> osname => 'cygwin',
>
> I believe perl needs to be built with the properly set/found libpth in advance.
I'm no perl expert, but this doesn't strike me as a good solution. It
means that a specific gcc version is hard-coded into perl.
It seems to me that the bug is in perl's algorithm (in
/usr/lib/perl5/5.22/ExtUtils/Liblist/Kid.pm) for finding libraries of
the form -lfoo. There's a special case for Cygwin at line 171 that
looks for foo.dll (if it hasn't found libfoo.dll.a), which is wrong for
two reasons. First, it should look for cygfoo*.dll instead (or in
addition). Second, it should look in the path, or at least in /usr/bin,
rather than in libpth.
In the present case of -lgomp, it would have found /usr/bin/cyggomp-1.dll.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2016-06-05 22:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 16:14 Dmitry Karasik
2016-06-05 22:28 ` Ken Brown [this message]
2016-06-06 7:47 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=785ef8ef-4335-2d25-284e-6ece02fbd427@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).