NetBSD Problem Report #50279

From tsutsui@ceres.dti.ne.jp  Sun Sep 27 01:20:24 2015
Return-Path: <tsutsui@ceres.dti.ne.jp>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id E9E81A6531
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 27 Sep 2015 01:20:24 +0000 (UTC)
Message-Id: <201509270120.t8R1KJ3P005347@mirage.localdomain>
Date: Sun, 27 Sep 2015 10:20:19 +0900 (JST)
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reply-To: tsutsui@ceres.dti.ne.jp
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: emulators/tme build failure on NetBSD/amd64 7.0
X-Send-Pr-Version: 3.95

>Number:         50279
>Category:       pkg
>Synopsis:       emulators/tme build failure on NetBSD/amd64 7.0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 27 01:25:00 +0000 2015
>Closed-Date:    Wed Dec 30 17:41:28 +0000 2015
>Last-Modified:  Wed Dec 30 17:41:28 +0000 2015
>Originator:     Izumi Tsutsui
>Release:        NetBSD 7.0
>Organization:
>Environment:
System: NetBSD optiplex 7.0 NetBSD 7.0 (GENERIC.201509250726Z) amd64
Architecture: x86_64
Machine: amd64
>Description:
emulators/tme build fails on NetBSD/amd64 7.0:

---
 :

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthread -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/gtk-2.0 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/lib/gtk-2.0/include -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/pango-1.0 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/glib/gio-unix-2.0/ -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.x11-buildlink/include -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/cairo -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/atk-1.0 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.x11-buildlink/include/pixman-1 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/libpng16 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/gdk-pixbuf-2.0 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include/harfbuzz -I/usr/obj.x86_64/pkgsrc/emulators/t!
 me/work.x86_64/.buildlink/include/glib/glib-2.0 -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/lib/glib-2.0/include -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.buildlink/include -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.x11-buildlink/include/freetype2 -D_TME_IMPL -I/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/.x11-buildlink/include/libdrm -DTME_NO_LOG -DTME_NO_DEBUG_LOCKS -DTME_NO_AUDIT_ATOMICS -DNDEBUG -O2 -Wundef -Wall -Werror -MT memory-auto.lo -MD -MP -MF .deps/memory-auto.Tpo -c memory-auto.c  -fPIC -DPIC -o .libs/memory-auto.o
In file included from ../tme/memory.h:124:0,
                 from memory-auto.c:35:
memory-auto.c: In function 'tme_memory_bus_write16':
../libtme/memory-auto.h:69:12: error: 'UINTMAX_MAX' undeclared (first use in this function)
   ((type) (UINTMAX_MAX shift))
            ^
memory-auto.c:323:20: note: in expansion of macro '_tme_memory_type_mask'
         part64 &= (_tme_memory_type_mask(tme_uint64_t, + 0) ^ (((tme_uint64_t) _tme_memory_type_mask(tme_uint16_t, << 0)) << size_skip));
                    ^
../libtme/memory-auto.h:69:12: note: each undeclared identifier is reported only once for each function it appears in
   ((type) (UINTMAX_MAX shift))
            ^
memory-auto.c:323:20: note: in expansion of macro '_tme_memory_type_mask'
         part64 &= (_tme_memory_type_mask(tme_uint64_t, + 0) ^ (((tme_uint64_t) _tme_memory_type_mask(tme_uint16_t, << 0)) << size_skip));
                    ^
memory-auto.c: In function 'tme_memory_bus_write32':
../libtme/memory-auto.h:69:12: error: 'UINTMAX_MAX' undeclared (first use in this function)
   ((type) (UINTMAX_MAX shift))
            ^
memory-auto.c:887:20: note: in expansion of macro '_tme_memory_type_mask'
         part64 &= (_tme_memory_type_mask(tme_uint64_t, + 0) ^ (((tme_uint64_t) _tme_memory_type_mask(tme_uint32_t, << 0)) << size_skip));
                    ^
memory-auto.c: In function 'tme_memory_bus_write64':
../libtme/memory-auto.h:69:12: error: 'UINTMAX_MAX' undeclared (first use in this function)
   ((type) (UINTMAX_MAX shift))
            ^
memory-auto.c:1503:20: note: in expansion of macro '_tme_memory_type_mask'
         part64 &= (_tme_memory_type_mask(tme_uint64_t, + 0) ^ (((tme_uint64_t) _tme_memory_type_mask(tme_uint64_t, << 0)) << size_skip));
                    ^
memory-auto.c: In function 'tme_memory_bus_write_buffer':
../libtme/memory-auto.h:69:12: error: 'UINTMAX_MAX' undeclared (first use in this function)
   ((type) (UINTMAX_MAX shift))
            ^
memory-auto.c:2686:14: note: in expansion of macro '_tme_memory_type_mask'
            ? _tme_memory_type_mask(tme_uint64_t, << (count * 8))
              ^
Makefile:370: recipe for target 'memory-auto.lo' failed
gmake[4]: *** [memory-auto.lo] Error 1
gmake[4]: Leaving directory '/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/tme-0.8/libtme'
Makefile:406: recipe for target 'all-recursive' failed
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory '/usr/obj.x86_64/pkgsrc/emulators/tme/work.x86_64/tme-0.8/libtme'
Makefile:267: recipe for target 'all' failed
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory '/usr/obj.x86_64/pkgsrc
---

The "UINTMAX_MAX" was added in a pkgsrc patch in recently:
 http://mail-index.netbsd.org/pkgsrc-changes/2015/09/13/msg130026.html
 http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/tme/patches/patch-libtme_memory-auto.sh?rev=1.1

>How-To-Repeat:
cd /usr/pkgsrc/emulators/tme && make package

>Fix:
Revert untested changes?

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->joerg
Responsible-Changed-By: bsiegert@NetBSD.org
Responsible-Changed-When: Sun, 27 Sep 2015 08:18:18 +0000
Responsible-Changed-Why:
Hello Joerg! Could you take a look at why your patch is breaking the build,
please?


From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: joerg@NetBSD.org
Cc: gnats-bugs@NetBSD.org, pkg-manager@netbsd.org, gnats-admin@netbsd.org,
        bsiegert@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Wed, 14 Oct 2015 02:28:44 +0900

 http://mail-index.netbsd.org/pkgsrc-changes/2015/10/07/msg130977.html

 >> Modified Files:
 >>         pkgsrc/emulators/tme: distinfo
 >>         pkgsrc/emulators/tme/patches: patch-libtme_memory-auto.sh
 >> 
 >> Log Message:
 >> Explicitly pull in limits.h, it sometimes hasn't been included yet.

 - Could you please explicitly denote PR number in your commit log?

 - Did you actually test it before commit?
   <limits.h> won't pull <machine/int_limits.h> (at least on NetBSD 7.0)
   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
	gnats-admin@netbsd.org, bsiegert@NetBSD.org
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Tue, 13 Oct 2015 23:18:52 +0200

 On Wed, Oct 14, 2015 at 02:28:44AM +0900, Izumi Tsutsui wrote:
 > http://mail-index.netbsd.org/pkgsrc-changes/2015/10/07/msg130977.html
 > 
 > >> Modified Files:
 > >>         pkgsrc/emulators/tme: distinfo
 > >>         pkgsrc/emulators/tme/patches: patch-libtme_memory-auto.sh
 > >> 
 > >> Log Message:
 > >> Explicitly pull in limits.h, it sometimes hasn't been included yet.
 > 
 > - Could you please explicitly denote PR number in your commit log?

 Depends on how much work it is to look them up.

 > 
 > - Did you actually test it before commit?
 >   <limits.h> won't pull <machine/int_limits.h> (at least on NetBSD 7.0)
 >   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
 >   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

 Given that I don't have the problem, how could I? Feel free to change it
 to stdint.h if that works better.

 Joerg

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: joerg@britannica.bec.de
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
        gnats-admin@netbsd.org, bsiegert@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Wed, 14 Oct 2015 06:46:59 +0900

 joerg@ wrote:

 > > - Did you actually test it before commit?
 > >   <limits.h> won't pull <machine/int_limits.h> (at least on NetBSD 7.0)
 > >   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
 > >   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
 > 
 > Given that I don't have the problem, how could I?

 Which architecture/environment did you test it on?
 What makes you think limits.h is enough?

 ---
 Izumi Tsutsui

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
	gnats-admin@netbsd.org, bsiegert@NetBSD.org
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Wed, 14 Oct 2015 00:11:16 +0200

 On Wed, Oct 14, 2015 at 06:46:59AM +0900, Izumi Tsutsui wrote:
 > joerg@ wrote:
 > 
 > > > - Did you actually test it before commit?
 > > >   <limits.h> won't pull <machine/int_limits.h> (at least on NetBSD 7.0)
 > > >   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
 > > >   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
 > > 
 > > Given that I don't have the problem, how could I?
 > 
 > Which architecture/environment did you test it on?
 > What makes you think limits.h is enough?

 I am doing my testing on NetBSD current with clang. I don't know right
 now what is pulling in stdint.h. I am not saying it is enough, just that
 I can't reproduce the problem in my test environment.

 Joerg

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: joerg@britannica.bec.de
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
        gnats-admin@netbsd.org, bsiegert@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Wed, 14 Oct 2015 08:27:23 +0900

 joerg@ write:

 > I am doing my testing on NetBSD current with clang. I don't know right
 > now what is pulling in stdint.h. I am not saying it is enough, just that
 > I can't reproduce the problem in my test environment.

 Why didn't you write it in your commit log?
 What you wrote in the log ("explicitly") was very confusing.
  >> Explicitly pull in limits.h, it sometimes hasn't been included yet.

 Anyway, please don't commit random changes you can't test.

 ---
 Izumi Tsutsui

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
	gnats-admin@netbsd.org, bsiegert@NetBSD.org
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Wed, 14 Oct 2015 11:33:37 +0200

 On Wed, Oct 14, 2015 at 08:27:23AM +0900, Izumi Tsutsui wrote:
 > joerg@ write:
 > 
 > > I am doing my testing on NetBSD current with clang. I don't know right
 > > now what is pulling in stdint.h. I am not saying it is enough, just that
 > > I can't reproduce the problem in my test environment.
 > 
 > Why didn't you write it in your commit log?
 > What you wrote in the log ("explicitly") was very confusing.
 >  >> Explicitly pull in limits.h, it sometimes hasn't been included yet.
 > 
 > Anyway, please don't commit random changes you can't test.

 Fine, I'll just leave things broken the next time.

 Joerg

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: joerg@britannica.bec.de
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
        gnats-admin@netbsd.org, bsiegert@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Thu, 15 Oct 2015 01:37:31 +0900

 joerg@ wrote:

 > > > I am doing my testing on NetBSD current with clang. I don't know right
 > > > now what is pulling in stdint.h. I am not saying it is enough, just that
 > > > I can't reproduce the problem in my test environment.
 > > 
 > > Why didn't you write it in your commit log?
 > > What you wrote in the log ("explicitly") was very confusing.
 > >  >> Explicitly pull in limits.h, it sometimes hasn't been included yet.
 > > 
 > > Anyway, please don't commit random changes you can't test.
 > 
 > Fine, I'll just leave things broken the next time.

 If you mean the original "(((type) 0) - ((type) 1))" was broken,
 it's fine to leave it.

 Making build broken even on the default NetBSD environment is
 much worse than that, i.e you should revert your untested change.

 ---
 Izumi Tsutsui

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
	gnats-admin@netbsd.org, bsiegert@NetBSD.org
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Wed, 14 Oct 2015 21:24:52 +0200

 On Thu, Oct 15, 2015 at 01:37:31AM +0900, Izumi Tsutsui wrote:
 > joerg@ wrote:
 > 
 > > > > I am doing my testing on NetBSD current with clang. I don't know right
 > > > > now what is pulling in stdint.h. I am not saying it is enough, just that
 > > > > I can't reproduce the problem in my test environment.
 > > > 
 > > > Why didn't you write it in your commit log?
 > > > What you wrote in the log ("explicitly") was very confusing.
 > > >  >> Explicitly pull in limits.h, it sometimes hasn't been included yet.
 > > > 
 > > > Anyway, please don't commit random changes you can't test.
 > > 
 > > Fine, I'll just leave things broken the next time.
 > 
 > If you mean the original "(((type) 0) - ((type) 1))" was broken,
 > it's fine to leave it.

 No, the original was ((type)0 - (type)1) << x, for some value of x. The
 C standard is pretty explicitly about that not being valid.

 > Making build broken even on the default NetBSD environment is
 > much worse than that, i.e you should revert your untested change.

 I have an environment where it works. As such, it was tested. I could
 not verify your problem, so I tried to apply a fix for that which
 doesn't make the situation any worse. I won't try to do that in the
 future, since it has become obvious that you prefer to do any fixes
 yourself.

 Joerg

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: joerg@britannica.bec.de
Cc: joerg@NetBSD.org, gnats-bugs@NetBSD.org, pkg-manager@netbsd.org,
        gnats-admin@netbsd.org, bsiegert@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: pkg/50279 (emulators/tme build failure on NetBSD/amd64 7.0)
Date: Fri, 16 Oct 2015 00:08:57 +0900

 joerg@ wrote:

 > On Thu, Oct 15, 2015 at 01:37:31AM +0900, Izumi Tsutsui wrote:
 > > joerg@ wrote:
 > > 
 > > > > > I am doing my testing on NetBSD current with clang. I don't know right
 > > > > > now what is pulling in stdint.h. I am not saying it is enough, just that
 > > > > > I can't reproduce the problem in my test environment.
 > > > > 
 > > > > Why didn't you write it in your commit log?
 > > > > What you wrote in the log ("explicitly") was very confusing.
 > > > >  >> Explicitly pull in limits.h, it sometimes hasn't been included yet.
 > > > > 
 > > > > Anyway, please don't commit random changes you can't test.
 > > > 
 > > > Fine, I'll just leave things broken the next time.
 > > 
 > > If you mean the original "(((type) 0) - ((type) 1))" was broken,
 > > it's fine to leave it.
 > 
 > No, the original was ((type)0 - (type)1) << x, for some value of x. The
 > C standard is pretty explicitly about that not being valid.

 The standard also defines <stdint.h> for UINTMAX_MAX.
 That's what you missed.

 > > Making build broken even on the default NetBSD environment is
 > > much worse than that, i.e you should revert your untested change.
 > 
 > I have an environment where it works. As such, it was tested. I could
 > not verify your problem, so I tried to apply a fix for that which
 > doesn't make the situation any worse. I won't try to do that in the
 > future, since it has become obvious that you prefer to do any fixes
 > yourself.

 I prefer everyone admits his mistake and corrects it himself.

 ---
 Izumi Tsutsui

Responsible-Changed-From-To: joerg->pkg-manager
Responsible-Changed-By: joerg@NetBSD.org
Responsible-Changed-When: Thu, 15 Oct 2015 19:19:50 +0000
Responsible-Changed-Why:
Can't reproduce, can't test and submitter is busy with ad hominem attacks.
Necessary changes are included for whoever can reproduce the problem and
wants to spend more time on fixing things than producing wasted electrons.


From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/50279 CVS commit: pkgsrc/emulators/tme
Date: Wed, 4 Nov 2015 03:33:39 +0000

 Module Name:	pkgsrc
 Committed By:	dholland
 Date:		Wed Nov  4 03:33:39 UTC 2015

 Modified Files:
 	pkgsrc/emulators/tme: distinfo
 	pkgsrc/emulators/tme/patches: patch-libtme_memory-auto.sh

 Log Message:
 add stdint.h per PR 50279


 To generate a diff of this commit:
 cvs rdiff -u -r1.22 -r1.23 pkgsrc/emulators/tme/distinfo
 cvs rdiff -u -r1.2 -r1.3 \
     pkgsrc/emulators/tme/patches/patch-libtme_memory-auto.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Wed, 04 Nov 2015 03:36:59 +0000
State-Changed-Why:
added stdint.h, please test in your environment.

...and can we please try to avoid this kind of sniping?


State-Changed-From-To: feedback->closed
State-Changed-By: tsutsui@NetBSD.org
State-Changed-When: Wed, 30 Dec 2015 17:41:28 +0000
State-Changed-Why:
Builds on pkgsrc-2015Q4 (though sparc64 emulation gets segmentation fault).


>Unformatted:

Home	PR Database Search