Bug #69318 for ExtUtils-MakeMaker: EU:MM rejects necessary link library

Wed Jul 06 13:36:03 2011 zefram [...] fysh.org - Ticket created

Subject:	EU:MM rejects necessary link library
Date:	Wed, 6 Jul 2011 18:35:43 +0100
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Zefram <zefram [...] fysh.org>

Message body is not shown because it is too large.

Fri Jul 29 11:40:29 2011 perlbug-followup [...] perl.org - Ticket #69891: Ticket created

CC:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
Subject:	[perl #95884] ExtUtils::MakeMaker removes valid libraries from LIBS on debian
Date:	Fri, 29 Jul 2011 08:40:20 -0700
To:	"OtherRecipients of perl Ticket #95884":;
From:	"Father Chrysostomos via RT" <perlbug-followup [...] perl.org>

Forwarding to the CPAN RT queue.... On Fri Jul 29 02:21:46 2011, schmorp@schmorp.de wrote: Show quoted text

> > This is a bug report for perl from schmorp@schmorp.de, > generated with the help of perlbug 1.39 running under perl 5.12.3. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > ExtUtils::MakeMaker removes valid libraries from LIBS, e.g.: > > LIBS => ["-lpthread -ldb"] > > results in: > > Note (probably harmless): No library found for -ldb > > Even though the library is installed in the configured compiler search > path. > > This seems to happen due to multiarch support, i.e. gcc(ld) looks into > /usr/lib/x86_64-linux-gnu, but perl does not because it doesn't know > about > the real library path. > > The suggested fix would be to use the compiler to try to link against > the library to see if it's there (as opposed to yet another layer of > comaptibility hacking :)) > > [Please do not change anything below this line] > ----------------------------------------------------------------- > --- > Flags: > category=library > severity=low > module=ExtUtils::Liblist::Kid > --- > Site configuration information for perl 5.12.3: > > Configured by Marc Lehmann at Wed Feb 23 06:21:02 CET 2011. > > Summary of my perl5 (revision 5 version 12 subversion 3) > configuration: > > Platform: > osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux > uname='linux cerebro 2.6.32-5-amd64 #1 smp wed jan 12 03:40:32 utc > 2011 x86_64 gnulinux ' > config_args='-Duselargefiles -Duse64bitint -Dusemymalloc=n > -Dstatic_ext=Fcntl -Dcc=gcc -Dccflags=-DPERL_DISABLE_PMC > -DPERL_ARENA_SIZE=16376 -USITEARCH_EXP -USITELIB_EXP -UARCHLIB_EXP > -D_GNU_SOURCE -I/opt/include -ggdb -gdwarf-2 -g3 -Doptimize=-O6 > -fno-strict-aliasing -Dcccdlflags=-fPIC -Dldflags=-L/opt/perl/lib > -L/opt/lib -Dlibs=-ldl -lm -lcrypt -lgdbm -Dprefix=/opt/perl > -Dprivlib=/opt/perl/lib/perl5 -Darchlib=/opt/perl/lib/perl5 > -Uusevendorprefix -Dsiteprefix=/opt/perl > -Dsitelib=/opt/perl/lib/perl5 -Dsitearch=/opt/perl/lib/perl5 > -Dsitebin=/opt/perl/bin -Dman1dir=/opt/perl/man/man1 > -Dman3dir=/opt/perl/man/man3 -Dsiteman1dir=/opt/perl/man/man1 > -Dsiteman3dir=/opt/perl/man/man3 -Dman1ext=1 -Dman3ext=3 > -Dpager=/usr/bin/less -Uafs -Uusesfio -Uusenm -Uuseshrplib > -Ud_dosuid -Dusethreads=undef -Duse5005threads=undef > -Duseithreads=undef -Dusemultiplicity=undef > -Demail=perl-binary@plan9.de -Dcf_email=perl-binary@plan9.de > -Dcf_by=Marc Lehmann -Dlocincpth=/opt/perl/include /opt/include > -Dmyhostname=localhost -Dmultiarch=undef -Dbin=/opt/perl/bin > -Dxxxusedevel -DxxxDEBUGGING -Dxxxuse_debugging_perl > -Dxxxuse_debugmalloc -dEs' > hint=recommended, useposix=true, d_sigaction=define > useithreads=undef, usemultiplicity=undef > useperlio=define, d_sfio=undef, uselargefiles=define, > usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='gcc', ccflags ='-DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 > -USITEARCH_EXP -USITELIB_EXP -UARCHLIB_EXP -D_GNU_SOURCE > -I/opt/include -ggdb -gdwarf-2 -g3 -fno-strict-aliasing -pipe > -I/opt/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', > optimize='-O6 -fno-strict-aliasing', > cppflags='-DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 > -USITEARCH_EXP -USITELIB_EXP -UARCHLIB_EXP -D_GNU_SOURCE > -I/opt/include -ggdb -gdwarf-2 -g3 -fno-strict-aliasing -pipe > -I/opt/include' > ccversion='', gccversion='4.4.5', gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, > longdblsize=16 > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='gcc', ldflags ='-L/opt/perl/lib -L/opt/lib -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 > libs=-ldl -lm -lcrypt -lgdbm > perllibs=-ldl -lm -lcrypt > libc=/lib/libc-2.11.2.so, so=so, useshrplib=false, > libperl=libperl.a > gnulibc_version='2.11.2' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' > cccdlflags='-fPIC', lddlflags='-shared -O6 -fno-strict-aliasing > -L/opt/perl/lib -L/opt/lib -L/usr/local/lib' > > Locally applied patches: > > > --- > @INC for perl 5.12.3: > /root/src/sex > /opt/perl/lib/perl5 > /opt/perl/lib/perl5 > . > > --- > Environment for perl 5.12.3: > HOME=/root > LANG (unset) > LANGUAGE (unset) > LC_CTYPE=en_US.UTF-8 > LD_LIBRARY_PATH (unset) > LOGDIR (unset) >

