pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/52561



The following reply was made to PR pkg/52561; it has been noted by GNATS.

From: Jonathan Perkin <jperkin%joyent.com@localhost>
To: Joern Clausen <joern.clausen%uni-bielefeld.de@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, solaris-pkg-people%NetBSD.org@localhost,
	gnats-admin%NetBSD.org@localhost, pkgsrc-bugs%NetBSD.org@localhost
Subject: Re: pkg/52561
Date: Fri, 11 May 2018 10:30:38 +0100

 * On 2018-05-11 at 10:00 BST, Jonathan Perkin wrote:
 
 > * On 2018-05-11 at 09:57 BST, Joern Clausen wrote:
 > 
 > > On 05/11/18 10:48, Jonathan Perkin wrote:
 > > > The only way a package does not build with cwrappers but does with
 > > > legacy wrappers is if something is incorrect with the package, and we
 > > > shouldn't hide bugs.
 > > 
 > > I totally agree. But more often than not when I report such a bug, nothing
 > > happens. I don't have enough expertise to dig into the make process or
 > > cwrapper to fix it myself, and those who do seem to look away as soon one of
 > > my tickets is labeled "Solaris issue".
 > 
 > Ok, let me see if I can make some time to look through these, and
 > document how I did them to aid others who want to help out.  It's
 > usually not too difficult, just takes time trawling through the build
 > process to see what's going on.
 
 I've committed a fix for the p5-Text-Iconv issue.  Here's how I went
 about it:
 
  * Reproduced the initial problem on SmartOS 64-bit.
 
  * Went into the work directory "cd $(bmake show-var VARNAME=WRKSRC)"
    and looked at ../.work.log to see what the last compile line was
    (the actual command is the one that starts "<.>", the one before it
    that starts "[*]" is the input to the wrappers).  Copy and pasted
    it to try and reproduce and get the exact error message, but
    linktest.c had been removed.
 
  * Grepped for linktest in the work area, found it in Makefile.PL
 
  * Edited Makefile.PL using pkgvi and commented out this line:
 
     unlink $file, "$file.c", "$file$obj_ext";
 
  * Went back to the pkgsrc directory with "cd -", re-ran bmake, went
    back again into the work area with another "cd -", got the compile
    line again from the end of .work.log and re-ran it, this time
    getting the actual error:
 
      ld: fatal: library -liconv: not found
 
    This is what I was expecting all along, but it's always good to
    double check.
 
  * Ok, so the link line is not getting the correct arguments to find
    pkgsrc libiconv, i.e. we're missing -L${PREFIX}/lib, we now need to
    find out why.
 
  * Looking through Makefile.PL we see the test is performed using the
    linktest() function, which takes the following arguments:
 
      sub linktest
      {
        my $libs = shift;
        my $incs = shift;
 
    and is called as
 
      linktest($config{LIBS}, $config{INC})
 
    These config{} vars are set in this loop around argv, the command
    line arguments to the Makefile.PL script:
 
      while ($i <= $#ARGV)
      {
         my ($key, $val) = split(/=/, $ARGV[$i], 2);
         $config{$key} = $val;     
 
    How do we call Makefile.PL?  Looking back at the pkgsrc Makefile we
    have this line:
 
      .include "../../lang/perl5/module.mk"
 
    and searching in that file for "Makefile.PL" we see:
 
      ${BUILDLINK_PREFIX.perl}/bin/perl Makefile.PL ${MAKE_PARAMS}
 
    Ok, so we need to pass LIBS and INC in using MAKE_PARAMS
 
  * The actual fix I used is:
 
    MAKE_PARAMS+=	INC="-I${BUILDLINK_PREFIX.iconv}/include"
    MAKE_PARAMS+=	LIBS="-L${BUILDLINK_PREFIX.iconv}/lib"
 
    The BUILDLINK_PREFIX.iconv variable points to the location where
    libiconv is installed, so for pkgsrc will be $PREFIX, and for OS
    where it is builtin it'll be /usr or similar.  This ensures that
    the correct paths are used across all OS.
 
  * Test everything with a 'bmake clean; bmake', it all now works and
    passes PKG_DEVELOPER=yes checks, so I'm happy to commit it.
 
 Hope that helps.  This one is probably a bit more difficult than most
 as it uses a custom build script, so requires the ability to read perl
 and be able to modify things to figure out what exactly is happening.
 
 Happy to explain further if any parts don't make sense.
 
 -- 
 Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com
 


Home | Main Index | Thread Index | Old Index