From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23233 invoked by alias); 6 Jun 2016 07:47:58 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 23224 invoked by uid 89); 6 Jun 2016 07:47:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_05,FSL_HELO_BARE_IP_2,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=H*M:post, UD:eu.org, karasikeuorg, karasik.eu.org X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 06 Jun 2016 07:47:47 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1b9pGA-0007sE-JD for cygwin@cygwin.com; Mon, 06 Jun 2016 09:47:42 +0200 Received: from 217.10.52.10 ([217.10.52.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jun 2016 09:47:42 +0200 Received: from Stromeko by 217.10.52.10 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jun 2016 09:47:42 +0200 To: cygwin@cygwin.com From: Achim Gratz Subject: Re: bug: configuration problem in perl with gcc libs Date: Mon, 06 Jun 2016 07:47:00 -0000 Message-ID: References: <20160603161419.GA5300@karasik2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00051.txt.bz2 Dmitry Karasik 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 > -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: 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