PATH=/root/s2:/root/s:/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/root/pserv:. Show quoted text

> PERL5LIB=/root/src/sex > PERL5_CPANPLUS_CONFIG=/root/.cpanplus/config > PERLDB_OPTS=ornaments=0 > PERL_ANYEVENT_DBI_TESTS=1 > PERL_ANYEVENT_EDNS0=1 > PERL_ANYEVENT_NET_TESTS=1 > PERL_ANYEVENT_PROTOCOLS=ipv4,ipv6 > PERL_ANYEVENT_STRICT=1 > PERL_BADLANG (unset) > PERL_UNICODE=E > SHELL=/bin/bash

Tue Aug 02 09:24:52 2011 perlbug-comment [...] perl.org - Ticket #69891: Correspondence added

CC:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
Subject:	[perl #95884] [rt.cpan.org #69891] ExtUtils::MakeMaker removes valid libraries from LIBS on debian
Date:	Tue, 02 Aug 2011 06:24:40 -0700
To:	"OtherRecipients of perl Ticket #95884":;
From:	"Father Chrysostomos via RT" <perlbug-comment [...] perl.org>

On Tue Aug 02 05:55:16 2011, doughera wrote: Show quoted text

> On Fri, 29 Jul 2011, schmorp @ schmorp . de wrote: >

> > # New Ticket Created by schmorp@schmorp.de > > # Please include the string: [perl #95884] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=95884 > > > > > This is a bug report for perl from schmorp@schmorp.de, > > generated with the help of perlbug 1.39 running under perl 5.12.3. > > > > > > ----------------------------------------------------------------- > > [Please describe your issue here] > > > > ExtUtils::MakeMaker removes valid libraries from LIBS, e.g.: > > > > LIBS => ["-lpthread -ldb"] > > > > results in: > > > > Note (probably harmless): No library found for -ldb > > > > Even though the library is installed in the configured compiler

> search path.

> > > > This seems to happen due to multiarch support, i.e. gcc(ld) looks

> into

> > /usr/lib/x86_64-linux-gnu, but perl does not because it doesn't know

> about

> > the real library path. > > > > The suggested fix would be to use the compiler to try to link

> against

> > the library to see if it's there (as opposed to yet another layer of > > comaptibility hacking :))

> > Thanks for the report and the concise diagnosis. > > This should already be fixed in version 5.12.4. The manual workaround > is > to hand-edit the "libpth" entries in $archlib/Config.pm and > $archlib/Config_heavy.pl to include the correct directories for your > system. >

Tue Aug 02 09:24:54 2011 The RT System itself - Ticket #69891: Status changed from 'new' to 'open'

Sun Sep 25 01:15:04 2011 mschwern [...] cpan.org - Ticket #69891: Merged into ticket #69318

Sun Sep 25 01:15:04 2011 mschwern [...] cpan.org - Merged into ticket #69318

Sun Sep 25 01:16:03 2011 mschwern [...] cpan.org - Correspondence added

No idea what to do about this. That whole subsystem is inscrutable to me. Any ideas?

Sun Sep 25 01:16:05 2011 The RT System itself - Status changed from 'new' to 'open'

Mon Sep 26 06:27:02 2011 fawaka [...] gmail.com - Correspondence added

CC:	perlbug-followup [...] perl.org, zefram [...] fysh.org
Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Mon, 26 Sep 2011 12:26:54 +0200
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Leon Timmermans <fawaka [...] gmail.com>

On Sun, Sep 25, 2011 at 7:16 AM, Michael G Schwern via RT <bug-ExtUtils-MakeMaker@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=69318 > > > No idea what to do about this. That whole subsystem is inscrutable to > me. Any ideas?

I think MakeMaker needs to use $Config{plibpth} instead of or in addition to $Config{libpth} when it checks the availability of certain libraries. Leon

Mon Sep 26 06:45:56 2011 MITHALDU [...] cpan.org - Correspondence added

On Sun Sep 25 01:16:03 2011, MSCHWERN wrote: Show quoted text

> No idea what to do about this. That whole subsystem is inscrutable to > me. Any ideas?

Which subsystem? Liblist? What it does, in short, is this: 1. take the list of linker parameters provided by Makefile.PL 2. try to resolve that list, by going through it and looking for each library mentioned in it, including the directory parameters and what not 2. a) if the lib is found, append that directive to a new linker parameter string 2. b) if the lib is not found, warn and skip 3. pass the new linker parameter string to the compiler As schmorp rightly says, that's actually a bit stupid. Due to EUMM emulating the compiler actions, there's potential for both false positives (when eumm can find the lib, but compiler can't) and false negatives (when eumm can't find the lib and removes it from the list, but the compiler could). So, the optimum way of handling this would be to actually use the compiler itself to verify the lib list, but i personally have no idea how that could be done. Meanwhile, an option is: Debug through Liblist, figure out why it can't find that lib, and change the code so it can find it. Or maybe change it so it just warns, but adds the directive anyhow.

