bug: configuration problem in perl with gcc libs

bug: configuration problem in perl with gcc libs

[Dmitry Karasik]

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.
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
@@ -4948,6 +4948,16 @@
 		   *) libpth="$libpth $j";;
 		   esac
 	       fi
+               # 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
 	    done
 	    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 libpath
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:

https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/master/share/portable/portable.perl.32#L60-L65

Hopefully this makes sense.

-- 
Sincerely,
	Dmitry Karasik


--
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

Re: bug: configuration problem in perl with gcc libs

[Ken Brown]

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

Re: bug: configuration problem in perl with gcc libs

[Achim Gratz]

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
that.
> 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
gcc version.
 
> I believe perl needs to be built with the properly set/found libpth in
advance.

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";;
>  		   esac
>  	       fi
> +               # 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
>  	    done
>  	    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
libpath
> 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.


Regards,
Achim.


--
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