NetBSD Problem Report #52561

From www@NetBSD.org  Wed Sep 20 07:00:27 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 45C1A7A1FC
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 20 Sep 2017 07:00:27 +0000 (UTC)
Message-Id: <20170920070026.76ABF7A287@mollari.NetBSD.org>
Date: Wed, 20 Sep 2017 07:00:26 +0000 (UTC)
From: joern.clausen@uni-bielefeld.de
Reply-To: joern.clausen@uni-bielefeld.de
To: gnats-bugs@NetBSD.org
Subject: devel/npth broken
X-Send-Pr-Version: www-1.0

>Number:         52561
>Category:       pkg
>Synopsis:       devel/npth broken
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    solaris-pkg-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 20 07:05:00 +0000 2017
>Last-Modified:  Fri May 11 10:00:02 +0000 2018
>Originator:     Joern Clausen
>Release:        
>Organization:
University of Bielefeld
>Environment:
>Description:
This is a replacement for pkg/52550, which has a wrong subject and is assigned to the wrong person.

After installing devel/npth, npth-config is unusable:

$ npth-config --version
/opt/pkg-hrz/20170814/bin/npth-config: line 43: syntax error at line 92: `newline' unexpected

I see this behavior both on NetBSD 7.0.1/amd64 and Solaris 11.3/i86.

After "make configure", a working script is generated, after "make", this script is broken in this fashion:

 --- npth-config.ok      2017-09-19 14:44:24.000000000 +0200
 +++ npth-config 2017-09-19 14:44:27.000000000 +0200
 @@ -87,7 +87,7 @@
               for i in $cflags ; do
                 skip=no
                 case $i in
 -                  -I/usr/include|-I/include)
 +
                         skip=yes
                         ;;
                     -I*)
 @@ -110,7 +110,7 @@
               for i in $libs ; do
                 skip=no
                 case $i in
 -                  -L/usr/lib|-L/lib)
 +
                         skip=yes
                         ;;
                     -L*|-l*)
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Wed, 20 Sep 2017 10:09:13 +0200

 On Wed, Sep 20, 2017 at 07:05:00AM +0000, joern.clausen@uni-bielefeld.de wrote:
 > After installing devel/npth, npth-config is unusable:
 > 
 > $ npth-config --version
 > /opt/pkg-hrz/20170814/bin/npth-config: line 43: syntax error at line 92: `newline' unexpected
 > 
 > I see this behavior both on NetBSD 7.0.1/amd64 and Solaris 11.3/i86.

 Works for me on NetBSD-8.99.2/amd64.

 > After "make configure", a working script is generated, after "make", this script is broken in this fashion:
 > 
 >  --- npth-config.ok      2017-09-19 14:44:24.000000000 +0200
 >  +++ npth-config 2017-09-19 14:44:27.000000000 +0200
 >  @@ -87,7 +87,7 @@
 >                for i in $cflags ; do
 >                  skip=no
 >                  case $i in
 >  -                  -I/usr/include|-I/include)
 >  +
 >                          skip=yes
 >                          ;;
 >                      -I*)
 >  @@ -110,7 +110,7 @@
 >                for i in $libs ; do
 >                  skip=no
 >                  case $i in
 >  -                  -L/usr/lib|-L/lib)
 >  +
 >                          skip=yes
 >                          ;;
 >                      -L*|-l*)

 Reverse diffs make understanding harder :)

 The npth-config installed by npth-1.5 on 8.99.2/amd64 has the "ok"
 lines already inside. Even the npth-config.in file coming with the
 distribution has them.

 Please find out why/how they are broken for you.

 Thanks,
  Thomas

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org, pkg-manager@NetBSD.org, gnats-admin@NetBSD.org,
 pkgsrc-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Wed, 20 Sep 2017 10:20:51 +0200

 >  Reverse diffs make understanding harder :)

 Awww, I trust you manage to understand it...

 >  The npth-config installed by npth-1.5 on 8.99.2/amd64 has the "ok"
 >  lines already inside. Even the npth-config.in file coming with the
 >  distribution has them.

 That's not a contradiction to what I said: The .in file is okay, the 
 generated script is at first okay, but pkgsrc mangles it in the last 
 step. I failed to transfer the info from the other PR, that building 
 npth outside pkgsrc does not show this problem. For me this is clearly a 
 pkgsrc problem.

 >  Please find out why/how they are broken for you.

 If I knew where this came from, I would have mentioned it and opened a 
 different PR. I don't understand what pkgsrc is doing to this file 
 enough to debug this problem.

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Wed, 20 Sep 2017 10:27:33 +0200

 There is no mangling breakage happening for me.

 What's your PREFIX?
  Thomas

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Wed, 20 Sep 2017 10:31:34 +0200

 To get on with building my packages, I fixed npth-config inplace. Now 
 gpgme-config from security/gpgme shows exactly the same failure:

                case $i in

                        skip=yes
                        ;;

 instead of

                case $i in
                    -I/usr/include|-I/include)
                        skip=yes
                        ;;


 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Wed, 20 Sep 2017 10:34:49 +0200

 >  What's your PREFIX?

 On NetBSD, everything is where it should be: Sources are in /usr/pkgsrc, 
 PREFIX is /usr/pkg

 On Solaris, PREFIX is /opt/pkg-hrz/20170814.

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Fri, 22 Sep 2017 13:19:19 +0200

 One more piece: I tried it on a machine running NetBSD 7.1/amd64, and 
 there npth-config was installed okay.

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Mon, 25 Sep 2017 05:02:38 +0000

 On Fri, Sep 22, 2017 at 11:20:00AM +0000, J?rn Clausen wrote:
  > [very bizarre behavior]

 First thought: try MAKE_JOBS_SAFE=no. Thanks to the wonders of
 automake the makefile is about 20x the size of the build log... and it
 includes rules that affect npth-config... and automake output is
 frequently not jobs-safe.

 Second thought: check for clock skew or other things that might
 confuse make into running rules it shouldn't.

 Third: the build log with one job is only a couple screenfuls long, so
 inspecting it for things that oughtn't to be there, like rerunning
 configure or config.status, isn't a big task.

 And, if you run out of other ideas, try running the whole thing (or
 rather, the smallest separable part of the build that exhibits the
 failure) under ktrace, that is,

    make clean
    make configure
    ktrace -i -t+a make
    kdump | less

 The dump file will be full of crap but it should reveal what's editing
 the script, and that plus the build log ought to allow figuring out
 what happened.

 -- 
 David A. Holland
 dholland@netbsd.org

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Mon, 25 Sep 2017 09:48:32 +0200

 >  First thought: try MAKE_JOBS_SAFE=no.

 Nope, no change.

 >  Second thought: check for clock skew or other things that might
 >  confuse make into running rules it shouldn't.

 No, I think I can rule that out.

 >  Third: the build log with one job is only a couple screenfuls long, so
 >  inspecting it for things that oughtn't to be there, like rerunning
 >  configure or config.status, isn't a big task.

 Of course I have done that, and I don't see anything. I have appended 
 the full output between "make configure" (script okay) and "make" 
 (script broken) below.

 >  And, if you run out of other ideas, try running the whole thing (or
 >  rather, the smallest separable part of the build that exhibits the
 >  failure) under ktrace, that is,
 >
 >     make clean
 >     make configure
 >     ktrace -i -t+a make
 >     kdump | less
 >
 >  The dump file will be full of crap but it should reveal what's editing
 >  the script, and that plus the build log ought to allow figuring out
 >  what happened.

 I still can't pinpoint the exact location where things go wrong, but 
 that reveals a few suspects:

 npth-config seems to get touched by work/npth-1.5/build-aux/ltmain.sh. 
 This seems to apply work/.wrapper/tmp/untransform.sed.

 Is the source of this file something that changed between NetBSD 7.0.1 
 and 7.1? On Solaris I am using bootstrap-mk-files-20170802.





 root@pkgsrc-nb70:/usr/pkgsrc/devel/npth> make
 => Bootstrap dependency digest>=20010302: found digest-20160304
 ===> Skipping vulnerability checks.
 WARNING: No /var/db/pkg/pkg-vulnerabilities file found.
 WARNING: To fix run: `/usr/sbin/pkg_admin -K /var/db/pkg 
 fetch-pkg-vulnerabilities'.
 ===> Building for npth-1.5
 --- all ---
 /usr/bin/make  all-recursive
 --- all-recursive ---
 Making all in src
 --- npth.lo ---
 --- npth-sigev.lo ---
 --- npth.lo ---
 /bin/sh ../libtool  --tag=CC    --mode=compile gcc -DHAVE_CONFIG_H  -I. 
 -I..      -O2 -D_FORTIFY_SOURCE=2 -MT npth.lo -MD -MP -MF .deps/npth.Tpo 
 -c -o npth.lo npth.c
 --- npth-sigev.lo ---
 /bin/sh ../libtool  --tag=CC    --mode=compile gcc -DHAVE_CONFIG_H  -I. 
 -I..      -O2 -D_FORTIFY_SOURCE=2 -MT npth-sigev.lo -MD -MP -MF 
 .deps/npth-sigev.Tpo -c -o npth-sigev.lo npth-sigev.c
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -O2 -D_FORTIFY_SOURCE=2 
 -MT npth-sigev.lo -MD -MP -MF .deps/npth-sigev.Tpo -c npth-sigev.c 
 -fPIC -DPIC -o .libs/npth-sigev.o
 --- npth.lo ---
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -O2 -D_FORTIFY_SOURCE=2 
 -MT npth.lo -MD -MP -MF .deps/npth.Tpo -c npth.c  -fPIC -DPIC -o 
 .libs/npth.o
 --- npth-sigev.lo ---
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -O2 -D_FORTIFY_SOURCE=2 
 -MT npth-sigev.lo -MD -MP -MF .deps/npth-sigev.Tpo -c npth-sigev.c -o 
 npth-sigev.o >/dev/null 2>&1
 --- npth.lo ---
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -O2 -D_FORTIFY_SOURCE=2 
 -MT npth.lo -MD -MP -MF .deps/npth.Tpo -c npth.c -o npth.o >/dev/null 2>&1
 --- npth-sigev.lo ---
 mv -f .deps/npth-sigev.Tpo .deps/npth-sigev.Plo
 --- npth.lo ---
 mv -f .deps/npth.Tpo .deps/npth.Plo
 --- libnpth.la ---
 /bin/sh ../libtool  --tag=CC    --mode=link gcc  -O2 -D_FORTIFY_SOURCE=2 
       -version-info  1:1:1 -Wl,-R/usr/pkg/lib -o libnpth.la -rpath 
 /usr/pkg/lib npth.lo npth-sigev.lo  -lpthread
 libtool: link: gcc -shared  -fPIC -DPIC  .libs/npth.o .libs/npth-sigev.o 
    -lpthread -L/usr/pkgsrc/devel/npth/work/.buildlink/lib  -O2 
 -Wl,-R/usr/pkg/lib   -Wl,-soname -Wl,libnpth.so.0 -o .libs/libnpth.so.0.1.1
 libtool: link: (cd ".libs" && rm -f "libnpth.so.0" && ln -s 
 "libnpth.so.0.1.1" "libnpth.so.0")
 libtool: link: (cd ".libs" && rm -f "libnpth.so" && ln -s 
 "libnpth.so.0.1.1" "libnpth.so")
 libtool: link: ar cru .libs/libnpth.a  npth.o npth-sigev.o
 libtool: link: ranlib .libs/libnpth.a
 libtool: link: ( cd ".libs" && rm -f "libnpth.la" && ln -s 
 "../libnpth.la" "libnpth.la" )
 Making all in tests
 --- t-mutex.o ---
 --- t-thread.o ---
 --- t-fork.o ---
 --- t-mutex.o ---
 gcc -DHAVE_CONFIG_H -I. -I..  -I../src -D_POSIX_C_SOURCE=200112L    -O2 
 -D_FORTIFY_SOURCE=2 -MT t-mutex.o -MD -MP -MF .deps/t-mutex.Tpo -c -o 
 t-mutex.o t-mutex.c
 --- t-thread.o ---
 gcc -DHAVE_CONFIG_H -I. -I..  -I../src -D_POSIX_C_SOURCE=200112L    -O2 
 -D_FORTIFY_SOURCE=2 -MT t-thread.o -MD -MP -MF .deps/t-thread.Tpo -c -o 
 t-thread.o t-thread.c
 --- t-fork.o ---
 gcc -DHAVE_CONFIG_H -I. -I..  -I../src -D_POSIX_C_SOURCE=200112L    -O2 
 -D_FORTIFY_SOURCE=2 -MT t-fork.o -MD -MP -MF .deps/t-fork.Tpo -c -o 
 t-fork.o t-fork.c
 --- t-mutex.o ---
 mv -f .deps/t-mutex.Tpo .deps/t-mutex.Po
 --- t-mutex ---
 /bin/sh ../libtool  --tag=CC    --mode=link gcc  -O2 -D_FORTIFY_SOURCE=2 
    -Wl,-R/usr/pkg/lib -o t-mutex t-mutex.o ../src/libnpth.la   -lpthread
 --- t-fork.o ---
 mv -f .deps/t-fork.Tpo .deps/t-fork.Po
 --- t-fork ---
 /bin/sh ../libtool  --tag=CC    --mode=link gcc  -O2 -D_FORTIFY_SOURCE=2 
    -Wl,-R/usr/pkg/lib -o t-fork t-fork.o ../src/libnpth.la   -lpthread
 --- t-mutex ---
 libtool: link: gcc -O2 -D_FORTIFY_SOURCE=2 -Wl,-R/usr/pkg/lib -o 
 .libs/t-mutex t-mutex.o  -L../src/.libs -lnpth 
 -L/usr/pkgsrc/devel/npth/work/.buildlink/lib -lpthread 
 -Wl,-rpath,/usr/pkg/lib
 --- t-fork ---
 libtool: link: gcc -O2 -D_FORTIFY_SOURCE=2 -Wl,-R/usr/pkg/lib -o 
 .libs/t-fork t-fork.o  -L../src/.libs -lnpth 
 -L/usr/pkgsrc/devel/npth/work/.buildlink/lib -lpthread 
 -Wl,-rpath,/usr/pkg/lib
 --- t-thread.o ---
 mv -f .deps/t-thread.Tpo .deps/t-thread.Po
 --- t-thread ---
 /bin/sh ../libtool  --tag=CC    --mode=link gcc  -O2 -D_FORTIFY_SOURCE=2 
    -Wl,-R/usr/pkg/lib -o t-thread t-thread.o ../src/libnpth.la   -lpthread
 libtool: link: gcc -O2 -D_FORTIFY_SOURCE=2 -Wl,-R/usr/pkg/lib -o 
 .libs/t-thread t-thread.o  -L../src/.libs -lnpth 
 -L/usr/pkgsrc/devel/npth/work/.buildlink/lib -lpthread 
 -Wl,-rpath,/usr/pkg/lib
 => Unwrapping files-to-be-installed.


 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

 Universität Bielefeld
 Universitätsstraße 25
 33615 Bielefeld
 Telefon: +49 521 106-12601
 E-Mail: joern.clausen@uni-bielefeld.de

 http://www.uni-bielefeld.de/bits

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Wed, 04 Oct 2017 09:02:46 +0200

 Just for the record: On a freshly installed NetBSD 7.0.1 with pkgsrc 
 from 2017-10-02, npth builds fine. On a freshly bootstrapped pkgsrc on 
 the same day on Solaris 11.3, the error is still present.

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

Responsible-Changed-From-To: pkg-manager->solaris-pkg-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Wed, 04 Oct 2017 07:20:25 +0000
Responsible-Changed-Why:
Problem moved to Solaris-only


From: Jonathan Perkin <jperkin@joyent.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561 (devel/npth broken)
Date: Fri, 13 Oct 2017 16:20:49 +0100

 FWIW I don't see this on SmartOS.  I don't know what would be
 different on Solaris 11.3 to cause the problem.  Are you doing
 anything funky in your mk.conf?

 -- 
 Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

From: =?UTF-8?Q?J=c3=b6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org, solaris-pkg-people@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561 (devel/npth broken)
Date: Mon, 16 Oct 2017 08:59:52 +0200

 On 13.10.17 17:25, Jonathan Perkin wrote:
 >  FWIW I don't see this on SmartOS.  I don't know what would be
 >  different on Solaris 11.3 to cause the problem.  Are you doing
 >  anything funky in your mk.conf?

 No, just some *_DEFAUTLTS, some PKG_OPTIONS, nothing weird.

 Are the bulk builds for SunOS done on SmartOS, on Oracle Solaris, or are 
 that cross builds?

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

From: Jonathan Perkin <jperkin@pkgsrc.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561 (devel/npth broken)
Date: Mon, 16 Oct 2017 09:08:44 +0100

 * On 2017-10-16 at 08:05 BST, Jörn Clausen wrote:

 >  Are the bulk builds for SunOS done on SmartOS, on Oracle Solaris, or are 
 >  that cross builds?

 SmartOS.

 -- 
 Jonathan Perkin       www.perkin.org.uk
 github.com/jperkin  twitter.com/jperkin

From: Joern Clausen <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561: devel/npth broken
Date: Tue, 02 Jan 2018 10:51:22 +0100

 Thought I give this another go in the new year, so I tried it on NetBSD 
 7.1.1.

 Turn's out, you can trigger the error by defining

 USE_CWRAPPERS = no

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

From: Adrian Steinmann <ast@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561
Date: Thu, 10 May 2018 22:13:41 +0200

 As Jörn Clausen already mentioned last September, it's during
 the "Unwrapping files-to-be-installed" phase where
 work/.wrapper/tmp/untransform.sed erroneously removes the case
 lines in work/npth-1.5/npth-config

 pkgtools/cwrappers doesn't pose this problem as it doesn't use
 untransform.sed

 This problem can be avoided eother by

 + updating /usr/pkgsrc/mk/platform to get _OPSYS_SUPPORTS_CWRAPPERS=yes
   on the platform in question

 or

 + setting USE_CWRAPPERS=yes in devel/npth/Makefile to force using
   pkgtools/cwrappers

 or

 + setting _WRAP_UNTRANSFORM_SEDFILE=/dev/null in devel/npth/Makefile
   to avoid having sed apply work/.wrapper/tmp/untransform.sed on
   work/npth-1.5/npth-config

 Probably as more platforms support cwrappers and /usr/pkgsrc/mk/platform
 is updated, this problem will just fade away ...

 Adrian

From: Joern Clausen <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org, solaris-pkg-people@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/52561
Date: Fri, 11 May 2018 10:38:52 +0200

 On 05/10/18 22:20, Adrian Steinmann wrote:
 [...]
 >   Probably as more platforms support cwrappers and /usr/pkgsrc/mk/platform
 >   is updated, this problem will just fade away ...

 I just opened pkg/53275, which is another example of a package that does 
 not build using cwrappers on Solaris, but succeeds with cwrappers turned 
 off.

 Is it possible to turn off cwrappers in the Makefile of a package based 
 on OS? Like

 USE_CWRAPPERS.SunOS = no

 or is it already too late when that part of the Makefile is read?

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

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

 * On 2018-05-11 at 09:39 BST, Joern Clausen wrote:

 > On 05/10/18 22:20, Adrian Steinmann wrote:
 > [...]
 > >   Probably as more platforms support cwrappers and /usr/pkgsrc/mk/platform
 > >   is updated, this problem will just fade away ...
 > 
 > I just opened pkg/53275, which is another example of a package that does not
 > build using cwrappers on Solaris, but succeeds with cwrappers turned off.
 > 
 > Is it possible to turn off cwrappers in the Makefile of a package based on
 > OS? Like
 > 
 > USE_CWRAPPERS.SunOS = no
 > 
 > or is it already too late when that part of the Makefile is read?

 It's not currently supported, and it's not something I would like to
 see added.

 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.

 -- 
 Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

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

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

 -- 
 Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com

From: Jonathan Perkin <jperkin@joyent.com>
To: Joern Clausen <joern.clausen@uni-bielefeld.de>
Cc: gnats-bugs@NetBSD.org, solaris-pkg-people@NetBSD.org,
	gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
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

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

 Thanks for this detailed explanation! I'd like to see stuff like this 
 more from time to time. Alas, I cannot guarantee, that next time I will 
 be able to find such a bug on my own :)

 But one more question: Why was there a different behavior with/without 
 cwrappers in the first place? Do the classic wrappers handle MAKE_PARAMS 
 in some way cwrappers don't?

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

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

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

 So my next best solution would be a mechanism, that would allow me to 
 keep the build process as automated as possible, without as little 
 manual intervention as necessary. BTW: Turning off cwrappers in mk.conf 
 is no longer an option, as there are packages that do no longer compile 
 without cwrappers on Solaris. I think this is also a bug (at least as 
 long as cwrappers is optional), but the treatment of such PRs is the 
 same as above.

 -- 
 Jörn Clausen
 Plattformen & Serverdienste
 BITS - Bielefelder IT-Servicezentrum

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

 * On 2018-05-11 at 10:50 BST, Joern Clausen wrote:

 > Thanks for this detailed explanation! I'd like to see stuff like this more
 > from time to time. Alas, I cannot guarantee, that next time I will be able
 > to find such a bug on my own :)
 > 
 > But one more question: Why was there a different behavior with/without
 > cwrappers in the first place? Do the classic wrappers handle MAKE_PARAMS in
 > some way cwrappers don't?

 The legacy wrappers are less strict about enforcing the correct library
 paths, and it's likely they added and passed through $PREFIX/{include,lib}
 somewhere regardless.

 While this helps some software build, it's not correct, and can lead to
 problems later on.

 -- 
 Jonathan Perkin       www.perkin.org.uk
 github.com/jperkin  twitter.com/jperkin

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.