Tue Sep 27 22:10:56 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Tue, 27 Sep 2011 19:10:44 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.9.26 3:45 AM, Christian Walde via RT wrote: Show quoted text

> As schmorp rightly says, that's actually a bit stupid. Due to EUMM > emulating the compiler actions, there's potential for both false > positives (when eumm can find the lib, but compiler can't) and false > negatives (when eumm can't find the lib and removes it from the list, > but the compiler could). > > So, the optimum way of handling this would be to actually use the > compiler itself to verify the lib list, but i personally have no idea > how that could be done.

I think the general way to accomplish that is to just try to compile a small program. Isn't that what Configure does? I wonder if delegating to ExtUtils::CBuilder would be sufficient. I'd love to see all that nasty Liblist code go away. Alternatively... do we need to go through that process at all? Why is MakeMaker taking responsibility for pruning the library list? Why not just let the compiler/linker handle it? I suspect the answer might have originally been "to produce a friendlier error message" but it seems to me not worth all the trouble and bugs. Christian, I think of anyone you know Liblist the most. Or if nothing else you're brave enough to mess with it. What do you think? Show quoted text

> Meanwhile, an option is: Debug through Liblist, figure out why it can't > find that lib, and change the code so it can find it. Or maybe change > it so it just warns, but adds the directive anyhow.

That seems to be the usual way. -- We do what we must because we can. For the good of all of us, Except the ones who are dead. -- Jonathan Coulton, "Still Alive"

