This is the mail archive of the
mailing list for the Cygwin project.
Re: bug: configuration problem in perl with gcc libs
- From: Achim Gratz <Stromeko at NexGo dot DE>
- To: cygwin at cygwin dot com
- Date: Mon, 6 Jun 2016 07:47:20 +0000 (UTC)
- Subject: Re: bug: configuration problem in perl with gcc libs
- Authentication-results: sourceware.org; auth=none
- References: <20160603161419 dot GA5300 at karasik2>
Dmitry Karasik <dmitry <at> karasik.eu.org> writes:
> 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
> Which in turn tries to resolve '-llibname' using its own
> compile-time-configured internal list of lib paths.
There are several parts in Perl that try nonsensical workarounds on Cygwin,
especially when the folks that implemented those workarounds apparently
haven't used Cygwin much. Reimplementing library search is one such folly,
since it doesn't make the linker and loader follow those "make it more
UNIX-like" ideas no matter how hard you try...
> 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',
This is the wrong thing to do. We don't want to tie Perl to some specific
> I believe perl needs to be built with the properly set/found libpth in
No, ExtUtils::MakeMaker shouldn't be trying to re-implement the library
search algorithm if it doesn't understand how its supposed to be working
(note that I don't claim to fully understand it myself). There are other
ways to check if linking to some library works. If it wouldn't remove the
library from the link line everything would work out just fine AFAICS.
Please report this as a bug against MakeMaker and perhaps drop a note on
p5p. I'll try to find some time to look at what MakeMaker is doing and why,
so it can be fixed properly. Could you please let me know what distribution
you were trying to build that triggers the problem?
> The diff below is the closest thing resembling a patch for the perl source
> package I could come with:
> --- Configure.0 2016-06-03 17:45:43.102008000 +0200
> +++ Configure 2016-06-03 17:46:10.077558700 +0200
> <at> <at> -4948,6 +4948,16 <at> <at>
> *) libpth="$libpth $j";;
> + # add gcc-specific libpath
> + if echo "$i" | grep -q "/usr/lib/gcc/"; then
> + j="`$echo $i|$sed 's,/include$,,'`"
> + if $test -d $j; then
> + case " $libpth " in
> + *" $j "*) ;;
> + *) libpth="$libpth $j";;
> + esac
> + fi
> + fi
> libpth="`$echo $libpth|$sed 's/^ //'`"
> for xxx in $libpth $loclibpth $plibpth $glibpth; do
> The idea for the patch is taken from strawberry perl, which has the gcc
> included in configuration. I couldn't find though exactly how they manage to
> include the path, during the configuration or when building, but it seems they
> somehow add it explicitly, using a custom tool for the MinGW perl build:
I doubt this is the correct thing to do for Strawberry Perl (but I have no
in-depth knowledge of MinGW), but as said above it's certainly the wrong
thing to do on Cygwin.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple