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: joernc@gmail.com
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: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Sep 20 07:05:00 +0000 2017
>Closed-Date: Fri May 31 08:11:45 +0000 2019
>Last-Modified: Fri May 31 08:11:45 +0000 2019
>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
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/52561
Date: Sun, 25 Nov 2018 23:42:35 +0000
On Fri, May 11, 2018 at 10:00:02AM +0000, Jonathan Perkin wrote:
> [...]
Am I correct in thinking the state of this PR is:
- there is no problem as long as one turns on cwrappers;
- with old wrappers, untransform.sed is zorching shell scripts and we
aren't sure why;
- nobody really feels inclined to fix the old wrappers.
?
--
David A. Holland
dholland@netbsd.org
From: Jonathan Perkin <jperkin@pkgsrc.org>
To: gnats-bugs@NetBSD.org
Cc: solaris-pkg-people@NetBSD.org, gnats-admin@netbsd.org,
pkgsrc-bugs@netbsd.org, joern.clausen@uni-bielefeld.de
Subject: Re: pkg/52561
Date: Mon, 26 Nov 2018 09:10:43 +0000
* On 2018-11-25 at 23:45 GMT, David Holland wrote:
> The following reply was made to PR pkg/52561; it has been noted by GNATS.
>
> From: David Holland <dholland-pbugs@netbsd.org>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: pkg/52561
> Date: Sun, 25 Nov 2018 23:42:35 +0000
>
> On Fri, May 11, 2018 at 10:00:02AM +0000, Jonathan Perkin wrote:
> > [...]
>
> Am I correct in thinking the state of this PR is:
>
> - there is no problem as long as one turns on cwrappers;
> - with old wrappers, untransform.sed is zorching shell scripts and we
> aren't sure why;
> - nobody really feels inclined to fix the old wrappers.
I'd agree. SunOS is one of the platforms where legacy wrappers hurt the
most in terms of performance, so I certainly have no desire to fix them.
Again, I'd much rather spent the time fixing any packages that are
currently incompatible with cwrappers and its stricter requirements.
--
Jonathan Perkin www.perkin.org.uk
github.com/jperkin twitter.com/jperkin
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 31 May 2019 08:11:45 +0000
State-Changed-Why:
wontfix. use cwrappers...
>Unformatted:
(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.
Home