Wed Sep 28 05:56:28 2011 MITHALDU [...] cpan.org - Correspondence added

Weird, RT didn't mail me your last reply. Anyhow: Note ahead: I know almost nothing about C. It's been almost a decade since i last wrote a C program. Show quoted text

> I think the general way to accomplish that is to just try to compile a > small program. Isn't that what Configure does?

No idea. Completely outside of my expertise. Show quoted text

> I wonder if delegating to ExtUtils::CBuilder would be sufficient. I'd > love to see all that nasty Liblist code go away.

Again, I have no idea and do not know the module. Though, casual looking reveals: "However, it is not intended as a general cross-platform interface to all your C building needs." Show quoted text

> Alternatively... do we need to go through that process at all?

Good question! Why indeed. I personally have no clue why that is necessary. I can only guess at it being meant to make it possible for authors to indicate multiple libraries with EUMM choosing the one that actually exists. But that's a wild guess. Show quoted text

> Christian, I think of anyone you know Liblist the most. Or if nothing > else you're brave enough to mess with it. What do you think?

I can, by virtue of perl -d, understand what it does. Sadly this does not mean i know why it does that. Even the initial commit in the git repo on the 16th january of 2002 only says: Show quoted text

> ExtUtils::Liblist - determine libraries to use and how to use them > > This utility takes a list of libraries in the form C<-llib1 -llib2 > -llib3> and returns lines suitable for inclusion in an extension > Makefile.

But does not qualify why it does so. What I'm thinking right now is that first of all we need to find the why of the matter. Only then can an informed decision be made.

Wed Sep 28 07:04:26 2011 nick [...] ccl4.org - Correspondence added

CC:	perlbug-followup [...] perl.org, zefram [...] fysh.org
Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Wed, 28 Sep 2011 12:04:17 +0100
To:	Christian Walde via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
From:	Nicholas Clark <nick [...] ccl4.org>

On Wed, Sep 28, 2011 at 05:56:30AM -0400, Christian Walde via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=69318 > > > Weird, RT didn't mail me your last reply. Anyhow: > > Note ahead: I know almost nothing about C. It's been almost a decade > since i last wrote a C program. >

> > I think the general way to accomplish that is to just try to compile a > > small program. Isn't that what Configure does?

> > No idea. Completely outside of my expertise. >

> > I wonder if delegating to ExtUtils::CBuilder would be sufficient. I'd > > love to see all that nasty Liblist code go away.

> > Again, I have no idea and do not know the module. Though, casual > looking reveals: > > "However, it is not intended as a general cross-platform interface to > all your C building needs." >

> > Alternatively... do we need to go through that process at all?

> > Good question! Why indeed. I personally have no clue why that is > necessary. I can only guess at it being meant to make it possible for > authors to indicate multiple libraries with EUMM choosing the one that > actually exists. > > But that's a wild guess.

Which corresponds to the actual documentation: =item LIBS An anonymous array of alternative library specifications to be searched for (in order) until at least one library is found. E.g. 'LIBS' => ["-lgdbm", "-ldbm -lfoo", "-L/path -ldbm.nfs"] Mind, that any element of the array contains a complete set of arguments for the ld command. So do not specify 'LIBS' => ["-ltcl", "-ltk", "-lX11"] See ODBM_File/Makefile.PL for an example, where an array is needed. If you specify a scalar as in 'LIBS' => "-ltcl -ltk -lX11" MakeMaker will turn it into an array with one element. =cut Nicholas Clark

Wed Sep 28 23:30:31 2011 schwern [...] pobox.com - Correspondence added

CC:	"H.Merijn Brand" <h.m.brand [...] xs4all.nl>
Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Wed, 28 Sep 2011 20:30:19 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.9.28 4:04 AM, Nicholas Clark via RT wrote: Show quoted text

> On Wed, Sep 28, 2011 at 05:56:30AM -0400, Christian Walde via RT wrote:

>> Good question! Why indeed. I personally have no clue why that is >> necessary. I can only guess at it being meant to make it possible for >> authors to indicate multiple libraries with EUMM choosing the one that >> actually exists. >> >> But that's a wild guess.

