This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug: configuration problem in perl with gcc libs


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]