> > Which corresponds to the actual documentation: > > =item LIBS > > An anonymous array of alternative library > specifications to be searched for (in order) until > at least one library is found. E.g. > > 'LIBS' => ["-lgdbm", "-ldbm -lfoo", "-L/path -ldbm.nfs"]

I'm going to propose that only a very, very small subset of modules need that functionality. I'm also going to propose that it would be far simpler and more robust to compile a small program with each flag. Somebody that knows Configure could help with this, maybe Merijn could help. ExtUtils::CBuilder would come into play here to do the compiling and linking. If we go down that route, I'd propose leaving LIBS as a legacy interface for backwards compatibility. It will still search for working libraries, but it would use CBuilder instead of Liblist (a goal being to delete Liblist). We'd then create a second key for "just use these libraries" and perhaps provide a method which can do the searching.

Thu Sep 29 05:26:28 2011 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Thu, 29 Sep 2011 10:26:08 +0100
To:	Michael G Schwern via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

Michael G Schwern via RT wrote: Show quoted text

> ExtUtils::CBuilder would come into >play here to do the compiling and linking.

EU:CB is poor on this aspect of linking. See, for example, the gyrations that I go through with Devel::CallChecker and Scope::Escape::Sugar, where the latter imports functions from the former. (This because I use Module::Build, which uses EU:CB.) Having got this to work with chewing gum and baling wire, the next step, which I haven't yet attempted, is to build good interfaces for this into EU:CB and M:B. -zefram

Thu Sep 29 06:14:21 2011 fawaka [...] gmail.com - Correspondence added

CC:	perlbug-followup [...] perl.org, zefram [...] fysh.org
Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Thu, 29 Sep 2011 12:14:13 +0200
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Leon Timmermans <fawaka [...] gmail.com>

On Thu, Sep 29, 2011 at 5:30 AM, Michael G Schwern via RT <bug-ExtUtils-MakeMaker@rt.cpan.org> wrote: Show quoted text

> ExtUtils::CBuilder would come into > play here to do the compiling and linking. > > If we go down that route, I'd propose leaving LIBS as a legacy interface for > backwards compatibility. It will still search for working libraries, but it > would use CBuilder instead of Liblist (a goal being to delete Liblist). We'd > then create a second key for "just use these libraries" and perhaps provide a > method which can do the searching.

I'm not so sure ExtUtils::CBuilder really is in a better shape than ExtUtils;:MakeMaker, specially on Windows. Leon

Thu Sep 29 17:34:59 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Thu, 29 Sep 2011 14:34:45 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.9.29 2:26 AM, Zefram via RT wrote: Show quoted text

> EU:CB is poor on this aspect of linking. See, for example, the gyrations > that I go through with Devel::CallChecker and Scope::Escape::Sugar, > where the latter imports functions from the former. (This because I use > Module::Build, which uses EU:CB.) Having got this to work with chewing > gum and baling wire, the next step, which I haven't yet attempted, > is to build good interfaces for this into EU:CB and M:B.

You're absolutely correct that CBuilder will not be able to do things MakeMaker can. And vice versa. I imagine plotting CBuilder and MakeMaker's respective strengths/weaknesses/bugs would make an interesting Venn diagram. Building that diagram isn't necessary right now, but it will be very necessary later. Now, if I'm wrong and CBuilder fundamentally can't do what MakeMaker does, apples and oranges, that's a different matter and should be brought to immediately. I would rather transplant MakeMaker knowledge into CBuilder for others to benefit from than to continue to patch MakeMaker's mess that nobody else can use or understand or test. [1] CBuilder is a separate package which has an interface and is in active use. Internals can be fixed. That's progressing Perl, not just running to stay in the same place. [1] This is the point where somebody will point out that on odd Thursdays while sacrificing the third born of a rooster that crows backwards, you can use MakeMaker's compiler code in other libraries. Great.

Fri Sep 30 09:31:45 2011 fawaka [...] gmail.com - Correspondence added

CC:	perlbug-followup [...] perl.org, zefram [...] fysh.org
Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Fri, 30 Sep 2011 15:31:36 +0200
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Leon Timmermans <fawaka [...] gmail.com>

On Thu, Sep 29, 2011 at 11:35 PM, Michael G Schwern via RT <bug-ExtUtils-MakeMaker@rt.cpan.org> wrote: Show quoted text

> You're absolutely correct that CBuilder will not be able to do things > MakeMaker can. And vice versa. I imagine plotting CBuilder and MakeMaker's > respective strengths/weaknesses/bugs would make an interesting Venn diagram. > Building that diagram isn't necessary right now, but it will be very necessary > later. > > Now, if I'm wrong and CBuilder fundamentally can't do what MakeMaker does, > apples and oranges, that's a different matter and should be brought to > immediately.

EU::CB is barely maintained within its current limited featureset. There's no reason it can't be extended, but the right people with the right knowledge (e.g. a Windows linking expert would be most welcome to clean up the mess we have right now) have to be available. Leon

Fri Sep 30 21:53:14 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #69318] EU:MM rejects necessary link library
Date:	Fri, 30 Sep 2011 18:53:00 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.9.30 6:31 AM, Leon Timmermans via RT wrote: Show quoted text

> EU::CB is barely maintained within its current limited featureset. > There's no reason it can't be extended, but the right people with the > right knowledge (e.g. a Windows linking expert would be most welcome > to clean up the mess we have right now) have to be available.

Acceptable. Sounds about the same as MakeMaker. Better, there's no "MakeMaker" to worry about. :)

Tue Dec 20 09:03:03 2011 cavac [...] cavac.at - Correspondence added

On Fri Jul 29 11:40:29 2011, perlbug-followup@perl.org wrote: Show quoted text

> > This seems to happen due to multiarch support, i.e. gcc(ld) looks

> into

> > /usr/lib/x86_64-linux-gnu, but perl does not because it doesn't know > > about > > the real library path.

Here's a temporary workaround (globally disabling the checks in MakeMaker). So, find the file Kid.pm in */lib/ExtUtils/Liblist and find the following lines (somewhere around line 170 in my MakeMaker version): 1 } 2 else { 3 warn "$thislib not found in $thispth\n" if $verbose; 4 next; 5 } 6 warn "'-l$thislib' found at $fullname\n" if $verbose; 7 push @libs, $fullname unless $libs_seen{$fullname}++; 8 $found++; 9 $found_lib++; 10 We'll disabling using the "results" of this checks, just comment out four lines: 1 } 2 else { 3 #warn "$thislib not found in $thispth\n" if $verbose; 4 #next; 5 } 6 #warn "'-l$thislib' found at $fullname\n" if $verbose; 7 #push @libs, $fullname unless $libs_seen{$fullname}++; 8 $found++; 9 $found_lib++; 10 11 # Now update library lists Of course, a nicer workaround is checking for an environment variable: 1 } 2 else { 3 if(!defined($ENV{MM_DISABLE_LIBCHECKS}) || $ENV{MM_DISABLE_LIBCHECKS} == 0) { 4 warn "$thislib not found in $thispth\n" if $verbose; 5 next; 6 } 7 } 8 if(!defined($ENV{MM_DISABLE_LIBCHECKS}) || $ENV{MM_DISABLE_LIBCHECKS} == 0) { 9 warn "'-l$thislib' found at $fullname\n" if $verbose; 10 push @libs, $fullname unless $libs_seen{$fullname}++; 11 } 12 $found++; 13 $found_lib++; 14 15 # Now update library lists Now, you can overide failing library checks by setting the environment variable MM_DISABLE_LIBCHECKS to a non-zero value, for example: MM_DISABLE_LIBCHECKS=1 perl Makefile.PL This should do it. Since (most) Makefile.PL's use checks with "pkg- config" in addition to internal MakeMaker checks anyway, you should still see all missing dependencies from your operating system. Tested this with Gtk3, Gtk3::WebKit and their dependencies. It's not quite nice and sometimes needs reading gcc errors to find missing dependencies - but it basically works.

Wed Apr 25 07:42:14 2012 lxp [...] cpan.org - Reference by ticket #76753 added