Re: powerpc bulk build report

[George Koehler]

On Sun, 10 Mar 2024 18:26:04 +0100
Omar Polo  wrote:

> The alternative, if I'm reading this[0] correctly, is to sprinkle some
> #include  and -maltivec, but since it's not used I think it's
> easier to just remove it.  If it works I'll upstream this as well.

On Sun, 10 Mar 2024 18:42:06 +0100
Tobias Heider  wrote:

> Do we actually support ppcs without altivec? I guess it might work better
> with altivec enabled instead.

OpenBSD/macppc runs on PowerPC G3 without altivec, and G4 and G5 with
altivec.  The default from clang is -mno-altivec for powerpc, but
-maltivec for powerpc64.

This game needs 3d acceleration, but Mesa in OpenBSD/macppc can
accelerate only the newer radeon cards (r300), and I have seen these
cards only in G4 and G5 models with altivec.

On Sun, 10 Mar 2024 19:21:22 +0100
Tobias Heider  wrote:

> Right, the commit history also doesn't really help. I can test it and see if 
> it
> works with just the vec removed. The other __ppc__ parts might actually work.

The other __ppc__ parts use the "fsel" and "frsqrte" instructions.
These were optional instructions, but the G3 does have them (in the
MPC750 manual).
--gkoehler

Re: powerpc bulk build report

[Tobias Heider]

On Sun, Mar 10, 2024 at 06:26:04PM +0100, Omar Polo wrote:
> On 2024/03/03 20:37:45 -0700, gkoeh...@openbsd.org wrote:
> > http://build-failures.rhaalovely.net/powerpc/2024-02-07/games/nanosaur2.log
> 
> : 
> /usr/obj/ports/nanosaur2-2.1.0/Nanosaur2-2.1.0/Source/Headers/ogl_support.h:122:2:
> : error: unknown type name 'vector'
> : vector float v[4];
> : ^
> : 1 error generated.
> 
> I missed this failure, thanks izzy for prodding me.  I don't have a
> powerpc to test this, but it appears if I'm grepping correctly that this
> field is never used.
> 
> (no bump needed since it only fixes -hopefully- the build on powerpc
> where it wasn't built before.)
> 
> The alternative, if I'm reading this[0] correctly, is to sprinkle some
> #include  and -maltivec, but since it's not used I think it's
> easier to just remove it.  If it works I'll upstream this as well.
> 
> [0]: 
> https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html

I actually built and tested this a few weeks back. I just removed all the
#ifdef __ppc__ blocks. Game loads but runs with ~5 fps and crashes after
a few seconds on my powerbook G4

Do we actually support ppcs without altivec? I guess it might work better
with altivec enabled instead.

> 
> 
> Thanks!
> 
> Omar Polo
> 
> 
> Index: patches/patch-Source_Headers_ogl_support_h
> ===
> RCS file: patches/patch-Source_Headers_ogl_support_h
> diff -N patches/patch-Source_Headers_ogl_support_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-Source_Headers_ogl_support_h10 Mar 2024 17:12:47 
> -
> @@ -0,0 +1,16 @@
> +fixes "error: unknown type name 'vector'" on powerpc; the v field is
> +never used.
> +
> +Index: Source/Headers/ogl_support.h
> +--- Source/Headers/ogl_support.h.orig
>  Source/Headers/ogl_support.h
> +@@ -118,9 +118,6 @@ typedef struct
> + typedef union
> + {
> + GLfloat value[16];
> +-#if defined(__ppc__)
> +-vector float v[4];
> +-#endif
> + }OGLMatrix4x4;
> + 
> + typedef struct
> 

Re: powerpc bulk build report

[Tobias Heider]

On Sun, Mar 10, 2024 at 06:55:07PM +0100, Omar Polo wrote:
> On 2024/03/10 18:42:06 +0100, Tobias Heider  wrote:
> > On Sun, Mar 10, 2024 at 06:26:04PM +0100, Omar Polo wrote:
> > > On 2024/03/03 20:37:45 -0700, gkoeh...@openbsd.org wrote:
> > > > http://build-failures.rhaalovely.net/powerpc/2024-02-07/games/nanosaur2.log
> > > 
> > > : 
> > > /usr/obj/ports/nanosaur2-2.1.0/Nanosaur2-2.1.0/Source/Headers/ogl_support.h:122:2:
> > > : error: unknown type name 'vector'
> > > : vector float v[4];
> > > : ^
> > > : 1 error generated.
> > > 
> > > I missed this failure, thanks izzy for prodding me.  I don't have a
> > > powerpc to test this, but it appears if I'm grepping correctly that this
> > > field is never used.
> > > 
> > > (no bump needed since it only fixes -hopefully- the build on powerpc
> > > where it wasn't built before.)
> > > 
> > > The alternative, if I'm reading this[0] correctly, is to sprinkle some
> > > #include  and -maltivec, but since it's not used I think it's
> > > easier to just remove it.  If it works I'll upstream this as well.
> > > 
> > > [0]: 
> > > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html
> > 
> > I actually built and tested this a few weeks back. I just removed all the
> > #ifdef __ppc__ blocks. Game loads but runs with ~5 fps and crashes after
> > a few seconds on my powerbook G4
> > 
> > Do we actually support ppcs without altivec? I guess it might work better
> > with altivec enabled instead.
> 
> If there are chances that it is playable with altivec enabled IMHO it
> would make sense to do so since the choice is between a broken game
> everywhere and something that can be played on some machines.
> 
> However, this vector doesn't seem to be used at all in the code, so I
> don't see how enabling altivec here will actually change something at
> runtime, although I might have missed something.
> 

Right, the commit history also doesn't really help. I can test it and see if it
works with just the vec removed. The other __ppc__ parts might actually work.

Re: powerpc bulk build report

[Omar Polo]

On 2024/03/10 18:42:06 +0100, Tobias Heider  wrote:
> On Sun, Mar 10, 2024 at 06:26:04PM +0100, Omar Polo wrote:
> > On 2024/03/03 20:37:45 -0700, gkoeh...@openbsd.org wrote:
> > > http://build-failures.rhaalovely.net/powerpc/2024-02-07/games/nanosaur2.log
> > 
> > : 
> > /usr/obj/ports/nanosaur2-2.1.0/Nanosaur2-2.1.0/Source/Headers/ogl_support.h:122:2:
> > : error: unknown type name 'vector'
> > : vector float v[4];
> > : ^
> > : 1 error generated.
> > 
> > I missed this failure, thanks izzy for prodding me.  I don't have a
> > powerpc to test this, but it appears if I'm grepping correctly that this
> > field is never used.
> > 
> > (no bump needed since it only fixes -hopefully- the build on powerpc
> > where it wasn't built before.)
> > 
> > The alternative, if I'm reading this[0] correctly, is to sprinkle some
> > #include  and -maltivec, but since it's not used I think it's
> > easier to just remove it.  If it works I'll upstream this as well.
> > 
> > [0]: 
> > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html
> 
> I actually built and tested this a few weeks back. I just removed all the
> #ifdef __ppc__ blocks. Game loads but runs with ~5 fps and crashes after
> a few seconds on my powerbook G4
> 
> Do we actually support ppcs without altivec? I guess it might work better
> with altivec enabled instead.

If there are chances that it is playable with altivec enabled IMHO it
would make sense to do so since the choice is between a broken game
everywhere and something that can be played on some machines.

However, this vector doesn't seem to be used at all in the code, so I
don't see how enabling altivec here will actually change something at
runtime, although I might have missed something.

Re: powerpc bulk build report

[Omar Polo]

On 2024/03/03 20:37:45 -0700, gkoeh...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/powerpc/2024-02-07/games/nanosaur2.log

: 
/usr/obj/ports/nanosaur2-2.1.0/Nanosaur2-2.1.0/Source/Headers/ogl_support.h:122:2:
: error: unknown type name 'vector'
: vector float v[4];
: ^
: 1 error generated.

I missed this failure, thanks izzy for prodding me.  I don't have a
powerpc to test this, but it appears if I'm grepping correctly that this
field is never used.

(no bump needed since it only fixes -hopefully- the build on powerpc
where it wasn't built before.)

The alternative, if I'm reading this[0] correctly, is to sprinkle some
#include  and -maltivec, but since it's not used I think it's
easier to just remove it.  If it works I'll upstream this as well.

[0]: 
https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html


Thanks!

Omar Polo


Index: patches/patch-Source_Headers_ogl_support_h
===
RCS file: patches/patch-Source_Headers_ogl_support_h
diff -N patches/patch-Source_Headers_ogl_support_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-Source_Headers_ogl_support_h  10 Mar 2024 17:12:47 -
@@ -0,0 +1,16 @@
+fixes "error: unknown type name 'vector'" on powerpc; the v field is
+never used.
+
+Index: Source/Headers/ogl_support.h
+--- Source/Headers/ogl_support.h.orig
 Source/Headers/ogl_support.h
+@@ -118,9 +118,6 @@ typedef struct
+ typedef union
+ {
+   GLfloat value[16];
+-  #if defined(__ppc__)
+-  vector float v[4];
+-  #endif
+ }OGLMatrix4x4;
+ 
+ typedef struct

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

[Tobias Heider]

On Fri, Nov 24, 2023 at 03:23:46PM +0100, Tobias Heider wrote:
> On Fri, Nov 24, 2023 at 08:36:03AM +0100, Sebastien Marie wrote:
> > Tobias Heider  writes:
> >
> > > On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
> > >> gkoeh...@openbsd.org writes:
> > >> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
> > >>
> > >> Could someone test the following patch for lang/sbcl on powerpc ?
> > >> If it works, I will push it upstream.
> > >
> > > This fixes the first problem but after that I ran into an undefined
> > > symbol current_thread error.
> > >
> > > It looks like arm64 already handles this correctly in arm64-assem.S:114
> > > but a simple s/current_thread/__emutls_v.current_thread/ was not enough
> > > since it caused runtime errors later on.
> >
> > oh.
> >
> > direct TLS seems to not be expected for powerpc: Linux code enable it
> > only for some archs (and ppc isn't in the list). So follow the same way.
> >
> > Does it correct the problem ? (and does #include "validate.h" is still
> > need ?)
> >
> > Thanks.
> >
> 
> Sadly this seems to give me the same error that I got with 
> __emutls_v.current_thread:
> 
> //doing warm init - compilation phase
> This is SBCL 2.3.10.openbsd.sbcl-2.3.10, an implementation of ANSI Common 
> Lisp.
> More information about SBCL is available at .
> 
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> Initial page table:
> Immobile Object Counts
>  Gen layout fdefn symbol   code  Boxed   ConsRaw   Code  SmMix  Mixed  
> LgRaw LgCode  LgMix Waste%   AllocTrig   Dirty GCs Mem-age
>   6  0  0  0  0  0501  0   3505  0   3591 
>  0  0  00.430986640 2003505   0  0.
> Tot  0  0  0  0  0501  0   3505  0   3591 
>  0  0  00.430986640 [5.8% of 536870912 max]
> fatal error encountered in SBCL pid 94032 pthread 0xc50e1d94:
> maximum interrupt nesting depth (8) exceeded
> 
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> //doing warm init - load and dump phase
> fatal error encountered in SBCL pid 52269 pthread 0xc040cd94:
> maximum interrupt nesting depth (8) exceeded
> 
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> [1] + Stopped (tty input)  ./src/runtime/sbcl --core 
> output/cold-sbcl.core
> [2] - Stopped (tty input)  ./src/runtime/sbcl --noinform --core output/col
> 0m00.51s real 0m00.01s user 0m00.01s system
> //entering make-target-contrib.sh
> 

Just realized that that was a lie.  I was looking at the wrong tmux pane...
Your fix seems to work. Thank you!

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

[Tobias Heider]

On Fri, Nov 24, 2023 at 08:36:03AM +0100, Sebastien Marie wrote:
> Tobias Heider  writes:
>
> > On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
> >> gkoeh...@openbsd.org writes:
> >> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
> >>
> >> Could someone test the following patch for lang/sbcl on powerpc ?
> >> If it works, I will push it upstream.
> >
> > This fixes the first problem but after that I ran into an undefined
> > symbol current_thread error.
> >
> > It looks like arm64 already handles this correctly in arm64-assem.S:114
> > but a simple s/current_thread/__emutls_v.current_thread/ was not enough
> > since it caused runtime errors later on.
>
> oh.
>
> direct TLS seems to not be expected for powerpc: Linux code enable it
> only for some archs (and ppc isn't in the list). So follow the same way.
>
> Does it correct the problem ? (and does #include "validate.h" is still
> need ?)
>
> Thanks.
>

Sadly this seems to give me the same error that I got with 
__emutls_v.current_thread:

//doing warm init - compilation phase
This is SBCL 2.3.10.openbsd.sbcl-2.3.10, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
Initial page table:
Immobile Object Counts
 Gen layout fdefn symbol   code  Boxed   ConsRaw   Code  SmMix  Mixed  
LgRaw LgCode  LgMix Waste%   AllocTrig   Dirty GCs Mem-age
  6  0  0  0  0  0501  0   3505  0   3591  
0  0  00.430986640 2003505   0  0.
Tot  0  0  0  0  0501  0   3505  0   3591  
0  0  00.430986640 [5.8% of 536870912 max]
fatal error encountered in SBCL pid 94032 pthread 0xc50e1d94:
maximum interrupt nesting depth (8) exceeded

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> //doing warm init - load and dump phase
fatal error encountered in SBCL pid 52269 pthread 0xc040cd94:
maximum interrupt nesting depth (8) exceeded

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> [1] + Stopped (tty input)  ./src/runtime/sbcl --core output/cold-sbcl.core
[2] - Stopped (tty input)  ./src/runtime/sbcl --noinform --core output/col
0m00.51s real 0m00.01s user 0m00.01s system
//entering make-target-contrib.sh

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

[Sebastien Marie]

Tobias Heider  writes:

> On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
>> gkoeh...@openbsd.org writes:
>> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
>> 
>> Could someone test the following patch for lang/sbcl on powerpc ?
>> If it works, I will push it upstream.
>
> This fixes the first problem but after that I ran into an undefined
> symbol current_thread error.
>
> It looks like arm64 already handles this correctly in arm64-assem.S:114
> but a simple s/current_thread/__emutls_v.current_thread/ was not enough
> since it caused runtime errors later on.

oh.

direct TLS seems to not be expected for powerpc: Linux code enable it
only for some archs (and ppc isn't in the list). So follow the same way.

Does it correct the problem ? (and does #include "validate.h" is still
need ?)

Thanks.


diff /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl
commit - 665eeac5c5d6c581db4785cba6292a0e5fc1bbf2
path + /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl
blob - /dev/null
file + patches/patch-make-config_sh (mode 640)
--- /dev/null
+++ patches/patch-make-config_sh
@@ -0,0 +1,15 @@
+Index: make-config.sh
+--- make-config.sh.orig
 make-config.sh
+@@ -610,7 +610,10 @@ case "$sbcl_os" in
+ ;;
+ openbsd)
+ printf ' :openbsd' >> $ltf
+-printf ' :gcc-tls' >> $ltf
++case "$sbcl_arch" in
++  arm64 | x86 | x86-64)
++  printf ' :gcc-tls' >> $ltf
++esac
+ link_or_copy Config.$sbcl_arch-openbsd Config
+ ;;
+ netbsd)
blob - /dev/null
file + patches/patch-src_runtime_ppc-assem_S (mode 640)
--- /dev/null
+++ patches/patch-src_runtime_ppc-assem_S
@@ -0,0 +1,11 @@
+Index: src/runtime/ppc-assem.S
+--- src/runtime/ppc-assem.S.orig
 src/runtime/ppc-assem.S
+@@ -5,6 +5,7 @@
+ 
+ #include "sbcl.h"
+ #include "lispregs.h"
++#include "validate.h"
+ #include "genesis/closure.h"
+ #include "genesis/static-symbols.h"
+ #include "genesis/thread.h"


-- 
Sebastien Marie

Re: lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

[Tobias Heider]

On Thu, Nov 23, 2023 at 11:02:22AM +0100, Sebastien Marie wrote:
> gkoeh...@openbsd.org writes:
> > http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log
> 
> Could someone test the following patch for lang/sbcl on powerpc ?
> If it works, I will push it upstream.

This fixes the first problem but after that I ran into an undefined
symbol current_thread error.

It looks like arm64 already handles this correctly in arm64-assem.S:114
but a simple s/current_thread/__emutls_v.current_thread/ was not enough
since it caused runtime errors later on.

lang/sbcl on powerpc (call for testing) - Re: powerpc bulk build report

[Sebastien Marie]

gkoeh...@openbsd.org writes:
> http://build-failures.rhaalovely.net/powerpc/2023-10-31/lang/sbcl.log

Could someone test the following patch for lang/sbcl on powerpc ?
If it works, I will push it upstream.


diff /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl
commit - 665eeac5c5d6c581db4785cba6292a0e5fc1bbf2
path + /home/semarie/repos/openbsd/ports/mystuff/lang/sbcl
blob - /dev/null
file + patches/patch-src_runtime_ppc-assem_S (mode 640)
--- /dev/null
+++ patches/patch-src_runtime_ppc-assem_S
@@ -0,0 +1,11 @@
+Index: src/runtime/ppc-assem.S
+--- src/runtime/ppc-assem.S.orig
 src/runtime/ppc-assem.S
+@@ -5,6 +5,7 @@
+ 
+ #include "sbcl.h"
+ #include "lispregs.h"
++#include "validate.h"
+ #include "genesis/closure.h"
+ #include "genesis/static-symbols.h"
+ #include "genesis/thread.h"

Thanks.
-- 
Sebastien Marie

Re: powerpc bulk build report

[George Koehler]

On Thu, 22 Sep 2022 08:24:48 -0600 (MDT)
gkoeh...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Tue Aug 30 14:54:38 MDT 2022
> Finished: Thu Sep 22 08:24:16 MDT 2022
> Duration: 22 Days 17 hours 30 minutes

This bulk is not finished.  I stopped the bulk (with
/usr/ports/logs/powerpc/stop) and restarted it to fix a problem; but
dpb(1) did exit 0, so my script mistook it as a finished bulk and
mailed this report.

Beware that the "Resolved failures" in this report are not really
resolved; the bulk has not yet reached those packages, and I expect
the packages to fail again when reached.

The restarted bulk has fixed x11/qt6/qtlottie.

> Built using OpenBSD 7.2-beta (GENERIC) #14: Sat Aug 27 17:39:17 MDT 2022
> 
> Built 8158 packages
> 
> Number of packages built each day:
> Aug 30: 389
> Aug 31: 382
> Sep 2: 151
> Sep 3: 417
> Sep 4: 412
> Sep 5: 206
> Sep 6: 108
> Sep 7: 127
> Sep 8: 247
> Sep 9: 385
> Sep 10: 520
> Sep 11: 293
> Sep 12: 354
> Sep 13: 701
> Sep 14: 584
> Sep 15: 1772
> Sep 16: 969
> Sep 17: 26
> Sep 18: 48
> Sep 19: 67
> Sep 20: 35
> Sep 21: 55
> Sep 22: 2
> 
> 
> 
> Critical path missing pkgs: 
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/summary.log
> 
> Build failures: 6
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/devel/abseil-cpp.log
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/games/mvdsv.log
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/graphics/webp-pixbuf-loader.log
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/lang/pcc/pcc-libs.log
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/x11/py-qt5,python3.log
> http://build-failures.rhaalovely.net/powerpc/2022-08-30/x11/qt6/qtlottie.log
> 
> Recurrent failures:
>  failures/devel/abseil-cpp.log
>  failures/lang/pcc/pcc-libs.log
>  failures/summary.log
> 
> New failures:
> +failures/games/mvdsv.log
> +failures/graphics/webp-pixbuf-loader.log
> +failures/x11/py-qt5,python3.log
> +failures/x11/qt6/qtlottie.log
> 
> Resolved failures:
> -failures/devel/qcoro.log
> -failures/emulators/higan.log
> -failures/emulators/retroarch.log
> -failures/games/eduke32.log
> -failures/games/hyperrogue.log
> -failures/games/nblood.log
> -failures/geo/qgis.log
> -failures/graphics/birdfont.log
> -failures/graphics/openimageio.log
> -failures/lang/chicken/bootstrap.log
> -failures/lang/gambit.log
> -failures/multimedia/mkvtoolnix.log
> -failures/telephony/asterisk-g729.log
> -failures/x11/gnome/secrets.log
> 
> Packages newly built:
> +converters/ruby-oj
> +devel/binutils
> +devel/py-editables,python3
> +devel/py-executing,python3
> +devel/py-jaraco-path,python3
> +devel/py-littleutils,python3
> +devel/py-parameterized,python3
> +devel/py-path,python3
> +devel/py-poetry-core,python3
> +devel/py-pure_eval,python3
> +devel/py-typeguard,python3
> +devel/py2-parsing
> +graphics/kplot
> +graphics/librtprocess
> +graphics/ruby-chunky_png
> +graphics/ruby-chunky_png,ruby31
> +graphics/ruby-rqrcode
> +net/py-websockets,python3
> +sysutils/py-command_runner,python3
> +sysutils/py-distlib,python3
> +sysutils/py-filelock,python3
> +sysutils/vifm
> +textproc/py-ini2toml,python3
> +x11/kde-applications/ksanecore
> +x11/qt6/qtcharts
> +x11/qt6/qtconnectivity
> +x11/qt6/qtdatavis3d
> +x11/qt6/qtnetworkauth
> +x11/qt6/qtremoteobjects
> +x11/qt6/qtscxml
> +x11/qt6/qtsensors
> +x11/qt6/qtvirtualkeyboard
> +x11/qt6/qtwayland
> 
> Packages not built this time:
> -archivers/deco
> -archivers/p7zip
> -archivers/p7zip,-main
> -archivers/p7zip,-rar
> -archivers/pecl-lzf,php74
> -archivers/pecl-lzf,php81
> -archivers/pecl-rar,php74
> -astro/celestia
> -astro/gnuastro
> -astro/kstars
> -astro/wcslib
> -astro/xephem
> -audio/adplay
> -audio/adplug
> -audio/audacious/plugins
> -audio/audacity
> -audio/calf
> -audio/cantata
> -audio/clementine
> -audio/cozy
> -audio/cplay
> -audio/curseradio
> -audio/deadbeef
> -audio/gogglesmm
> -audio/hydrogen
> -audio/liblastfm
> -audio/libopenmpt
> -audio/lmms
> -audio/mpd
> -audio/mumble
> -audio/mumble,-main
> -audio/mumble,-server
> -audio/musikcube
> -audio/musique
> -audio/ncmpcpp
> -audio/ocp
> -audio/picard
> -audio/puddletag
> -audio/pykaraoke
> -audio/quodlibet
> -audio/rhythmbox
> -audio/ruby-taglib,ruby30
> -audio/ruby-vorbis_comment,ruby30
> -audio/siren
> -audio/solfege
> -audio/xmcd
> -audio/xmms2
> -audio/xmms2-scrobbler
> -audio/zmusic
> -benchmarks/glmark2
> -benchmarks/netperf-wrapper,,-gui
> -benchmarks/netperf-wrapper,-gui
> -benchmarks/tsung
> -biology/emboss
> -cad/abc
> -cad/dxf2gcode
> -cad/fritzing
> -cad/geda-gaf
> -cad/gnucap
> -cad/lepton-eda
> -cad/librecad
> -cad/ngspice/libngspice
> -cad/ngspice/ngspice
> -cad/openscad
> -cad/opensta
> -cad/pcb
> -cad/pcb2gcode
> -cad/qelectrotech
> -cad/qflow
> -cad/yosys
> -chinese/libpinyin
> -comms/chirp
> -comms/conserver,ipmi
> -comms/conserver,ipmi,net
> -comms/fldigi
> -comms/gnuradio
> -comms/hamlib
> -comms/hamlib,
> -comms/hamlib,,-main
> -comms/hamlib,,-python
> 

Re: powerpc bulk build report

[George Koehler]

On Fri, 25 Feb 2022 12:44:43 -0700 (MST)
gkoeh...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Fri Feb  4 19:39:07 MST 2022
> Finished: Fri Feb 25 12:44:23 MST 2022
> Duration: 20 Days 17 hours 5 minutes
> 
> Built using OpenBSD 7.0-current (GENERIC) #992: Thu Feb  3 01:10:29 MST 2022
> 
> Built 9265 packages

This is the first bulk with a fixed cairo-1.17.4p1, which fixes
gtk+[23] apps.  The packages in this bulk need libX11.so.17.1, which
is older than the newest libX11.so.18.0, so I see messages like,

sylpheed:/usr/X11R6/lib/libX11.so.18.0: /usr/X11R6/lib/libX11.so.17.1:
WARNING: symbol(_XkeyTable) size mismatch, relink your program

I can still use sylpheed to send this mail.  The faster arches have
fixed these messages by rebuilding all the packages.

The 12 build failures include 7 real failures and 5 false positives.
The 7 real failures are

emulators/higanLLVM ERROR: out of memory
emulators/mednafen error: ... #if LIBCO_COMPROTECT
games/hyperrogue   ./langen: Segmentation fault (core dumped)
games/irrlamb  error: unknown FP unit 'sse'
lang/pcc-libs  error: expected ';' after top-level asm block
lang/racket-minimal./racketcgc: out of memory
math/coq   pkg_create: Error: *.cmo does not exist

The only new failure is racket.

The 5 false positives are spyder3, py3-opcua-widgets, gpodder,
rednotebook, py3-qtconsole.  These packages exist.  Near the end of
the bulk, macppc-1 tried to rebuild them without installing python 3,
and the rebuilds failed.
--George

> Build failures: 12
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/devel/spyder/spyder,python3.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/emulators/higan.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/emulators/mednafen.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/games/hyperrogue.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/games/irrlamb.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/lang/pcc/pcc-libs.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/lang/racket-minimal,no_jit.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/math/coq.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/misc/freeopcua/py-opcua-widgets,python3.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/net/gpodder.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/productivity/rednotebook.log
> http://build-failures.rhaalovely.net/powerpc/2022-02-04/shells/py-qtconsole,python3.log

Re: powerpc bulk build report

[George Koehler]

On Sat, 16 Oct 2021 17:43:35 +0100
Edd Barrett  wrote:

> On Sat, Oct 16, 2021 at 10:16:48AM -0600, c...@openbsd.org wrote:
> > http://build-failures.rhaalovely.net/powerpc/2021-09-28/games/odamex.log
> 
> > :1:9: error: macro name must be an identifier
> > #define -faltivec 1
> 
> Can you try this?

Edd, your diff pointed at the correct place in client/CMakeLists.txt.
I have a diff below, is my diff ok?

odamex uses OpenGL and macppc has trouble with OpenGL.  What works for
me is to run "GALLIUM_DRIVER=softpipe odamex" on a macppc G4 without
radeondrm.  Then the frame rate is too slow (press an arrow key, wait
5 seconds), so I can only try the first few menus.  Also, the title
screen (from doomdata) is tinted blue.  My G4 cpu has altivec; I tried
those menus with both the GENERIC kernel and a no-ALTIVEC kernel.

In client/CMakeLists.txt, remove -faltivec and pass -maltivec to just
one file.  This alone unbreaks the build on powerpc and powerpc64, but
the powerpc package would never call the -maltivec file (because clang
doesn't define __ALTIVEC__ in other files).  Add 2 more patches to
change __ALTIVEC__ to __powerpc__; my intent is to restore the
SDL_HasAltivec() check and call the -maltivec file if and only if the
powerpc cpu has altivec.

My powerpc64 isn't running X, so I didn't try to play my powerpc64
package.  clang for powerpc64 defaults to enabling -maltivec.

--George

Index: patches/patch-client_CMakeLists_txt
===
RCS file: /cvs/ports/games/odamex/patches/patch-client_CMakeLists_txt,v
retrieving revision 1.3
diff -u -p -r1.3 patch-client_CMakeLists_txt
--- patches/patch-client_CMakeLists_txt 29 Aug 2021 22:09:09 -  1.3
+++ patches/patch-client_CMakeLists_txt 17 Oct 2021 21:26:10 -
@@ -1,9 +1,12 @@
 $OpenBSD: patch-client_CMakeLists_txt,v 1.3 2021/08/29 22:09:09 sthen Exp $
 
+To fix powerpc* altivec, add -maltivec only in r_drawt_altivec.cpp,
+and allow r_draw.cpp to detect altivec at runtime.
+
 Index: client/CMakeLists.txt
 --- client/CMakeLists.txt.orig
 +++ client/CMakeLists.txt
-@@ -163,7 +163,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
+@@ -163,13 +163,14 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
  elseif(ODAMEX_TARGET_ARCH STREQUAL "i386")
if(NOT MSVC)
  # Pentium M has SSE2.
@@ -12,7 +15,15 @@ Index: client/CMakeLists.txt
else()
  target_compile_definitions(odamex PRIVATE /arch:SSE2)
endif()
-@@ -220,7 +220,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
+   message(STATUS "Default SIMD flags set to SSE2")
+ elseif(ODAMEX_TARGET_ARCH MATCHES "ppc")
+-  target_compile_definitions(odamex PRIVATE -faltivec)
++  set_source_files_properties(src/r_drawt_altivec.cpp
++PROPERTIES COMPILE_OPTIONS -maltivec)
+   message(STATUS "Default SIMD flags set to AltiVec")
+ endif()
+   else()
+@@ -220,7 +221,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
endif()
  
if(UNIX AND NOT APPLE)
Index: patches/patch-client_src_r_draw_cpp
===
RCS file: patches/patch-client_src_r_draw_cpp
diff -N patches/patch-client_src_r_draw_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-client_src_r_draw_cpp 17 Oct 2021 21:26:10 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+To fix powerpc* altivec, add -maltivec only in r_drawt_altivec.cpp,
+and allow r_draw.cpp to detect altivec at runtime.
+
+Index: client/src/r_draw.cpp
+--- client/src/r_draw.cpp.orig
 client/src/r_draw.cpp
+@@ -1511,7 +1511,7 @@ static bool detect_optimizations()
+   if (SDL_HasSSE2())
+   optimizations_available.push_back(OPTIMIZE_SSE2);
+   #endif
+-  #ifdef __ALTIVEC__
++  #ifdef __powerpc__
+   if (SDL_HasAltiVec())
+   optimizations_available.push_back(OPTIMIZE_ALTIVEC);
+   #endif
+@@ -1609,7 +1609,7 @@ void R_InitVectorizedDrawers()
+   r_dimpatchD = r_dimpatchD_MMX;
+   }
+   #endif
+-  #ifdef __ALTIVEC__
++  #ifdef __powerpc__
+   else if (optimize_kind == OPTIMIZE_ALTIVEC)
+   {
+   R_DrawSpanD = R_DrawSpanD_c;
// TODO
Index: patches/patch-common_r_draw_h
===
RCS file: patches/patch-common_r_draw_h
diff -N patches/patch-common_r_draw_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-common_r_draw_h   17 Oct 2021 21:26:10 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+To fix powerpc* altivec, add -maltivec only in r_drawt_altivec.cpp,
+and allow r_draw.cpp to detect altivec at runtime.
+
+Index: common/r_draw.h
+--- common/r_draw.h.orig
 common/r_draw.h
+@@ -174,7 +174,7 @@ void R_DrawSlopeSpanD_MMX(void);
+ void r_dimpatchD_MMX(IWindowSurface*, argb_t color, int alpha, int x1, int 
y1, int w, int h);
+ #endif
+ 
+-#ifdef __ALTIVEC__
++#ifdef __powerpc__
+ void R_DrawSpanD_ALTIVEC(void);
+ 

Re: powerpc bulk build report

[Brad Smith]

On Sat, Oct 16, 2021 at 11:32:39PM -0400, George Koehler wrote:
> On Sat, 16 Oct 2021 17:43:35 +0100
> Edd Barrett  wrote:
> 
> > On Sat, Oct 16, 2021 at 10:16:48AM -0600, c...@openbsd.org wrote:
> > > http://build-failures.rhaalovely.net/powerpc/2021-09-28/games/odamex.log
> > 
> > > :1:9: error: macro name must be an identifier
> > > #define -faltivec 1
> > 
> > Can you try this?
> 
> Fails because clang rejects -faltivec,
>   c++: error: the clang compiler does not support 'faltivec',
>   please use -maltivec and include altivec.h explicitly
> 
> I suspect that -faltivec was only for Apple gcc on Mac OS X (because
> our ports-gcc also rejects it).  It would also be wrong to build every
> file with -maltivec, because some macppc models (G3) have no altivec.
> It might be correct to build only r_drawt_altivec.cpp with -maltivec,
> because r_draw.cpp checks SDL_HasAltiVec().  Either that, or just
> disable altivec on powerpc.
> 
> I will try to unbreak the build on my macppc.
> --George

When I was looking at this I was thinking something like this, but I
don't have hw to test with.


Index: Makefile
===
RCS file: /home/cvs/ports/games/odamex/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile13 Sep 2021 19:51:30 -  1.7
+++ Makefile16 Oct 2021 18:54:31 -
@@ -33,6 +33,10 @@ CONFIGURE_ENV += CXXFLAGS=-I${LOCALBASE}
LDFLAGS=-L${LOCALBASE}/lib
 CONFIGURE_ARGS +=  -DNO_AG-ODALAUNCH_TARGET=YES
 
+.if ${MACHINE_ARCH} == "powerpc"
+CONFIGURE_ARGS +=  -DUSE_DEFAULT_SIMD=OFF
+.endif
+
 LIB_DEPENDS =  x11/wxWidgets \
audio/portmidi \
graphics/png \

> > Index: patches/patch-client_CMakeLists_txt
> > ===
> > RCS file: /cvs/ports/games/odamex/patches/patch-client_CMakeLists_txt,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 patch-client_CMakeLists_txt
> > --- patches/patch-client_CMakeLists_txt 29 Aug 2021 22:09:09 -  
> > 1.3
> > +++ patches/patch-client_CMakeLists_txt 16 Oct 2021 16:41:49 -
> > @@ -3,7 +3,7 @@ $OpenBSD: patch-client_CMakeLists_txt,v 
> >  Index: client/CMakeLists.txt
> >  --- client/CMakeLists.txt.orig
> >  +++ client/CMakeLists.txt
> > -@@ -163,7 +163,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
> > +@@ -163,13 +163,13 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
> >   elseif(ODAMEX_TARGET_ARCH STREQUAL "i386")
> > if(NOT MSVC)
> >   # Pentium M has SSE2.
> > @@ -12,6 +12,13 @@ Index: client/CMakeLists.txt
> > else()
> >   target_compile_definitions(odamex PRIVATE /arch:SSE2)
> > endif()
> > +   message(STATUS "Default SIMD flags set to SSE2")
> > + elseif(ODAMEX_TARGET_ARCH MATCHES "ppc")
> > +-  target_compile_definitions(odamex PRIVATE -faltivec)
> > ++  target_compile_options(odamex PRIVATE -faltivec)
> > +   message(STATUS "Default SIMD flags set to AltiVec")
> > + endif()
> > +   else()
> >  @@ -220,7 +220,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
> > endif()
> >   
> > -- 
> > Best Regards
> > Edd Barrett
> > 
> > https://www.theunixzoo.co.uk
> > 
> 
> 
> -- 
> George Koehler 
> 

Re: powerpc bulk build report

[George Koehler]

On Sat, 16 Oct 2021 17:43:35 +0100
Edd Barrett  wrote:

> On Sat, Oct 16, 2021 at 10:16:48AM -0600, c...@openbsd.org wrote:
> > http://build-failures.rhaalovely.net/powerpc/2021-09-28/games/odamex.log
> 
> > :1:9: error: macro name must be an identifier
> > #define -faltivec 1
> 
> Can you try this?

Fails because clang rejects -faltivec,
  c++: error: the clang compiler does not support 'faltivec',
  please use -maltivec and include altivec.h explicitly

I suspect that -faltivec was only for Apple gcc on Mac OS X (because
our ports-gcc also rejects it).  It would also be wrong to build every
file with -maltivec, because some macppc models (G3) have no altivec.
It might be correct to build only r_drawt_altivec.cpp with -maltivec,
because r_draw.cpp checks SDL_HasAltiVec().  Either that, or just
disable altivec on powerpc.

I will try to unbreak the build on my macppc.
--George

> Index: patches/patch-client_CMakeLists_txt
> ===
> RCS file: /cvs/ports/games/odamex/patches/patch-client_CMakeLists_txt,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-client_CMakeLists_txt
> --- patches/patch-client_CMakeLists_txt   29 Aug 2021 22:09:09 -  
> 1.3
> +++ patches/patch-client_CMakeLists_txt   16 Oct 2021 16:41:49 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-client_CMakeLists_txt,v 
>  Index: client/CMakeLists.txt
>  --- client/CMakeLists.txt.orig
>  +++ client/CMakeLists.txt
> -@@ -163,7 +163,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
> +@@ -163,13 +163,13 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
>   elseif(ODAMEX_TARGET_ARCH STREQUAL "i386")
> if(NOT MSVC)
>   # Pentium M has SSE2.
> @@ -12,6 +12,13 @@ Index: client/CMakeLists.txt
> else()
>   target_compile_definitions(odamex PRIVATE /arch:SSE2)
> endif()
> +   message(STATUS "Default SIMD flags set to SSE2")
> + elseif(ODAMEX_TARGET_ARCH MATCHES "ppc")
> +-  target_compile_definitions(odamex PRIVATE -faltivec)
> ++  target_compile_options(odamex PRIVATE -faltivec)
> +   message(STATUS "Default SIMD flags set to AltiVec")
> + endif()
> +   else()
>  @@ -220,7 +220,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
> endif()
>   
> -- 
> Best Regards
> Edd Barrett
> 
> https://www.theunixzoo.co.uk
> 


-- 
George Koehler 

Re: powerpc bulk build report

[Edd Barrett]

On Sat, Oct 16, 2021 at 10:16:48AM -0600, c...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/powerpc/2021-09-28/games/odamex.log

> :1:9: error: macro name must be an identifier
> #define -faltivec 1

Can you try this?

Index: patches/patch-client_CMakeLists_txt
===
RCS file: /cvs/ports/games/odamex/patches/patch-client_CMakeLists_txt,v
retrieving revision 1.3
diff -u -p -r1.3 patch-client_CMakeLists_txt
--- patches/patch-client_CMakeLists_txt 29 Aug 2021 22:09:09 -  1.3
+++ patches/patch-client_CMakeLists_txt 16 Oct 2021 16:41:49 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-client_CMakeLists_txt,v 
 Index: client/CMakeLists.txt
 --- client/CMakeLists.txt.orig
 +++ client/CMakeLists.txt
-@@ -163,7 +163,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
+@@ -163,13 +163,13 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
  elseif(ODAMEX_TARGET_ARCH STREQUAL "i386")
if(NOT MSVC)
  # Pentium M has SSE2.
@@ -12,6 +12,13 @@ Index: client/CMakeLists.txt
else()
  target_compile_definitions(odamex PRIVATE /arch:SSE2)
endif()
+   message(STATUS "Default SIMD flags set to SSE2")
+ elseif(ODAMEX_TARGET_ARCH MATCHES "ppc")
+-  target_compile_definitions(odamex PRIVATE -faltivec)
++  target_compile_options(odamex PRIVATE -faltivec)
+   message(STATUS "Default SIMD flags set to AltiVec")
+ endif()
+   else()
 @@ -220,7 +220,7 @@ if(TARGET SDL2::SDL2 OR TARGET SDL::SDL)
endif()
  
-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: powerpc bulk build report

[Charlene Wendling]

It's not done yet ;)

One of the machines lost some nfs mounts, i'm restarting the bulk atm ;)

On Fri, 15 Oct 2021 09:13:44 -0600 (MDT)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Tue Sep 28 01:49:06 MDT 2021
> Finished: Fri Oct 15 09:12:08 MDT 2021
> Duration: 17 Days 7 hours 23 minutes
> 
> Built using OpenBSD 7.0 (GENERIC) #939: Mon Sep 27 18:51:05 MDT 2021
> 

Re: powerpc bulk build report

[Charlene Wendling]

Hi,

On Thu, 9 Sep 2021 22:27:27 +0200
Alexander Bluhm  wrote:

> On Thu, Sep 09, 2021 at 08:56:52AM -0600, c...@openbsd.org wrote:
> > http://build-failures.rhaalovely.net/powerpc/2021-08-21/misc/open62541,ns0_full.log
> 
> /usr/obj/ports/open62541-1.0.6-ns0_full/bin/cc ...
> namespace0_generated.c Segmentation fault (core dumped) 
> ninja: build stopped: subcommand failed.
> 
> The compiler needs a lot of stack memory.  The ulimit -s should be
> raised to 8 GB.  Feel free to skip the ns0_full flavor on small
> memory architectures.

I was going to _very_ sloppily mark the flavor NOT_FOR_ARCHS, until
sthen noticed that 8 GB of stack memory is a bit too much.

I found out after some research that i was using an old login.conf,
and definitely have said no to sysmerge at one point. Sigh.

Using the latest login.conf, where the stacksize is raised to 8MB by
default for pbuild, fixes the build at home, it should be fine on the
bulk machines as well.

Thanks for your feedback :)

Charlène.

> bluhm
> 

Re: powerpc bulk build report

[Alexander Bluhm]

On Thu, Sep 09, 2021 at 08:56:52AM -0600, c...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/powerpc/2021-08-21/misc/open62541,ns0_full.log

/usr/obj/ports/open62541-1.0.6-ns0_full/bin/cc ... namespace0_generated.c
Segmentation fault (core dumped) 
ninja: build stopped: subcommand failed.

The compiler needs a lot of stack memory.  The ulimit -s should be
raised to 8 GB.  Feel free to skip the ns0_full flavor on small
memory architectures.

bluhm

Re: powerpc bulk build report

[Charlene Wendling]

Hi,

This is the first bulk done with LLD as the default linker.

Please test your favorite packages and report issues if you have some :)

On Thu, 9 Sep 2021 08:56:52 -0600 (MDT)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Sat Aug 21 14:27:57 MDT 2021
> Finished: Thu Sep  9 08:56:41 MDT 2021
> Duration: 18 Days 18 hours 29 minutes

It looks like LLD is making bulks a bit faster (actually macppc-1 was
down for 2 days, hence the extra delay)

> Built using OpenBSD 7.0-beta (GENERIC) #926: Fri Aug 20 18:11:14 MDT
> 2021
> 
> Built 9517 packages
> [...]
> 
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/powerpc/2021-08-21/summary.log
> 
> Build failures: 10

> http://build-failures.rhaalovely.net/powerpc/2021-08-21/devel/xtensa-lx106-elf/gdb.log

gkoehler@ is already providing a diff for libgmp:

https://marc.info/?l=openbsd-ports=163116370903235=2

> http://build-failures.rhaalovely.net/powerpc/2021-08-21/mail/rspamd,hyperscan.log

rspamd is not built on 32 bit archs for now.

> http://build-failures.rhaalovely.net/powerpc/2021-08-21/misc/open62541,ns0_full.log

This one was already present during the previous bulk, but no report has
been sent, it's not due to LLD.

Re: powerpc bulk build report

[Charlene Wendling]

Hi,

On Sun, 21 Feb 2021 13:29:53 -0700 (MST)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Thu Feb  4 17:42:22 MST 2021
> Finished: Sun Feb 21 13:29:25 MST 2021
> Duration: 16 Days 19 hours 47 minutes

> http://build-failures.rhaalovely.net/powerpc/2021-02-04/graphics/openvdb.log

This new port won't be built on powerpc, see
https://marc.info/?l=openbsd-ports-cvs=161387035817473=2

> http://build-failures.rhaalovely.net/powerpc/2021-02-04/shells/ksh93.log

Marked BROKEN, as seen on powerpc64.

Re: powerpc bulk build report

[Charlene Wendling]

On Wed, 3 Feb 2021 23:12:13 -0700 (MST)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Mon Jan 18 10:28:09 MST 2021
> Finished: Wed Feb  3 23:11:47 MST 2021
> Duration: 16 Days 12 hours 44 minutes
> 
> Built using OpenBSD 6.8-current (GENERIC) #830: Sun Jan 17 08:10:13
> MST 2021

Some comments:

> http://build-failures.rhaalovely.net/powerpc/2021-01-18/games/valyriatear.log

It won't be built anymore on BE_ARCHS until upstream fix their code.

> http://build-failures.rhaalovely.net/powerpc/2021-01-18/x11/e17/elementary.log

It has been removed from CVS.

> http://build-failures.rhaalovely.net/powerpc/2021-01-18/net/ntopng.log
> http://build-failures.rhaalovely.net/powerpc/2021-01-18/net/pmacct,postgresql.log

It's a temporary failure due to a desync between the kernel used and the
ports tree, see https://github.com/openbsd/src/commit/ff78d6edd
They'll be back once the next bulk is finished.

Re: powerpc bulk build report

[Otto Moerbeek]

On Tue, Dec 15, 2020 at 03:56:19PM +0100, Charlene Wendling wrote:

> On Tue, 15 Dec 2020 08:42:58 +0100
> Otto Moerbeek wrote:
> 
> > On Tue, Dec 15, 2020 at 02:28:01AM -0500, Brad Smith wrote:
> > 
> > > On Tue, Dec 15, 2020 at 08:19:13AM +0100, Otto Moerbeek wrote:
> > > > On Mon, Dec 14, 2020 at 11:05:45AM +0100, Otto Moerbeek wrote:
> > > > 
> > > > > On Mon, Dec 14, 2020 at 02:52:02AM -0500, Brad Smith wrote:
> > > > > 
> > > > > > On 12/14/2020 2:39 AM, Otto Moerbeek wrote:
> > > > > > > On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:
> > > > > > > 
> > > > > > > > I'm on my phone and don't have another log to compare to
> > > > > > > > but this line stuck out to me..
> > > > > > > > 
> > > > > > > > checking for the toolset name used by Boost for c++...
> > > > > > > > gcc42 -gcc
> > > > > > > That configure line is alwasy reported, also on other
> > > > > > > platforms, since it does not seem to cause issues there I
> > > > > > > never looked into it.
> > > > > > 
> > > > > > Could be a potential issue. Just something to consider. I'm
> > > > > > curious to see what it says on amd64 and i386.
> > > > > 
> > > > > amd64 and arm64:
> > > > > 
> > > > >   checking for the toolset name used by Boost for c++...
> > > > > gcc42 -gcc
> > > > > 
> > > > > I don't have an i386 at thand,
> > > > > 
> > > > >   -Otto
> > > > > 
> > > > 
> > > > Removing pacthes/patch-libs_context_build_Jamfile_v2 in boost and
> > > > bumping the revision produces a boost-md that has the correct
> > > > symbols. Test build for pdns_recursor is still running, but it
> > > > now detects the boost context functionality correctly.
> > > > 
> > > > As for the toolchain configure check in pdns_recursor: the value
> > > > produced is not used by the build afaiks. I'll put it on my list
> > > > of things to look at, but it's not high priority.
> > > 
> > > Ah, yes. I noticed that was merged upstream and released with 1.69
> > > when looking at newer Boost. The patch there was mismerged by
> > > patch(1).
> > 
> > Yes, ok,
> > 
> > -Otto
> 
> This also fixes that build failure:
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-11-27/net/icinga/core2,-main.log
> 
> Thanks a lot! OK cwen@

I can now confirm pdns_recursor builds and runs fine wit this as well,

-Otto

> 
> > > 
> > > 
> > > Index: Makefile
> > > ===
> > > RCS file: /home/cvs/ports/devel/boost/Makefile,v
> > > retrieving revision 1.104
> > > diff -u -p -u -p -r1.104 Makefile
> > > --- Makefile  26 Nov 2020 00:08:36 -  1.104
> > > +++ Makefile  15 Dec 2020 07:24:21 -
> > > @@ -6,7 +6,7 @@ COMMENT-main= free peer-reviewed portabl
> > >  COMMENT-md=  machine-dependent libraries for boost
> > >  
> > >  VERSION= 1.70.0
> > > -REVISION=0
> > > +REVISION=1
> > >  DISTNAME=boost_${VERSION:S/./_/g}
> > >  PKGNAME-main=boost-${VERSION}
> > >  PKGNAME-md=  boost-md-${VERSION}
> > > Index: patches/patch-libs_context_build_Jamfile_v2
> > > ===
> > > RCS file: patches/patch-libs_context_build_Jamfile_v2
> > > diff -N patches/patch-libs_context_build_Jamfile_v2
> > > --- patches/patch-libs_context_build_Jamfile_v2   5 Nov 2020
> > > 11:23:03 -1.3 +++ /dev/null   1 Jan 1970 00:00:00
> > > - @@ -1,17 +0,0 @@
> > > -$OpenBSD: patch-libs_context_build_Jamfile_v2,v 1.3 2020/11/05
> > > 11:23:03 sthen Exp $ -
> > > -ppc32_sysv_elf has 2 instances of "clang".
> > > -The second "clang" should be "gcc".
> > > -
> > > -Index: libs/context/build/Jamfile.v2
> > >  libs/context/build/Jamfile.v2.orig
> > > -+++ libs/context/build/Jamfile.v2
> > > -@@ -280,7 +280,7 @@ alias asm_sources
> > > -  32
> > > -  power
> > > -  elf
> > > -- clang
> > > -+ gcc
> > > -;
> > > - 
> > > - alias asm_sources
> > 

Re: powerpc bulk build report

[Charlene Wendling]

On Tue, 15 Dec 2020 08:42:58 +0100
Otto Moerbeek wrote:

> On Tue, Dec 15, 2020 at 02:28:01AM -0500, Brad Smith wrote:
> 
> > On Tue, Dec 15, 2020 at 08:19:13AM +0100, Otto Moerbeek wrote:
> > > On Mon, Dec 14, 2020 at 11:05:45AM +0100, Otto Moerbeek wrote:
> > > 
> > > > On Mon, Dec 14, 2020 at 02:52:02AM -0500, Brad Smith wrote:
> > > > 
> > > > > On 12/14/2020 2:39 AM, Otto Moerbeek wrote:
> > > > > > On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:
> > > > > > 
> > > > > > > I'm on my phone and don't have another log to compare to
> > > > > > > but this line stuck out to me..
> > > > > > > 
> > > > > > > checking for the toolset name used by Boost for c++...
> > > > > > > gcc42 -gcc
> > > > > > That configure line is alwasy reported, also on other
> > > > > > platforms, since it does not seem to cause issues there I
> > > > > > never looked into it.
> > > > > 
> > > > > Could be a potential issue. Just something to consider. I'm
> > > > > curious to see what it says on amd64 and i386.
> > > > 
> > > > amd64 and arm64:
> > > > 
> > > > checking for the toolset name used by Boost for c++...
> > > > gcc42 -gcc
> > > > 
> > > > I don't have an i386 at thand,
> > > > 
> > > > -Otto
> > > > 
> > > 
> > > Removing pacthes/patch-libs_context_build_Jamfile_v2 in boost and
> > > bumping the revision produces a boost-md that has the correct
> > > symbols. Test build for pdns_recursor is still running, but it
> > > now detects the boost context functionality correctly.
> > > 
> > > As for the toolchain configure check in pdns_recursor: the value
> > > produced is not used by the build afaiks. I'll put it on my list
> > > of things to look at, but it's not high priority.
> > 
> > Ah, yes. I noticed that was merged upstream and released with 1.69
> > when looking at newer Boost. The patch there was mismerged by
> > patch(1).
> 
> Yes, ok,
> 
>   -Otto

This also fixes that build failure:

> http://build-failures.rhaalovely.net/powerpc/2020-11-27/net/icinga/core2,-main.log

Thanks a lot! OK cwen@

> > 
> > 
> > Index: Makefile
> > ===
> > RCS file: /home/cvs/ports/devel/boost/Makefile,v
> > retrieving revision 1.104
> > diff -u -p -u -p -r1.104 Makefile
> > --- Makefile26 Nov 2020 00:08:36 -  1.104
> > +++ Makefile15 Dec 2020 07:24:21 -
> > @@ -6,7 +6,7 @@ COMMENT-main=   free peer-reviewed portabl
> >  COMMENT-md=machine-dependent libraries for boost
> >  
> >  VERSION=   1.70.0
> > -REVISION=  0
> > +REVISION=  1
> >  DISTNAME=  boost_${VERSION:S/./_/g}
> >  PKGNAME-main=  boost-${VERSION}
> >  PKGNAME-md=boost-md-${VERSION}
> > Index: patches/patch-libs_context_build_Jamfile_v2
> > ===
> > RCS file: patches/patch-libs_context_build_Jamfile_v2
> > diff -N patches/patch-libs_context_build_Jamfile_v2
> > --- patches/patch-libs_context_build_Jamfile_v2 5 Nov 2020
> > 11:23:03 -  1.3 +++ /dev/null   1 Jan 1970 00:00:00
> > - @@ -1,17 +0,0 @@
> > -$OpenBSD: patch-libs_context_build_Jamfile_v2,v 1.3 2020/11/05
> > 11:23:03 sthen Exp $ -
> > -ppc32_sysv_elf has 2 instances of "clang".
> > -The second "clang" should be "gcc".
> > -
> > -Index: libs/context/build/Jamfile.v2
> >  libs/context/build/Jamfile.v2.orig
> > -+++ libs/context/build/Jamfile.v2
> > -@@ -280,7 +280,7 @@ alias asm_sources
> > -  32
> > -  power
> > -  elf
> > -- clang
> > -+ gcc
> > -;
> > - 
> > - alias asm_sources
> 

Re: powerpc bulk build report

[Brad Smith]

On Tue, Dec 15, 2020 at 08:19:13AM +0100, Otto Moerbeek wrote:
> On Mon, Dec 14, 2020 at 11:05:45AM +0100, Otto Moerbeek wrote:
> 
> > On Mon, Dec 14, 2020 at 02:52:02AM -0500, Brad Smith wrote:
> > 
> > > On 12/14/2020 2:39 AM, Otto Moerbeek wrote:
> > > > On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:
> > > > 
> > > > > I'm on my phone and don't have another log to compare to but this 
> > > > > line stuck
> > > > > out to me..
> > > > > 
> > > > > checking for the toolset name used by Boost for c++... gcc42 -gcc
> > > > That configure line is alwasy reported, also on other platforms, since
> > > > it does not seem to cause issues there I never looked into it.
> > > 
> > > Could be a potential issue. Just something to consider. I'm curious to see
> > > what it says on amd64 and i386.
> > 
> > amd64 and arm64:
> > 
> > checking for the toolset name used by Boost for c++... gcc42 -gcc
> > 
> > I don't have an i386 at thand,
> > 
> > -Otto
> > 
> 
> Removing pacthes/patch-libs_context_build_Jamfile_v2 in boost and
> bumping the revision produces a boost-md that has the correct symbols.
> Test build for pdns_recursor is still running, but it now detects the
> boost context functionality correctly.
> 
> As for the toolchain configure check in pdns_recursor: the value
> produced is not used by the build afaiks. I'll put it on my list of
> things to look at, but it's not high priority.

Ah, yes. I noticed that was merged upstream and released with 1.69 when
looking at newer Boost. The patch there was mismerged by patch(1).


Index: Makefile
===
RCS file: /home/cvs/ports/devel/boost/Makefile,v
retrieving revision 1.104
diff -u -p -u -p -r1.104 Makefile
--- Makefile26 Nov 2020 00:08:36 -  1.104
+++ Makefile15 Dec 2020 07:24:21 -
@@ -6,7 +6,7 @@ COMMENT-main=   free peer-reviewed portabl
 COMMENT-md=machine-dependent libraries for boost
 
 VERSION=   1.70.0
-REVISION=  0
+REVISION=  1
 DISTNAME=  boost_${VERSION:S/./_/g}
 PKGNAME-main=  boost-${VERSION}
 PKGNAME-md=boost-md-${VERSION}
Index: patches/patch-libs_context_build_Jamfile_v2
===
RCS file: patches/patch-libs_context_build_Jamfile_v2
diff -N patches/patch-libs_context_build_Jamfile_v2
--- patches/patch-libs_context_build_Jamfile_v2 5 Nov 2020 11:23:03 -   
1.3
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-libs_context_build_Jamfile_v2,v 1.3 2020/11/05 11:23:03 sthen 
Exp $
-
-ppc32_sysv_elf has 2 instances of "clang".
-The second "clang" should be "gcc".
-
-Index: libs/context/build/Jamfile.v2
 libs/context/build/Jamfile.v2.orig
-+++ libs/context/build/Jamfile.v2
-@@ -280,7 +280,7 @@ alias asm_sources
-  32
-  power
-  elf
-- clang
-+ gcc
-;
- 
- alias asm_sources

Re: powerpc bulk build report

[Otto Moerbeek]

On Tue, Dec 15, 2020 at 02:28:01AM -0500, Brad Smith wrote:

> On Tue, Dec 15, 2020 at 08:19:13AM +0100, Otto Moerbeek wrote:
> > On Mon, Dec 14, 2020 at 11:05:45AM +0100, Otto Moerbeek wrote:
> > 
> > > On Mon, Dec 14, 2020 at 02:52:02AM -0500, Brad Smith wrote:
> > > 
> > > > On 12/14/2020 2:39 AM, Otto Moerbeek wrote:
> > > > > On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:
> > > > > 
> > > > > > I'm on my phone and don't have another log to compare to but this 
> > > > > > line stuck
> > > > > > out to me..
> > > > > > 
> > > > > > checking for the toolset name used by Boost for c++... gcc42 -gcc
> > > > > That configure line is alwasy reported, also on other platforms, since
> > > > > it does not seem to cause issues there I never looked into it.
> > > > 
> > > > Could be a potential issue. Just something to consider. I'm curious to 
> > > > see
> > > > what it says on amd64 and i386.
> > > 
> > > amd64 and arm64:
> > > 
> > >   checking for the toolset name used by Boost for c++... gcc42 -gcc
> > > 
> > > I don't have an i386 at thand,
> > > 
> > >   -Otto
> > > 
> > 
> > Removing pacthes/patch-libs_context_build_Jamfile_v2 in boost and
> > bumping the revision produces a boost-md that has the correct symbols.
> > Test build for pdns_recursor is still running, but it now detects the
> > boost context functionality correctly.
> > 
> > As for the toolchain configure check in pdns_recursor: the value
> > produced is not used by the build afaiks. I'll put it on my list of
> > things to look at, but it's not high priority.
> 
> Ah, yes. I noticed that was merged upstream and released with 1.69 when
> looking at newer Boost. The patch there was mismerged by patch(1).

Yes, ok,

-Otto

> 
> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/devel/boost/Makefile,v
> retrieving revision 1.104
> diff -u -p -u -p -r1.104 Makefile
> --- Makefile  26 Nov 2020 00:08:36 -  1.104
> +++ Makefile  15 Dec 2020 07:24:21 -
> @@ -6,7 +6,7 @@ COMMENT-main= free peer-reviewed portabl
>  COMMENT-md=  machine-dependent libraries for boost
>  
>  VERSION= 1.70.0
> -REVISION=0
> +REVISION=1
>  DISTNAME=boost_${VERSION:S/./_/g}
>  PKGNAME-main=boost-${VERSION}
>  PKGNAME-md=  boost-md-${VERSION}
> Index: patches/patch-libs_context_build_Jamfile_v2
> ===
> RCS file: patches/patch-libs_context_build_Jamfile_v2
> diff -N patches/patch-libs_context_build_Jamfile_v2
> --- patches/patch-libs_context_build_Jamfile_v2   5 Nov 2020 11:23:03 
> -   1.3
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,17 +0,0 @@
> -$OpenBSD: patch-libs_context_build_Jamfile_v2,v 1.3 2020/11/05 11:23:03 
> sthen Exp $
> -
> -ppc32_sysv_elf has 2 instances of "clang".
> -The second "clang" should be "gcc".
> -
> -Index: libs/context/build/Jamfile.v2
>  libs/context/build/Jamfile.v2.orig
> -+++ libs/context/build/Jamfile.v2
> -@@ -280,7 +280,7 @@ alias asm_sources
> -  32
> -  power
> -  elf
> -- clang
> -+ gcc
> -;
> - 
> - alias asm_sources

Re: powerpc bulk build report

[Otto Moerbeek]

On Mon, Dec 14, 2020 at 11:05:45AM +0100, Otto Moerbeek wrote:

> On Mon, Dec 14, 2020 at 02:52:02AM -0500, Brad Smith wrote:
> 
> > On 12/14/2020 2:39 AM, Otto Moerbeek wrote:
> > > On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:
> > > 
> > > > I'm on my phone and don't have another log to compare to but this line 
> > > > stuck
> > > > out to me..
> > > > 
> > > > checking for the toolset name used by Boost for c++... gcc42 -gcc
> > > That configure line is alwasy reported, also on other platforms, since
> > > it does not seem to cause issues there I never looked into it.
> > 
> > Could be a potential issue. Just something to consider. I'm curious to see
> > what it says on amd64 and i386.
> 
> amd64 and arm64:
> 
>   checking for the toolset name used by Boost for c++... gcc42 -gcc
> 
> I don't have an i386 at thand,
> 
>   -Otto
> 

Removing pacthes/patch-libs_context_build_Jamfile_v2 in boost and
bumping the revision produces a boost-md that has the correct symbols.
Test build for pdns_recursor is still running, but it now detects the
boost context functionality correctly.

As for the toolchain configure check in pdns_recursor: the value
produced is not used by the build afaiks. I'll put it on my list of
things to look at, but it's not high priority.

-Otto

Re: powerpc bulk build report

[Brad Smith]

On 12/14/2020 2:39 AM, Otto Moerbeek wrote:

On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:


I'm on my phone and don't have another log to compare to but this line stuck
out to me..

checking for the toolset name used by Boost for c++... gcc42 -gcc

That configure line is alwasy reported, also on other platforms, since
it does not seem to cause issues there I never looked into it.


Could be a potential issue. Just something to consider. I'm curious to see
what it says on amd64 and i386.

Re: powerpc bulk build report

[Brad Smith]

I'm on my phone and don't have another log to compare to but this line 
stuck out to me..


checking for the toolset name used by Boost for c++... gcc42 -gcc

On December 14, 2020 2:31:05 a.m. Otto Moerbeek  wrote:


On Mon, Dec 14, 2020 at 12:14:19AM -0700, c...@openbsd.org wrote:


http://build-failures.rhaalovely.net/powerpc/2020-11-27/net/powerdns_recursor.log


The root cause is that boost-md gets build with the userland context
switching primitives missing. I suppose something went wrong with the
recent boost update. I'll try to find out where if nobody beats me to
it.

-Otto



Sent with Aqua Mail for Android
https://www.mobisystems.com/aqua-mail

Re: powerpc bulk build report

[Otto Moerbeek]

On Mon, Dec 14, 2020 at 02:52:02AM -0500, Brad Smith wrote:

> On 12/14/2020 2:39 AM, Otto Moerbeek wrote:
> > On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:
> > 
> > > I'm on my phone and don't have another log to compare to but this line 
> > > stuck
> > > out to me..
> > > 
> > > checking for the toolset name used by Boost for c++... gcc42 -gcc
> > That configure line is alwasy reported, also on other platforms, since
> > it does not seem to cause issues there I never looked into it.
> 
> Could be a potential issue. Just something to consider. I'm curious to see
> what it says on amd64 and i386.

amd64 and arm64:

checking for the toolset name used by Boost for c++... gcc42 -gcc

I don't have an i386 at thand,

-Otto

Re: powerpc bulk build report

[Otto Moerbeek]

On Mon, Dec 14, 2020 at 02:36:37AM -0500, Brad Smith wrote:

> I'm on my phone and don't have another log to compare to but this line stuck
> out to me..
> 
> checking for the toolset name used by Boost for c++... gcc42 -gcc

That configure line is alwasy reported, also on other platforms, since
it does not seem to cause issues there I never looked into it.

-Otto

> 
> On December 14, 2020 2:31:05 a.m. Otto Moerbeek  wrote:
> 
> > On Mon, Dec 14, 2020 at 12:14:19AM -0700, c...@openbsd.org wrote:
> > 
> > > http://build-failures.rhaalovely.net/powerpc/2020-11-27/net/powerdns_recursor.log
> > 
> > The root cause is that boost-md gets build with the userland context
> > switching primitives missing. I suppose something went wrong with the
> > recent boost update. I'll try to find out where if nobody beats me to
> > it.
> > 
> > -Otto
> 
> 
> Sent with Aqua Mail for Android
> https://www.mobisystems.com/aqua-mail

Re: powerpc bulk build report

[Otto Moerbeek]

On Mon, Dec 14, 2020 at 12:14:19AM -0700, c...@openbsd.org wrote:

> http://build-failures.rhaalovely.net/powerpc/2020-11-27/net/powerdns_recursor.log

The root cause is that boost-md gets build with the userland context
switching primitives missing. I suppose something went wrong with the
recent boost update. I'll try to find out where if nobody beats me to
it.

-Otto

Re: powerpc bulk build report

[Charlene Wendling]

Hi,

On Mon, 29 Jun 2020 11:45:14 -0600 (MDT)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Sat Jun 13 07:45:16 MDT 2020
> Finished: Mon Jun 29 11:45:00 MDT 2020
> Duration: 16 Days 4 hours 0 minutes
> 
> Built using OpenBSD 6.7-current (GENERIC) #735: Fri Jun 12 08:20:27
> MDT 2020
> 
> Built 9822 packages

This bulk has been shorter and with less packages because it has
been started after kde4 has been mostly unhooked, but before Rafael
imported dozens of new kf5 ports.

Some GNUstep-related software that used to be broken have been built
again, runtime should be wrong [0]; this explains some failures
below. Maybe^W i'll try again with my fix for x11/gnustep/make.

MATE is working since last bulk [1]. GNOME still lacks gnome-session
and gnome-shell, now that spidermonkey68 is rust-free it may be 
available again soon :)

> http://build-failures.rhaalovely.net/powerpc/2020-06-13/devel/geany.log

I've a fix for it [2], despite my assumptions being wrong.

Charlène.


[0] https://marc.info/?l=openbsd-ports=158722515929053=2
[1] https://bsd.network/web/statuses/104336811837102326
[2] https://marc.info/?l=openbsd-ports=159188140009019=2

> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/summary.log
> 
> Build failures: 15

> http://build-failures.rhaalovely.net/powerpc/2020-06-13/emulators/frodo.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/games/hyperrogue.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/games/valyriatear.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/lang/gforth.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/lang/squeak/vm.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/shells/ksh93.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/sysutils/libvirt.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/www/sope.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/x11/agar/agar.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/x11/e17/elementary.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/x11/gnustep/dbuskit.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/x11/gnustep/gui.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/x11/gnustep/performance.log
> http://build-failures.rhaalovely.net/powerpc/2020-06-13/x11/kde4/pimlibs.log

Re: powerpc bulk build report

[Charlene Wendling]

On Fri, 12 Jun 2020 16:04:22 -0600 (MDT)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Tue May 26 11:12:39 MDT 2020
> Finished: Fri Jun 12 16:04:08 MDT 2020
> Duration: 17 Days 4 hours 51 minutes

^ We swapped some monsters that failed at runtime for GNOME/MATE 
stuff :)

> Built using OpenBSD 6.7-current (GENERIC) #722: Mon May 25 18:07:09
> MDT 2020
> 
> Built 9939 packages

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/cad/openscad.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-26/databases/sqlitebrowser.log

I'll commit the fix just after that mail

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/devel/geany.log

https://marc.info/?l=openbsd-ports=159188140009019=2

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/mail/kopano/core.log

Fixed, won't build on ld.bfd archs again

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/security/aircrack-ng.log

https://marc.info/?l=openbsd-ports=159141021925207=2

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/x11/gnome/builder.log

Fixed, but it requires also that uncommitted fix for libdazzle:

https://marc.info/?l=openbsd-ports=159199473212267=2

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/x11/gnome/eog.log

Rust only, it wasn't and won't be available, fixed.

> http://build-failures.rhaalovely.net/powerpc/2020-05-26/x11/qt5/qtwebengine.log

Fixed, added NOT_FOR_ARCHS

Re: powerpc bulk build report

[Charlene Wendling]

On Tue, 26 May 2020 04:55:26 -0600 (MDT)
c...@openbsd.org wrote:

> Bulk build on macppc-0.ports.openbsd.org
> 
> Started : Sat May  9 02:01:05 MDT 2020
> Finished: Tue May 26 04:55:14 MDT 2020
> Duration: 17 Days 2 hours 54 minutes
>
> Built using OpenBSD 6.7 (GENERIC) #714: Fri May  8 11:06:48 MDT 2020
> 
> Built 9964 packages
> 
> Number of packages built each day:


Already fixed:

> http://build-failures.rhaalovely.net/powerpc/2020-05-09/devel/dyncall.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/emulators/gsplus.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/geo/osrm-backend.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/lang/parrot.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/mail/hashcash.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/plan9/drawterm.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/textproc/apertium-dicts/crh.log
> http://build-failures.rhaalovely.net/powerpc/2020-05-09/textproc/apertium-dicts/tur.log


Builds just fine at home:

> http://build-failures.rhaalovely.net/powerpc/2020-05-09/games/wesnoth.log

Re: powerpc bulk build report

[Solene Rapenne]

Le Wed, 29 Apr 2020 09:46:21 +0200,
Charlene Wendling  a écrit :

> On Tue, 28 Apr 2020 23:31:41 -0600 (MDT)
> c...@openbsd.org wrote:
> 
> Some informations that may be useful:
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/audio/qsynth.log
> >  
> 
> Waiting OK from maintainer:
> https://marc.info/?l=openbsd-ports=158806011730632=2
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/benchmarks/wrk.log
> >  
> 
> Waiting for upstream to deal with
> https://github.com/wg/wrk/pull/395
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/avr/binutils.log
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/riscv-elf/binutils.log
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/xtensa-esp32-elf/binutils.log
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/xtensa-lx106-elf/binutils.log
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/net/libtorrent-rasterbar.log
> >  
> 
> It will be fixed by
> https://marc.info/?l=openbsd-tech=158805196327877=2
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/frodo.log
> >  
> 
> It builds and works fine by passing -U__POWERPC__ as CFLAGS, but it's
> not the best idea.
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/gsplus.log
> >  
> 
> __builtin_ppc_mftb() is gcc-specific, i can provide a duct tape diff
> for it, but we loose some emulation fidelity.
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/retroarch.log
> >  
> 
> Waiting an OK from maintainer:
> https://marc.info/?l=openbsd-ports=158790761010953=2
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/games/valyriatear.log
> >  
> 
> Upstream has a build fix but colors are off:
> https://github.com/ValyriaTear/ValyriaTear/issues/655
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/lang/gforth.log
> >  
> 
> Using the i386 patches around that issue causes segfaults. Building
> everything with -O0 also causes segfaults.
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/print/pdflib.log
> >  
> 
> I've proposed a fix for that one:
> https://marc.info/?l=openbsd-ports=158809446412960=2
> 
> > http://build-failures.rhaalovely.net/powerpc/2020-04-09/x11/gnustep/base.log
> >  
> 
> See https://marc.info/?l=openbsd-ports=158722515929053=2 
> 

I'm pretty sure you asked for testing powerpc packages now that they
are built with clang but didn't find the related mails, so I answer
here.

On my powerbook I tried the following packages successfully:

audacious
chocolate-doom
cataclysm-dda
feh
mednafen
moc
windowmaker
openttd
nethack
rednotebook (some webkitgtk features was crashing and works fine now)
zathura
lifeograph (was crashing when I imported but works fine now)
surf (works, didn't try previously, didn't try js)

thank you very much for your work

Re: powerpc bulk build report

[Charlene Wendling]

On Tue, 28 Apr 2020 23:31:41 -0600 (MDT)
c...@openbsd.org wrote:

Some informations that may be useful:

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/audio/qsynth.log

Waiting OK from maintainer:
https://marc.info/?l=openbsd-ports=158806011730632=2

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/benchmarks/wrk.log

Waiting for upstream to deal with
https://github.com/wg/wrk/pull/395

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/avr/binutils.log
> http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/riscv-elf/binutils.log
> http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/xtensa-esp32-elf/binutils.log
> http://build-failures.rhaalovely.net/powerpc/2020-04-09/devel/xtensa-lx106-elf/binutils.log
> http://build-failures.rhaalovely.net/powerpc/2020-04-09/net/libtorrent-rasterbar.log

It will be fixed by
https://marc.info/?l=openbsd-tech=158805196327877=2

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/frodo.log

It builds and works fine by passing -U__POWERPC__ as CFLAGS, but it's
not the best idea.

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/gsplus.log

__builtin_ppc_mftb() is gcc-specific, i can provide a duct tape diff
for it, but we loose some emulation fidelity.

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/emulators/retroarch.log

Waiting an OK from maintainer:
https://marc.info/?l=openbsd-ports=158790761010953=2

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/games/valyriatear.log

Upstream has a build fix but colors are off:
https://github.com/ValyriaTear/ValyriaTear/issues/655

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/lang/gforth.log

Using the i386 patches around that issue causes segfaults. Building
everything with -O0 also causes segfaults.

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/print/pdflib.log

I've proposed a fix for that one:
https://marc.info/?l=openbsd-ports=158809446412960=2

> http://build-failures.rhaalovely.net/powerpc/2020-04-09/x11/gnustep/base.log

See https://marc.info/?l=openbsd-ports=158722515929053=2 

[ports-gcc] Unbreak graphics/asymptote (Was: Re: powerpc bulk build report)

[Charlene Wendling]

On Sat, 11 Jan 2020 05:05:44 -0700 (MST)
c...@openbsd.org wrote:

> http://build-failures.rhaalovely.net/powerpc/2019-12-25/graphics/asymptote.log

It's broken since texlive-2019 due to packaging lists changes:

--8<--
$ pkglocate etoolbox.sty
texlive_texmf-minimal-2019:print/texlive/texmf,-main:
/usr/local/share/texmf-dist/tex/latex/etoolbox/etoolbox.sty
-->8--

It has not been spotted before because it's not built on clang archs.
Once added it builds fine on powerpc [0].

Comments/feedback are welcome,

Charlène.


[0] https://bin.charlenew.xyz/asymptote.log


Index: Makefile
===
RCS file: /cvs/ports/graphics/asymptote/Makefile,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 Makefile
--- Makefile12 Jul 2019 20:46:56 -  1.36
+++ Makefile11 Jan 2020 12:15:06 -
@@ -27,9 +27,10 @@ WANTLIB += GL GLU OSMesa c fftw3 gc glut
 WANTLIB += readline sigsegv ${COMPILER_LIBCXX} z
 
 COMPILER = base-clang ports-gcc base-gcc
-
-BUILD_DEPENDS= print/texlive/base \
-   print/texinfo
+   
+BUILD_DEPENDS= print/texinfo \
+   print/texlive/base \
+   print/texlive/texmf,-main
 RUN_DEPENDS=   graphics/py-Pillow \
print/texlive/texmf,-full \
${MODPY_TKINTER_DEPENDS}

Re: powerpc bulk build report

[Marc Espie]

On Tue, Dec 24, 2019 at 02:11:53PM +, Stuart Henderson wrote:
> > > > g-ir-scanner: link: cc -pthread -o 
> > > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
> > > >  -O2 -pipe 
> > > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0.o
> > > >  -L. -Wl,-rpath,. -Wl,--no-as-needed 
> > > > -L/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > > > -Wl,-rpath,/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > > > -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib 
> > > > -Wl,-rpath,/usr/local/lib -lgweather-3 -lm -lgtk-3 -lgdk-3 
> > > > -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo 
> > > > -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lsoup-2.4 
> > > > -lxml2 -lgeocode-glib -L/usr/local/lib -Wl,--export-dynamic -pthread 
> > > > -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
> > > 
> > > > /usr/bin/ld: warning: libpixman-1.so.38.4, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libfontconfig.so.13.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libfreetype.so.30.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libxcb-shm.so.1.1, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libxcb.so.4.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libxcb-render.so.1.1, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libXrender.so.6.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libX11.so.17.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libXext.so.13.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libXinerama.so.6.0, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libXi.so.12.1, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > /usr/bin/ld: warning: libXrandr.so.7.1, needed by 
> > > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > > -rpath-link)
> > > > ...
> > > 
> > > > looks like binutils really wants -L/usr/X11R6/lib in there.
> > > 
> > > > (link line is the same on amd64, but it links)
> > > 
> > > Exact same failures I was mentioning on sparc64. 
> > > 
> > > Making this change fixed a bunch of GNOME ports. may want something more
> > > generic because it is happening on KDE stuff and then ports that are 
> > > neither.
> > 
> > Can't we fix the underlying issue instead?
> 
> Does anyone know what the underlying issue *is*?
> 
> Neither ld.bfd nor ld.lld default to searching in ${X11BASE}/lib.

Notice that none of the X11 libraries are directly mentionned in that link
line.

I'm pretty sure the libraries involved have a recorded rpath pointing
to /usr/X11R6/lib.

ld.lld heeds that information, but ld.bfd does not.


I have looked a bit, I can't seem to find anything in any of those libraries
though ;(

Re: powerpc bulk build report

[Stuart Henderson]

> > > g-ir-scanner: link: cc -pthread -o 
> > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
> > >  -O2 -pipe 
> > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0.o
> > >  -L. -Wl,-rpath,. -Wl,--no-as-needed 
> > > -L/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > > -Wl,-rpath,/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > > -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib 
> > > -Wl,-rpath,/usr/local/lib -lgweather-3 -lm -lgtk-3 -lgdk-3 
> > > -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo 
> > > -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lsoup-2.4 
> > > -lxml2 -lgeocode-glib -L/usr/local/lib -Wl,--export-dynamic -pthread 
> > > -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
> > 
> > > /usr/bin/ld: warning: libpixman-1.so.38.4, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libfontconfig.so.13.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libfreetype.so.30.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libxcb-shm.so.1.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libxcb.so.4.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libxcb-render.so.1.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXrender.so.6.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libX11.so.17.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXext.so.13.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXinerama.so.6.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXi.so.12.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXrandr.so.7.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > ...
> > 
> > > looks like binutils really wants -L/usr/X11R6/lib in there.
> > 
> > > (link line is the same on amd64, but it links)
> > 
> > Exact same failures I was mentioning on sparc64. 
> > 
> > Making this change fixed a bunch of GNOME ports. may want something more
> > generic because it is happening on KDE stuff and then ports that are 
> > neither.
> 
> Can't we fix the underlying issue instead?

Does anyone know what the underlying issue *is*?

Neither ld.bfd nor ld.lld default to searching in ${X11BASE}/lib.

Re: powerpc bulk build report

[Kurt Mosiejczuk]

> > Can't we fix the underlying issue instead?

> Or at least only add it for legacy archs.

I'm definitely not trying to imply that is *the* solution. It's a hack
that works. It only fixes those gnome ports, not others that are failing
for the same reason. I'd have pushed harder if I thought it was a real
solution.

cwen had proposed one that only did it for the lld.bfd architectures, but
I guess there is some issue with that needing to pull in bsd.arch.mk?

--Kurt

Re: powerpc bulk build report

[Antoine Jacoutot]

On Tue, Dec 24, 2019 at 12:46:44PM +0100, Antoine Jacoutot wrote:
> On Mon, Dec 23, 2019 at 11:25:54PM -0500, Kurt Mosiejczuk wrote:
> > On Mon, Dec 23, 2019 at 11:47:46PM +0100, Marc Espie wrote:
> > > On Mon, Dec 23, 2019 at 01:22:05PM -0700, c...@openbsd.org wrote:
> > > > Bulk build on macppc-1.ports.openbsd.org
> > > > 
> > > > Critical path missing pkgs: 
> > > > http://build-failures.rhaalovely.net/powerpc/2019-12-08/summary.log
> > > Lots of stuff because of x11/gnome/libgweather
> > 
> > > Failure:
> > > g-ir-scanner: link: cc -pthread -o 
> > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
> > >  -O2 -pipe 
> > > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0.o
> > >  -L. -Wl,-rpath,. -Wl,--no-as-needed 
> > > -L/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > > -Wl,-rpath,/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > > -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib 
> > > -Wl,-rpath,/usr/local/lib -lgweather-3 -lm -lgtk-3 -lgdk-3 
> > > -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo 
> > > -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lsoup-2.4 
> > > -lxml2 -lgeocode-glib -L/usr/local/lib -Wl,--export-dynamic -pthread 
> > > -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
> > 
> > > /usr/bin/ld: warning: libpixman-1.so.38.4, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libfontconfig.so.13.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libfreetype.so.30.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libxcb-shm.so.1.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libxcb.so.4.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libxcb-render.so.1.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXrender.so.6.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libX11.so.17.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXext.so.13.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXinerama.so.6.0, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXi.so.12.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > /usr/bin/ld: warning: libXrandr.so.7.1, needed by 
> > > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > > -rpath-link)
> > > ...
> > 
> > > looks like binutils really wants -L/usr/X11R6/lib in there.
> > 
> > > (link line is the same on amd64, but it links)
> > 
> > Exact same failures I was mentioning on sparc64. 
> > 
> > Making this change fixed a bunch of GNOME ports. may want something more
> > generic because it is happening on KDE stuff and then ports that are 
> > neither.
> 
> Can't we fix the underlying issue instead?

Or at least only add it for legacy archs.

> > Index: gnome.port.mk
> > ===
> > RCS file: /cvs/ports/x11/gnome/gnome.port.mk,v
> > retrieving revision 1.115
> > diff -u -r1.115 gnome.port.mk
> > --- gnome.port.mk   1 Dec 2018 13:04:41 -   1.115
> > +++ gnome.port.mk   7 Dec 2019 19:27:53 -
> > @@ -147,7 +147,8 @@
> >  # If a port needs extra CPPFLAGS, they can just set MODGNOME_CPPFLAGS
> >  # to the desired value, like -I${X11BASE}/include
> >  _MODGNOME_cppflags ?= CPPFLAGS="${MODGNOME_CPPFLAGS} 
> > -I${LOCALBASE}/include"
> > -_MODGNOME_ldflags ?= LDFLAGS="${MODGNOME_LDFLAGS} -L${LOCALBASE}/lib"
> > +_MODGNOME_ldflags ?= LDFLAGS="${MODGNOME_LDFLAGS} -L${LOCALBASE}/lib \
> > +-L${X11BASE}/lib"
> >  
> >  .if ${CONFIGURE_STYLE:Mgnu} || ${CONFIGURE_STYLE:Msimple} || \
> >  ${CONFIGURE_STYLE:Mcmake} || ${CONFIGURE_STYLE:Mmeson}
> > 
> 
> -- 
> Antoine
> 

-- 
Antoine

Re: powerpc bulk build report

[Antoine Jacoutot]

On Mon, Dec 23, 2019 at 11:25:54PM -0500, Kurt Mosiejczuk wrote:
> On Mon, Dec 23, 2019 at 11:47:46PM +0100, Marc Espie wrote:
> > On Mon, Dec 23, 2019 at 01:22:05PM -0700, c...@openbsd.org wrote:
> > > Bulk build on macppc-1.ports.openbsd.org
> > > 
> > > Critical path missing pkgs: 
> > > http://build-failures.rhaalovely.net/powerpc/2019-12-08/summary.log
> > Lots of stuff because of x11/gnome/libgweather
> 
> > Failure:
> > g-ir-scanner: link: cc -pthread -o 
> > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
> >  -O2 -pipe 
> > /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0.o
> >  -L. -Wl,-rpath,. -Wl,--no-as-needed 
> > -L/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > -Wl,-rpath,/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> > -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib 
> > -Wl,-rpath,/usr/local/lib -lgweather-3 -lm -lgtk-3 -lgdk-3 -lpangocairo-1.0 
> > -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 
> > -lgobject-2.0 -lglib-2.0 -lintl -lsoup-2.4 -lxml2 -lgeocode-glib 
> > -L/usr/local/lib -Wl,--export-dynamic -pthread -lgio-2.0 -lgobject-2.0 
> > -lgmodule-2.0 -lglib-2.0 -lintl
> 
> > /usr/bin/ld: warning: libpixman-1.so.38.4, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libfontconfig.so.13.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libfreetype.so.30.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libxcb-shm.so.1.1, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libxcb.so.4.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libxcb-render.so.1.1, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libXrender.so.6.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libX11.so.17.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libXext.so.13.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libXinerama.so.6.0, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libXi.so.12.1, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > /usr/bin/ld: warning: libXrandr.so.7.1, needed by 
> > /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or 
> > -rpath-link)
> > ...
> 
> > looks like binutils really wants -L/usr/X11R6/lib in there.
> 
> > (link line is the same on amd64, but it links)
> 
> Exact same failures I was mentioning on sparc64. 
> 
> Making this change fixed a bunch of GNOME ports. may want something more
> generic because it is happening on KDE stuff and then ports that are 
> neither.

Can't we fix the underlying issue instead?

> Index: gnome.port.mk
> ===
> RCS file: /cvs/ports/x11/gnome/gnome.port.mk,v
> retrieving revision 1.115
> diff -u -r1.115 gnome.port.mk
> --- gnome.port.mk 1 Dec 2018 13:04:41 -   1.115
> +++ gnome.port.mk 7 Dec 2019 19:27:53 -
> @@ -147,7 +147,8 @@
>  # If a port needs extra CPPFLAGS, they can just set MODGNOME_CPPFLAGS
>  # to the desired value, like -I${X11BASE}/include
>  _MODGNOME_cppflags ?= CPPFLAGS="${MODGNOME_CPPFLAGS} -I${LOCALBASE}/include"
> -_MODGNOME_ldflags ?= LDFLAGS="${MODGNOME_LDFLAGS} -L${LOCALBASE}/lib"
> +_MODGNOME_ldflags ?= LDFLAGS="${MODGNOME_LDFLAGS} -L${LOCALBASE}/lib \
> +-L${X11BASE}/lib"
>  
>  .if ${CONFIGURE_STYLE:Mgnu} || ${CONFIGURE_STYLE:Msimple} || \
>  ${CONFIGURE_STYLE:Mcmake} || ${CONFIGURE_STYLE:Mmeson}
> 

-- 
Antoine

Re: powerpc bulk build report

[Kurt Mosiejczuk]

On Mon, Dec 23, 2019 at 11:47:46PM +0100, Marc Espie wrote:
> On Mon, Dec 23, 2019 at 01:22:05PM -0700, c...@openbsd.org wrote:
> > Bulk build on macppc-1.ports.openbsd.org
> > 
> > Critical path missing pkgs: 
> > http://build-failures.rhaalovely.net/powerpc/2019-12-08/summary.log
> Lots of stuff because of x11/gnome/libgweather

> Failure:
> g-ir-scanner: link: cc -pthread -o 
> /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
>  -O2 -pipe 
> /usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0.o
>  -L. -Wl,-rpath,. -Wl,--no-as-needed 
> -L/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> -Wl,-rpath,/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
> -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib 
> -Wl,-rpath,/usr/local/lib -lgweather-3 -lm -lgtk-3 -lgdk-3 -lpangocairo-1.0 
> -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 
> -lgobject-2.0 -lglib-2.0 -lintl -lsoup-2.4 -lxml2 -lgeocode-glib 
> -L/usr/local/lib -Wl,--export-dynamic -pthread -lgio-2.0 -lgobject-2.0 
> -lgmodule-2.0 -lglib-2.0 -lintl

> /usr/bin/ld: warning: libpixman-1.so.38.4, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libfontconfig.so.13.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libfreetype.so.30.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libxcb-shm.so.1.1, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libxcb.so.4.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libxcb-render.so.1.1, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libXrender.so.6.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libX11.so.17.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libXext.so.13.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libXinerama.so.6.0, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libXi.so.12.1, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> /usr/bin/ld: warning: libXrandr.so.7.1, needed by 
> /usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
> ...

> looks like binutils really wants -L/usr/X11R6/lib in there.

> (link line is the same on amd64, but it links)

Exact same failures I was mentioning on sparc64. 

Making this change fixed a bunch of GNOME ports. may want something more
generic because it is happening on KDE stuff and then ports that are 
neither.

--Kurt

Index: gnome.port.mk
===
RCS file: /cvs/ports/x11/gnome/gnome.port.mk,v
retrieving revision 1.115
diff -u -r1.115 gnome.port.mk
--- gnome.port.mk   1 Dec 2018 13:04:41 -   1.115
+++ gnome.port.mk   7 Dec 2019 19:27:53 -
@@ -147,7 +147,8 @@
 # If a port needs extra CPPFLAGS, they can just set MODGNOME_CPPFLAGS
 # to the desired value, like -I${X11BASE}/include
 _MODGNOME_cppflags ?= CPPFLAGS="${MODGNOME_CPPFLAGS} -I${LOCALBASE}/include"
-_MODGNOME_ldflags ?= LDFLAGS="${MODGNOME_LDFLAGS} -L${LOCALBASE}/lib"
+_MODGNOME_ldflags ?= LDFLAGS="${MODGNOME_LDFLAGS} -L${LOCALBASE}/lib \
+-L${X11BASE}/lib"
 
 .if ${CONFIGURE_STYLE:Mgnu} || ${CONFIGURE_STYLE:Msimple} || \
 ${CONFIGURE_STYLE:Mcmake} || ${CONFIGURE_STYLE:Mmeson}

Re: powerpc bulk build report

[Marc Espie]

On Mon, Dec 23, 2019 at 01:22:05PM -0700, c...@openbsd.org wrote:
> Bulk build on macppc-1.ports.openbsd.org
> 
> Critical path missing pkgs: 
> http://build-failures.rhaalovely.net/powerpc/2019-12-08/summary.log
Lots of stuff because of x11/gnome/libgweather

Failure:
g-ir-scanner: link: cc -pthread -o 
/usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0
 -O2 -pipe 
/usr/obj/ports/libgweather-3.34.0/build-powerpc/tmp-introspecty_ix5pqn/GWeather-3.0.o
 -L. -Wl,-rpath,. -Wl,--no-as-needed 
-L/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
-Wl,-rpath,/usr/obj/ports/libgweather-3.34.0/build-powerpc/libgweather 
-L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib 
-Wl,-rpath,/usr/local/lib -lgweather-3 -lm -lgtk-3 -lgdk-3 -lpangocairo-1.0 
-lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lintl -lsoup-2.4 -lxml2 -lgeocode-glib 
-L/usr/local/lib -Wl,--export-dynamic -pthread -lgio-2.0 -lgobject-2.0 
-lgmodule-2.0 -lglib-2.0 -lintl

/usr/bin/ld: warning: libpixman-1.so.38.4, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libfontconfig.so.13.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libfreetype.so.30.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libxcb-shm.so.1.1, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libxcb.so.4.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libxcb-render.so.1.1, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXrender.so.6.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libX11.so.17.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXext.so.13.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXinerama.so.6.0, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXi.so.12.1, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXrandr.so.7.1, needed by 
/usr/local/lib/libgtk-3.so.2201.0, not found (try using -rpath or -rpath-link)
...

looks like binutils really wants -L/usr/X11R6/lib in there.

(link line is the same on amd64, but it links)

Re: [ports-gcc] Unbreak devel/pycdc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Ping.

On Tue, 16 Jul 2019 00:30:23 +0200
Charlene Wendling wrote:

> 
> > http://build-failures.rhaalovely.net//powerpc/2019-06-29/devel/pycdc.log
> 
> Using -Werror for releases seems ambitious to me, especially that GCC
> is very adept at generating them.
> 
> I've removed the flag, and it builds [0] on macppc. Tests pass as
> well. Same thing for amd64 where there is no warning at all to start
> with.
> 
> Comments/feedback are welcome!
> 
> Charlène.
> 
> 
> [0] https://bin.charlenew.xyz/pycdc.log
> 

Index: Makefile
===
RCS file: /cvs/ports/devel/pycdc/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- Makefile12 Jul 2019 20:45:56 -  1.4
+++ Makefile15 Jul 2019 22:14:54 -
@@ -3,7 +3,7 @@
 COMMENT =  python bytecode disassembler and decompiler
 
 DISTNAME = pycdc-0.0.20180428
-REVISION = 1
+REVISION = 2
 
 GH_ACCOUNT =   zrax
 GH_PROJECT =   pycdc
Index: patches/patch-CMakeLists_txt
===
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-CMakeLists_txt15 Jul 2019 22:14:54 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix for ports-gcc, the code generates warnings that triggers a
+build failure
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
 CMakeLists.txt
+@@ -5,7 +5,7 @@ cmake_minimum_required(VERSION 2.8)
+ find_package(PythonInterp REQUIRED)
+ 
+ if(CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
+-set(CMAKE_CXX_FLAGS "-Wall -Wextra -Werror ${CMAKE_CXX_FLAGS}")
++set(CMAKE_CXX_FLAGS "-Wall -Wextra ${CMAKE_CXX_FLAGS}")
+ endif()
+ 
+ set(PYTHON_VERSIONS

Re: [ports-gcc] Unbreak graphics/vulkan-loader (was: Re: powerpc bulk build report)

[Charlene Wendling]

On Thu, 18 Jul 2019 23:13:14 -0600
Thomas Frohwein wrote:

> Thanks, I appreciate that you found the fix for it! I'm traveling
> currently and can commit the change only on Sunday. 
> 
> I'm not sure if this should really be built if there is truly no
> hardware that's compatible... The alternative would excluding PPC and
> maybe a few other arches that are known to not work with any
> compatible hardware.

Well, there are 2 problems in fact:

- the one i address here is for all base-gcc archs, not macppc only
- but in fact most of these archs have no vulkan capable video cards

As far as macppc is concerned, all G4 system are AGP-based so no amdgpu
for them, hence no vulkan. 

Some G5 ones have PCI-Express and the best upgrade official upgrade you
could get is a Radeon X1900 that doesn't as well. I'm not sure more
modern third party cards are available.

CC'ing Jeremie and Kurt, as i don't know how sparc64 is doing in this
regard.

I guess it should be only for x86* and arm* in the end.

Charlène.

> On Mon, Jul 15, 2019, at 3:42 PM, Charlene Wendling wrote:
> > 
> > > http://build-failures.rhaalovely.net//powerpc/2019-06-29/graphics/vulkan-loader.log
> > 
> > The problem here is pretty simple as soon as base-gcc is implied:
> > 
> > - it has missing switches (that's the failure seen in the log)
> > - anonymous unions require -std=gnu99 (that's also in the log,
> >   "declarations that declare nothing" warnings)
> > - i fixed those in the CMakeLists, but then it fails with another 
> >   classic: "error: thread-local storage not supported for this
> > target"
> > 
> > I guess it's enough to allow me a COMPILER change. It has fixed the
> > build [0], i can't say anything about runtime since no macppc 
> > video cards are compatible.
> > 
> > I made no REVISION bump, because it has never been built on base-gcc
> > archs and it implies no changes for base-clang ones.
> > 
> > Comments/feedback are welcome!
> > 
> > Charlène.
> > 
> > [0] https://bin.charlenew.xyz/vulkan-loader.log
> > 
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/graphics/vulkan-loader/Makefile,v
> > retrieving revision 1.3
> > diff -u -p -u -p -r1.3 Makefile
> > --- Makefile22 Jun 2019 17:02:24 -  1.3
> > +++ Makefile15 Jul 2019 21:25:27 -
> > @@ -26,6 +26,9 @@ RUN_DEPENDS = graphics/vulkan-headers
> >  
> >  CONFIGURE_ARGS =   -DBUILD_WSI_WAYLAND_SUPPORT=False
> >  
> > +# Thread local storage
> > +COMPILER = base-clang ports-gcc
> > +
> >  MODULES =  devel/cmake \
> > lang/python
> >  MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
> >
> 
> -- 
>   
> tfrohw...@fastmail.com
> 
> PGP Public Key:
> https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22

Re: [ports-gcc] Unbreak graphics/vulkan-loader (was: Re: powerpc bulk build report)

[Thomas Frohwein]

Thanks, I appreciate that you found the fix for it! I'm traveling currently and 
can commit the change only on Sunday. 

I'm not sure if this should really be built if there is truly no hardware 
that's compatible... The alternative would excluding PPC and maybe a few other 
arches that are known to not work with any compatible hardware.

On Mon, Jul 15, 2019, at 3:42 PM, Charlene Wendling wrote:
> 
> > http://build-failures.rhaalovely.net//powerpc/2019-06-29/graphics/vulkan-loader.log
> 
> The problem here is pretty simple as soon as base-gcc is implied:
> 
> - it has missing switches (that's the failure seen in the log)
> - anonymous unions require -std=gnu99 (that's also in the log,
>   "declarations that declare nothing" warnings)
> - i fixed those in the CMakeLists, but then it fails with another 
>   classic: "error: thread-local storage not supported for this target"
> 
> I guess it's enough to allow me a COMPILER change. It has fixed the
> build [0], i can't say anything about runtime since no macppc 
> video cards are compatible.
> 
> I made no REVISION bump, because it has never been built on base-gcc
> archs and it implies no changes for base-clang ones.
> 
> Comments/feedback are welcome!
> 
> Charlène.
> 
> [0] https://bin.charlenew.xyz/vulkan-loader.log
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/vulkan-loader/Makefile,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 Makefile
> --- Makefile  22 Jun 2019 17:02:24 -  1.3
> +++ Makefile  15 Jul 2019 21:25:27 -
> @@ -26,6 +26,9 @@ RUN_DEPENDS =   graphics/vulkan-headers
>  
>  CONFIGURE_ARGS = -DBUILD_WSI_WAYLAND_SUPPORT=False
>  
> +# Thread local storage
> +COMPILER =   base-clang ports-gcc
> +
>  MODULES =devel/cmake \
>   lang/python
>  MODPY_VERSION =  ${MODPY_DEFAULT_VERSION_3}
>

-- 
  
tfrohw...@fastmail.com

PGP Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22

[ports-gcc] Unbreak devel/pycdc (was: Re: powerpc bulk build report)

[Charlene Wendling]

> http://build-failures.rhaalovely.net//powerpc/2019-06-29/devel/pycdc.log

Using -Werror for releases seems ambitious to me, especially that GCC
is very adept at generating them.

I've removed the flag, and it builds [0] on macppc. Tests pass as well.
Same thing for amd64 where there is no warning at all to start with.

Comments/feedback are welcome!

Charlène.


[0] https://bin.charlenew.xyz/pycdc.log


Index: Makefile
===
RCS file: /cvs/ports/devel/pycdc/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- Makefile12 Jul 2019 20:45:56 -  1.4
+++ Makefile15 Jul 2019 22:14:54 -
@@ -3,7 +3,7 @@
 COMMENT =  python bytecode disassembler and decompiler
 
 DISTNAME = pycdc-0.0.20180428
-REVISION = 1
+REVISION = 2
 
 GH_ACCOUNT =   zrax
 GH_PROJECT =   pycdc
Index: patches/patch-CMakeLists_txt
===
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-CMakeLists_txt15 Jul 2019 22:14:54 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix for ports-gcc, the code generates warnings that triggers a
+build failure
+
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
 CMakeLists.txt
+@@ -5,7 +5,7 @@ cmake_minimum_required(VERSION 2.8)
+ find_package(PythonInterp REQUIRED)
+ 
+ if(CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
+-set(CMAKE_CXX_FLAGS "-Wall -Wextra -Werror ${CMAKE_CXX_FLAGS}")
++set(CMAKE_CXX_FLAGS "-Wall -Wextra ${CMAKE_CXX_FLAGS}")
+ endif()
+ 
+ set(PYTHON_VERSIONS

[ports-gcc] Unbreak graphics/vulkan-loader (was: Re: powerpc bulk build report)

[Charlene Wendling]

> http://build-failures.rhaalovely.net//powerpc/2019-06-29/graphics/vulkan-loader.log

The problem here is pretty simple as soon as base-gcc is implied:

- it has missing switches (that's the failure seen in the log)
- anonymous unions require -std=gnu99 (that's also in the log,
  "declarations that declare nothing" warnings)
- i fixed those in the CMakeLists, but then it fails with another 
  classic: "error: thread-local storage not supported for this target"

I guess it's enough to allow me a COMPILER change. It has fixed the
build [0], i can't say anything about runtime since no macppc 
video cards are compatible.

I made no REVISION bump, because it has never been built on base-gcc
archs and it implies no changes for base-clang ones.

Comments/feedback are welcome!

Charlène.

[0] https://bin.charlenew.xyz/vulkan-loader.log


Index: Makefile
===
RCS file: /cvs/ports/graphics/vulkan-loader/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- Makefile22 Jun 2019 17:02:24 -  1.3
+++ Makefile15 Jul 2019 21:25:27 -
@@ -26,6 +26,9 @@ RUN_DEPENDS = graphics/vulkan-headers
 
 CONFIGURE_ARGS =   -DBUILD_WSI_WAYLAND_SUPPORT=False
 
+# Thread local storage
+COMPILER = base-clang ports-gcc
+
 MODULES =  devel/cmake \
lang/python
 MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}

[ports-gcc] Unbreak multimedia/qtav (was: Re: powerpc bulk build report)

[Charlene Wendling]

On Sun, 14 Jul 2019 06:46:44 -0600 (MDT)
lan...@openbsd.org wrote:


> http://build-failures.rhaalovely.net//powerpc/2019-06-29/multimedia/qtav.log
> http://build-failures.rhaalovely.net/sparc64/2019-06-09/multimedia/qtav.log

Classic issue here, GCC doesn't like to see NULL as an equivalent for
false. It seems like an upstream "typo", because there are many
occurrences where booleans are used.

It builds fine on amd64 and macppc (there are no tests).

Comments/feedback are welcome!

Charlène.


Index: Makefile
===
RCS file: /cvs/ports/multimedia/qtav/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- Makefile12 Jul 2019 20:47:57 -  1.3
+++ Makefile15 Jul 2019 20:27:40 -
@@ -5,6 +5,7 @@ COMMENT =   FFmpeg-based Qt multimedia fra
 GH_ACCOUNT =   wang-bin
 GH_PROJECT =   QtAV
 GH_TAGNAME =   v1.12.0
+REVISION = 0
 
 PKGNAME =  ${DISTNAME:L}
 
Index: patches/patch-src_codec_video_SurfaceInteropCUDA_cpp
===
RCS file: patches/patch-src_codec_video_SurfaceInteropCUDA_cpp
diff -N patches/patch-src_codec_video_SurfaceInteropCUDA_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_codec_video_SurfaceInteropCUDA_cpp15 Jul 2019 
20:27:40 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+ports-gcc fix for:
+converting to 'bool' from 'std::nullptr_t' requires direct-initialization
+
+Index: src/codec/video/SurfaceInteropCUDA.cpp
+--- src/codec/video/SurfaceInteropCUDA.cpp.orig
 src/codec/video/SurfaceInteropCUDA.cpp
+@@ -132,7 +132,7 @@ bool HostInteropResource::map(int picIndex, const CUVI
+ if (!ensureResource(pitch, H)) //copy height is coded height
+ return false;
+ // the same thread (context) as cuMemAllocHost, so no ccontext switch 
is needed
+-CUDA_ENSURE(cuMemcpyDtoH(host_mem.data, devptr, pitch*H*3/2), NULL);
++CUDA_ENSURE(cuMemcpyDtoH(host_mem.data, devptr, pitch*H*3/2), false);
+ host_mem.index = picIndex;
+ }
+ // map to texture
+@@ -173,7 +173,7 @@ bool HostInteropResource::ensureResource(int pitch, in
+ if (!share_ctx) // cuMemFreeHost will be called in dtor which is not the 
current thread.
+ CUDA_WARN(cuCtxPushCurrent(ctx));
+ // NV12
+-CUDA_ENSURE(cuMemAllocHost((void**)_mem.data, pitch*height*3/2), 
NULL);
++CUDA_ENSURE(cuMemAllocHost((void**)_mem.data, pitch*height*3/2), 
false);
+ if (!share_ctx)
+ CUDA_WARN(cuCtxPopCurrent(NULL)); //can be null or 
+ return true;

Re: [macppc/arm] Unbreak misc/openbabel (was: Re: powerpc bulk build report)

[Charlene Wendling]

Ping :)

On Sun, 16 Jun 2019 09:23:56 +0200
Charlene Wendling wrote:

> Hi,
> 
> > http://build-failures.rhaalovely.net//powerpc/2019-05-19/misc/openbabel.log
> > http://build-failures.rhaalovely.net/arm/2019-04-30/misc/openbabel.log
> > http://build-failures.rhaalovely.net/aarch64/2019-06-09/misc/openbabel.log
> 
> It's a typical narrowing error we've here.
> 
> Upstream has fixes [0] for it, and once applied, it builds fine on
> macppc [1] and amd64. 'make test' passes as well.
> 
> Comments/feedback are welcome!
> 
> Charlène.
> 
> 
> [0] https://github.com/openbabel/openbabel/pull/1744
> [1] http://0x0.st/zeBS.txt


Index: Makefile
===
RCS file: /cvs/ports/misc/openbabel/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile24 Oct 2018 14:28:08 -  1.26
+++ Makefile16 Jun 2019 07:04:56 -
@@ -4,7 +4,7 @@ COMMENT=chemistry file translation prog
 
 V= 2.2.3
 DISTNAME=  openbabel-${V}
-REVISION=  7
+REVISION=  8
 CATEGORIES=misc
 
 SUBST_VARS=V
Index: patches/patch-src_formats_pngformat_cpp
===
RCS file: patches/patch-src_formats_pngformat_cpp
diff -N patches/patch-src_formats_pngformat_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_formats_pngformat_cpp 16 Jun 2019 07:04:56 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix the build on archs where char is unsigned by default (arm,ppc)
+see:
+https://github.com/openbabel/openbabel/commit/e26491017efefdc6aaf73d4d49f284f4e9436244
+
+Index: src/formats/pngformat.cpp
+--- src/formats/pngformat.cpp.orig
 src/formats/pngformat.cpp
+@@ -120,7 +120,7 @@ bool PNGFormat::ReadMolecule(OBBase* pOb, OBConversion
+   if(pConv->IsFirstInput())
+ count=0;
+ 
+-  const char pngheader[] = {-119,80,78,71,13,10,26,10,0};
++  const unsigned char pngheader[] = {137,80,78,71,13,10,26,10,0};
+   char readbytes[9];
+   ifs.read(readbytes, 8);
+   
Index: patches/patch-src_formats_yasaraformat_cpp
===
RCS file: patches/patch-src_formats_yasaraformat_cpp
diff -N patches/patch-src_formats_yasaraformat_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_formats_yasaraformat_cpp  16 Jun 2019 07:04:56 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+fix narrowing conversion errors on archs where char is unsigned by default
+(arm, ppc), see 
+https://github.com/openbabel/openbabel/pull/1744
+
+Index: src/formats/yasaraformat.cpp
+--- src/formats/yasaraformat.cpp.orig
 src/formats/yasaraformat.cpp
+@@ -478,7 +478,7 @@ bool YOBFormat::WriteMolecule(OBBase* pOb, OBConversio
+ 
+   //  bool hetatom;
+   char buffer[32],/*resname[4],*/atomname[5];
+-  char double1[8]={0,0,0,0,0,0,-16,0x3f};
++  unsigned char double1[8]={0,0,0,0,0,0,0xf0,0x3f};
+   //   char *str;
+   int i,j,/*m,q,*/pos;
+   int /*resno,chainNum,link,linktype,*/atoms,element,links/*,chain*/;
+@@ -506,7 +506,7 @@ bool YOBFormat::WriteMolecule(OBBase* pOb, OBConversio
+   mem_set(buffer,0,8);
+   for (i=0;i<4;i++)
+   { for (j=0;j<4;j++)
+-{ if (i==j) ofs.write(double1,8);
++{ if (i==j) ofs.write((char*)double1,8);
+   else ofs.write(buffer,8); } }
+   storeint32le(buffer,MOB_INFOEND);
+   storeint32le([4],MOB_INFOENDSIZE);

[macppc/arm] Unbreak misc/openbabel (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi,

> http://build-failures.rhaalovely.net//powerpc/2019-05-19/misc/openbabel.log
> http://build-failures.rhaalovely.net/arm/2019-04-30/misc/openbabel.log
> http://build-failures.rhaalovely.net/aarch64/2019-06-09/misc/openbabel.log

It's a typical narrowing error we've here.

Upstream has fixes [0] for it, and once applied, it builds fine on
macppc [1] and amd64. 'make test' passes as well.

Comments/feedback are welcome!

Charlène.


[0] https://github.com/openbabel/openbabel/pull/1744
[1] http://0x0.st/zeBS.txt


Index: Makefile
===
RCS file: /cvs/ports/misc/openbabel/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile24 Oct 2018 14:28:08 -  1.26
+++ Makefile16 Jun 2019 07:04:56 -
@@ -4,7 +4,7 @@ COMMENT=chemistry file translation prog
 
 V= 2.2.3
 DISTNAME=  openbabel-${V}
-REVISION=  7
+REVISION=  8
 CATEGORIES=misc
 
 SUBST_VARS=V
Index: patches/patch-src_formats_pngformat_cpp
===
RCS file: patches/patch-src_formats_pngformat_cpp
diff -N patches/patch-src_formats_pngformat_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_formats_pngformat_cpp 16 Jun 2019 07:04:56 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix the build on archs where char is unsigned by default (arm,ppc)
+see:
+https://github.com/openbabel/openbabel/commit/e26491017efefdc6aaf73d4d49f284f4e9436244
+
+Index: src/formats/pngformat.cpp
+--- src/formats/pngformat.cpp.orig
 src/formats/pngformat.cpp
+@@ -120,7 +120,7 @@ bool PNGFormat::ReadMolecule(OBBase* pOb, OBConversion
+   if(pConv->IsFirstInput())
+ count=0;
+ 
+-  const char pngheader[] = {-119,80,78,71,13,10,26,10,0};
++  const unsigned char pngheader[] = {137,80,78,71,13,10,26,10,0};
+   char readbytes[9];
+   ifs.read(readbytes, 8);
+   
Index: patches/patch-src_formats_yasaraformat_cpp
===
RCS file: patches/patch-src_formats_yasaraformat_cpp
diff -N patches/patch-src_formats_yasaraformat_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_formats_yasaraformat_cpp  16 Jun 2019 07:04:56 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+fix narrowing conversion errors on archs where char is unsigned by default
+(arm, ppc), see 
+https://github.com/openbabel/openbabel/pull/1744
+
+Index: src/formats/yasaraformat.cpp
+--- src/formats/yasaraformat.cpp.orig
 src/formats/yasaraformat.cpp
+@@ -478,7 +478,7 @@ bool YOBFormat::WriteMolecule(OBBase* pOb, OBConversio
+ 
+   //  bool hetatom;
+   char buffer[32],/*resname[4],*/atomname[5];
+-  char double1[8]={0,0,0,0,0,0,-16,0x3f};
++  unsigned char double1[8]={0,0,0,0,0,0,0xf0,0x3f};
+   //   char *str;
+   int i,j,/*m,q,*/pos;
+   int /*resno,chainNum,link,linktype,*/atoms,element,links/*,chain*/;
+@@ -506,7 +506,7 @@ bool YOBFormat::WriteMolecule(OBBase* pOb, OBConversio
+   mem_set(buffer,0,8);
+   for (i=0;i<4;i++)
+   { for (j=0;j<4;j++)
+-{ if (i==j) ofs.write(double1,8);
++{ if (i==j) ofs.write((char*)double1,8);
+   else ofs.write(buffer,8); } }
+   storeint32le(buffer,MOB_INFOEND);
+   storeint32le([4],MOB_INFOENDSIZE);

Re: [ports-gcc] Unbreak x11/libhandy (was: Re: powerpc bulk build report)

[Stuart Henderson]

On 2019/06/10 15:04, Charlene Wendling wrote:
> 
> > http://build-failures.rhaalovely.net//sparc64/last/x11/libhandy.log
> > http://build-failures.rhaalovely.net//powerpc/last/x11/libhandy.log
> 
> It's just a COMPILER line missing because it's C11, right? Well it's
> more than this, as once provided it yells: 
> 
> > (more of them)
> > /usr/local/lib/libgtk-3.so.2201.0: undefined reference to 
> > `epoxy_glXQueryExtension'
> > /usr/local/lib/libgdk-3.so.2201.1: undefined reference to 
> > `XcursorImageCreate'
> > /usr/local/lib/libgdk-3.so.2201.1: undefined reference to 
> > `epoxy_glDrawArrays'
> > /usr/local/lib/libpangocairo-1.0.so.3800.1: undefined reference to 
> > `FcDefaultSubstitute'
> > collect2: error: ld returned 1 exit status
> > linking of temporary binary failed: Command '['cc', '-o', 
> > '/usr/ports/pobj/libhandy-0.0.9.1/build-powerpc/tmp-introspectxopgayge/Handy-0.0',
> >  '-O2', '-pipe', 
> > '/usr/ports/pobj/libhandy-0.0.9.1/build-powerpc/tmp-introspectxopgayge/Handy-0.0.o',
> >  '-L.', '-Wl,-rpath,.', '-Wl,--no-as-needed', 
> > '-L/usr/ports/pobj/libhandy-0.0.9.1/build-powerpc/src', 
> > '-Wl,-rpath,/usr/ports/pobj/libhandy-0.0.9.1/build-powerpc/src', 
> > '-L/usr/ports/pobj/libhandy-0.0.9.1/build-powerpc/src', 
> > '-Wl,-rpath,/usr/ports/pobj/libhandy-0.0.9.1/build-powerpc/src', 
> > '-L/usr/local/lib', '-Wl,-rpath,/usr/local/lib', '-lhandy-0.0', 
> > '-lhandy-0.0', '-lintl', '-lglib-2.0', '-lgio-2.0', '-lgobject-2.0', 
> > '-lgmodule-2.0', '-lgtk-3', '-lgdk-3', '-lpangocairo-1.0', '-lpango-1.0', 
> > '-latk-1.0', '-lcairo-gobject', '-lcairo', '-lgdk_pixbuf-2.0', '-lm', 
> > '-L/usr/local/lib', '-Wl,--export-dynamic', '-pthread', '-lgio-2.0', 
> > '-lgobject-2.0', '-lgmodule-2.0', '-lintl', '-lglib-2.0']' returned 
> > non-zero exit status 1
> 
> 
> They're either fontconfig, xcb or other X11-related references, 
> as it lacks X11BASE/lib as a LDFLAG, so i added it. It seems fishy
> to me, but i guess it's yet another base-gcc arch quirk that i don't
> know about ;)

This one doesn't feel all that likely to be a compiler quirk, perhaps
it'sactually related to ld.bfd rather than gcc ... No easy way to test
that theory though, meson + libraries + ld.bfd doesn't work on amd64
and at the moment CLANG_ARCHS == LLD_ARCHS.

Re: [macppc/arm] Unbreak graphics/ufraw (was: Re: powerpc bulk build report)

[Kirill Bychkov]

On Mon, June 10, 2019 16:13, Charlene Wendling wrote:
> On Mon, 10 Jun 2019 13:49:49 +0100
> Stuart Henderson wrote:
>
>> On 2019/06/10 13:22, Charlene Wendling wrote:
>> > Hi :)
>> >
>> > > http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/ufraw.log
>> > > http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/ufraw.log
>> > > http://build-failures.rhaalovely.net/arm/last/graphics/ufraw.log
>> >
>> > It's a typical case of code that assumes that char is signed on all
>> > platforms - not much to say.
>> >
>> > It has been built and tested on macppc [0] and amd64.
>> >
>> > Comments/feedback are welcome!
>>
>> OK. The dcraw code is copied around a lot, it maybe worth checking
>> others - besides ufraw there are:
>
> Thanks.
>
> Yes, we had issues with similar dcraw implementations already.
>
> Already fixed and tested:
>> graphics/freeimage
>
> Supposedly fixed:
>> graphics/rawstudio
>
> No fixes:
>> graphics/dcraw
>> graphics/libraw
>> graphics/rawtherapee

Hi!
rawtherapee is supposed to run only on amd64. Probably it could
work well on aarch64 too.

>
> I'll try to take some time once all the trivial stuff is done and
> study them.
>
>>
>> (if they don't fail then maybe they're built with -funsigned-char)
>>
>
> Charl?ne.
>
>

Re: [macppc/arm] Unbreak graphics/ufraw (was: Re: powerpc bulk build report)

[Charlene Wendling]

On Mon, 10 Jun 2019 13:49:49 +0100
Stuart Henderson wrote:

> On 2019/06/10 13:22, Charlene Wendling wrote:
> > Hi :)
> > 
> > > http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/ufraw.log
> > > http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/ufraw.log
> > > http://build-failures.rhaalovely.net/arm/last/graphics/ufraw.log
> > 
> > It's a typical case of code that assumes that char is signed on all
> > platforms - not much to say.
> > 
> > It has been built and tested on macppc [0] and amd64.
> > 
> > Comments/feedback are welcome!
> 
> OK. The dcraw code is copied around a lot, it maybe worth checking
> others - besides ufraw there are:

Thanks. 

Yes, we had issues with similar dcraw implementations already.

Already fixed and tested:
> graphics/freeimage

Supposedly fixed: 
> graphics/rawstudio

No fixes: 
> graphics/dcraw
> graphics/libraw
> graphics/rawtherapee

I'll try to take some time once all the trivial stuff is done and
study them.

> 
> (if they don't fail then maybe they're built with -funsigned-char)
> 

Charlène.

Re: [macppc/arm] Unbreak graphics/ufraw (was: Re: powerpc bulk build report)

[Stuart Henderson]

On 2019/06/10 13:22, Charlene Wendling wrote:
> Hi :)
> 
> > http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/ufraw.log
> > http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/ufraw.log
> > http://build-failures.rhaalovely.net/arm/last/graphics/ufraw.log
> 
> It's a typical case of code that assumes that char is signed on all
> platforms - not much to say.
> 
> It has been built and tested on macppc [0] and amd64.
> 
> Comments/feedback are welcome!

OK. The dcraw code is copied around a lot, it maybe worth checking others -
besides ufraw there are:

graphics/dcraw
graphics/freeimage
graphics/rawstudio
graphics/libraw
graphics/rawtherapee

(if they don't fail then maybe they're built with -funsigned-char)

[macppc/arm] Unbreak graphics/ufraw (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi :)

> http://build-failures.rhaalovely.net//powerpc/2019-05-19/graphics/ufraw.log
> http://build-failures.rhaalovely.net/aarch64/2019-06-02/graphics/ufraw.log
> http://build-failures.rhaalovely.net/arm/last/graphics/ufraw.log

It's a typical case of code that assumes that char is signed on all
platforms - not much to say.

It has been built and tested on macppc [0] and amd64.

Comments/feedback are welcome!

Charlène. 


[0] https://bsd.network/@julianaito/102246978069502521


Index: Makefile
===
RCS file: /cvs/ports/graphics/ufraw/Makefile,v
retrieving revision 1.49
diff -u -p -u -p -r1.49 Makefile
--- Makefile3 Jun 2019 16:06:51 -   1.49
+++ Makefile10 Jun 2019 11:20:10 -
@@ -3,7 +3,7 @@
 COMMENT=   read and manipulate raw images from digital cameras
 
 DISTNAME=  ufraw-0.22
-REVISION=  3
+REVISION=  4
 
 CATEGORIES=graphics
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=ufraw/}
Index: patches/patch-dcraw_cc
===
RCS file: /cvs/ports/graphics/ufraw/patches/patch-dcraw_cc,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-dcraw_cc
--- patches/patch-dcraw_cc  8 Apr 2018 22:13:54 -   1.4
+++ patches/patch-dcraw_cc  10 Jun 2019 11:20:10 -
@@ -1,4 +1,5 @@
 $OpenBSD: patch-dcraw_cc,v 1.4 2018/04/08 22:13:54 jca Exp $
+- fix narrowing on archs where char is unsigned by default (ppc, arm)
 - can't find abs of uint with clang
   fix stolen from ufraw-current
 - space between literal and identifier
@@ -6,6 +7,15 @@ $OpenBSD: patch-dcraw_cc,v 1.4 2018/04/0
 Index: dcraw.cc
 --- dcraw.cc.orig
 +++ dcraw.cc
+@@ -2285,7 +2285,7 @@ void CLASS quicktake_100_load_raw()
+ 
+ void CLASS kodak_radc_load_raw()
+ {
+-  static const char src[] = {
++  static const signed char src[] = {
+ 1,1, 2,3, 3,4, 4,2, 5,7, 6,5, 7,6, 7,8,
+ 1,0, 2,1, 3,3, 4,4, 5,2, 6,7, 7,6, 8,5, 8,8,
+ 2,1, 2,3, 3,0, 3,2, 3,4, 4,6, 5,5, 6,7, 6,8,
 @@ -9240,13 +9240,13 @@ canon_a5:
filters = 0x16161616;
  }

Re: [ports-gcc] Unbreak astro/celestia (was Re: powerpc bulk build report)

[Jeremie Courreges-Anglas]

On Thu, Jun 06 2019, Charlene Wendling  wrote:
> On Thu, 6 Jun 2019 09:27:07 -0600 (MDT)
> lan...@openbsd.org wrote:
>
>> http://build-failures.rhaalovely.net//powerpc/2019-05-19/astro/celestia.log
>
> This one is easy - it's a (static) bool method, and ports-gcc doesn't
> want NULL as a return value. It's the only problem there was, it builds
> without issues [0] on macppc and amd64.
>
> While here i've moved HOMEPAGE to https.
>
> The runtime is good as well - notably colors aren't off :)

ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

[macppc] Unbreak www/squid (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi,

> http://build-failures.rhaalovely.net//powerpc/2019-05-19/www/squid.log

It happens because upstream made a nice atomic detection code,
that takes -latomic into account (amazing!), but, i quote
$WRKSRC/configure test code:

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */

It's supposed to be uint64_t iirc, so the test fails with:

conftest.cpp:55:6: error: new declaration 'char __atomic_load_8()'
ambiguates built-in declaration 'long long unsigned int
__atomic_load_8(const volatile void*, int)' [-fpermissive]

So yes, i'm adding that block again *sigh*. The test needs to be 
bypassed as well, or it overrides LIBS. 

I've tested the runtime, it works as expected with the default
configuration on macppc (and it doesn't impact other archs).


Comments/feedback are welcome,

Charlène.


Index: Makefile
===
RCS file: /cvs/ports/www/squid/Makefile,v
retrieving revision 1.217
diff -u -p -u -p -r1.217 Makefile
--- Makefile3 Jun 2019 16:06:58 -   1.217
+++ Makefile8 Jun 2019 11:22:47 -
@@ -10,7 +10,9 @@ EXTRACT_SUFX= .tar.xz
 PKGNAME-main=  squid-$V
 PKGNAME-ldap=  squid-ldap-$V
 PKGNAME-ntlm=  squid-ntlm-$V
-REVISION-main= 0
+REVISION-main= 1
+REVISION-ldap= 0
+REVISION-ntlm= 0
 
 CATEGORIES=www
 
@@ -123,6 +125,13 @@ WANTLIB-ldap += ${cWANTLIB} crypto l
 RUN_DEPENDS-ntlm=   net/samba ${BASE_PKGPATH}
 LIB_DEPENDS-ntlm += security/libnettle
 WANTLIB-ntlm=   ${WANTLIB} ${COMPILER_LIBCXX}
+
+.if ${MACHINE_ARCH} == "powerpc"
+WANTLIB += atomic
+# The test in configure don't want atomic builtins, bypass it.
+CONFIGURE_ENV +=   LIBS=-latomic \
+   ac_cv_search___atomic_load_8=-latomic
+.endif
 
 pre-build:
@cd ${WRKSRC}; \

[ports-gcc] Unbreak astro/celestia (was Re: powerpc bulk build report)

[Charlene Wendling]

On Thu, 6 Jun 2019 09:27:07 -0600 (MDT)
lan...@openbsd.org wrote:

> http://build-failures.rhaalovely.net//powerpc/2019-05-19/astro/celestia.log

This one is easy - it's a (static) bool method, and ports-gcc doesn't
want NULL as a return value. It's the only problem there was, it builds
without issues [0] on macppc and amd64.

While here i've moved HOMEPAGE to https.

The runtime is good as well - notably colors aren't off :)

Charlène


[0] http://0x0.st/zuNH.txt


Index: Makefile
===
RCS file: /cvs/ports/astro/celestia/Makefile,v
retrieving revision 1.47
diff -u -p -u -p -r1.47 Makefile
--- Makefile20 May 2019 22:15:00 -  1.47
+++ Makefile6 Jun 2019 18:57:22 -
@@ -3,11 +3,11 @@
 COMMENT=   free space simulator and planetarium
 
 DISTNAME=  celestia-1.6.1
-REVISION=  17
+REVISION=  18
 
 CATEGORIES=astro x11
 
-HOMEPAGE=  http://www.shatters.net/celestia/
+HOMEPAGE=  https://celestia.space/
 
 MAINTAINER=Antoine Jacoutot 
 
Index: patches/patch-src_celengine_parseobject_cpp
===
RCS file: patches/patch-src_celengine_parseobject_cpp
diff -N patches/patch-src_celengine_parseobject_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_celengine_parseobject_cpp 6 Jun 2019 18:57:22 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+ports-gcc fix for:
+parseobject.cpp:280:10: error: converting to 'bool' from 'std::nullptr_t'
+requires direct-initialization 
+
+Index: src/celengine/parseobject.cpp
+--- src/celengine/parseobject.cpp.orig
 src/celengine/parseobject.cpp
+@@ -277,7 +277,7 @@ ParseStringList(Hash* table,
+ {
+   Value* v = table->getValue(propertyName);
+   if (v == NULL)
+-  return NULL;
++  return false;
+ 
+   // Check for a single string first.
+   if (v->getType() == Value::StringType)

Re: Unbreak net/haproxy on macppc (was: Re: powerpc bulk build report)

[Daniel Jakots]

On Sat, 9 Mar 2019 17:55:43 +0100, Charlene Wendling
 wrote:

> This requires atomics at least on macppc, where it has been built 
> sucessfully [1], and probably hppa. 

Wasn't this solved on hppa with
commit 0eb74ae52d1a40be580169c2333dafaaacdb3aac
Author: jca 
Date:   Tue Sep 8 18:28:50 2015 +

Disable the shared SSL session cache on hppa, and remove the BROKEN marker.

hppa lacks the atomic ops needed for this feature.  Other archs may be
good candidates too.

ok Daniel Jakots (maintainer), juanfra@

diff --git a/net/haproxy/Makefile b/net/haproxy/Makefile
index 83b94a7b999..2436c1829f7 100644
--- a/net/haproxy/Makefile
+++ b/net/haproxy/Makefile
@@ -1,6 +1,4 @@
-# $OpenBSD: Makefile,v 1.21 2015/09/07 22:20:52 juanfra Exp $
-
-BROKEN-hppa =  undefined reference to __sync atomic ops
+# $OpenBSD: Makefile,v 1.22 2015/09/08 18:28:50 jca Exp $
 
 COMMENT =  reliable, high performance TCP/HTTP load balancer
 
@@ -28,6 +26,10 @@ MAKE_FLAGS +=CFLAGS="${CFLAGS} -fno-strict-aliasing" 
LDFLAGS="${LDFLAGS}"
 MAKE_FLAGS +=  CC="${CC}" LD="${CC}" TARGET="openbsd"
 MAKE_FLAGS +=  USE_OPENSSL=1 USE_PCRE=1
 
+.if ${MACHINE_ARCH:Mhppa}
+MAKE_FLAGS +=  USE_PRIVATE_CACHE=1
+.endif
+
 NO_TEST =  Yes
 LIB_DEPENDS =  devel/pcre
 


Anyway, as long as you don't break amd64 and you don't make a mess of
the Makefile, no objection from me :)

Unbreak math/veusz on macppc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi ports, Brian,

> http://build-failures.rhaalovely.net//powerpc/2019-02-04/math/veusz.log

The same issue can be found in x11/kde4/marble's patches, it should
use cmath instead of using math.h, and std::.

Testing: 

- macppc: The build and tests are fine [1], i did the tutorial without
  issues [2]
- amd64: The build and tests are fine as well [3] 


Comments (especially because TIMTOWTDI) and feedback are welcome! 

Charlène. 


[1] http://ix.io/1DhU
[2] https://bsd.network/@julianaito/101737076440210681
[3] http://ix.io/1DhV


Index: Makefile
===
RCS file: /cvs/ports/math/veusz/Makefile,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 Makefile
--- Makefile8 Mar 2019 20:00:47 -   1.20
+++ Makefile12 Mar 2019 10:21:51 -
@@ -4,7 +4,7 @@ COMMENT =   scientific plotting and graphi
 MODPY_EGG_VERSION =3.0.1
 DISTNAME = veusz-${MODPY_EGG_VERSION}
 CATEGORIES =   math graphics
-REVISION = 0
+REVISION = 1
 
 HOMEPAGE = https://veusz.github.io/
 MAINTAINER =   Brian Callahan 
Index: patches/patch-veusz_helpers_src_qtloops_isnan_h
===
RCS file: 
/cvs/ports/math/veusz/patches/patch-veusz_helpers_src_qtloops_isnan_h,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-veusz_helpers_src_qtloops_isnan_h
--- patches/patch-veusz_helpers_src_qtloops_isnan_h 24 Apr 2018 15:24:59 
-  1.2
+++ patches/patch-veusz_helpers_src_qtloops_isnan_h 12 Mar 2019 10:21:51 
-
@@ -2,25 +2,38 @@ $OpenBSD: patch-veusz_helpers_src_qtloop
 clang is better at encapsulating C files, so we don't have a macro for isfinite
 or isnan, hence the tests fail!
 
-
+Also, unbreak the build on ports-gcc by using cmath and std namespace.
 Index: veusz/helpers/src/qtloops/isnan.h
 --- veusz/helpers/src/qtloops/isnan.h.orig
 +++ veusz/helpers/src/qtloops/isnan.h
-@@ -33,7 +33,7 @@
+@@ -23,7 +23,7 @@
+  */
+ 
+ #include 
+-#include 
++#include 
+ /* You might try changing the above to  if you have problems.
+  * Whether you use math.h or cmath, you may need to edit the .cpp file
+  * and/or other .h files to use the same header file.
+@@ -33,8 +33,8 @@
  # define isNaN(_a) (__isnan(_a))  /* MacOSX/Darwin definition < 10.4 */
  #elif defined(WIN32) || defined(_isnan) || defined(_MSC_VER)
  # define isNaN(_a) (_isnan(_a))   /* Win32 definition */
 -#elif defined(isnan) || defined(__FreeBSD__) || defined(__osf__)
+-# define isNaN(_a) (isnan(_a))/* GNU definition */
 +#elif defined(isnan) || defined(__FreeBSD__) || defined(__OpenBSD__) || 
defined(__osf__)
- # define isNaN(_a) (isnan(_a))/* GNU definition */
++# define isNaN(_a) (std::isnan(_a))   /* GNU definition */
  #else
  # define isNaN(_a) (std::isnan(_a))
-@@ -50,7 +50,7 @@
+ #endif
+@@ -50,8 +50,8 @@
  # define isFinite(_a) (_finite(_a))   /* Win32 definition */
  #elif defined(__sgi)
  # define isFinite(_a) (_isfinite(_a))
 -#elif defined(isfinite) || defined(__FreeBSD__)
+-# define isFinite(_a) (isfinite(_a))
 +#elif defined(isfinite) || defined(__FreeBSD__) || defined(__OpenBSD__)
- # define isFinite(_a) (isfinite(_a))
++# define isFinite(_a) (std::isfinite(_a))
  #elif defined(__osf__)
  # define isFinite(_a) (finite(_a) && !isNaN(_a))
+ #else

 

Unbreak multimedia/mlt on macppc (was: Re: powerpc bulk build report)

[Charlene Wendling]

> http://build-failures.rhaalovely.net//powerpc/2019-02-04/multimedia/mlt,,-main.log

sparc64 is not impacted as Qt5 is marked BROKEN there, but it's a
ports-gcc-4.9 issue.

Once -std=c++11 provided, it builds on macppc [1]. 'make test' returns
one failure, as seen on amd64. 

I didn't try building x11/kde-applications/kdenlive, it's main consumer,
as i'm trying to focus on what is currently known as broken.

Any comment? 

Charlène.


[1] http://ix.io/1D3d


Index: Makefile
===
RCS file: /cvs/ports/multimedia/mlt/Makefile,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 Makefile
--- Makefile8 Mar 2019 20:00:50 -   1.19
+++ Makefile9 Mar 2019 23:39:54 -
@@ -6,8 +6,8 @@ VERSION =   6.12.0
 DISTNAME = mlt-${VERSION}
 PKGNAME-main = ${DISTNAME}
 PKGNAME-gpl2 = mlt-gpl2-${VERSION}
-REVISION-gpl2 =0
-REVISION-main =0
+REVISION-gpl2 =1
+REVISION-main =1
 
 # XXX versions should be kept in sync together
 SHARED_LIBS =  mlt 3.0
@@ -87,3 +87,9 @@ do-test:
${ALL_TEST_FLAGS} clean all check
 
 .include 
+
+# fix error: #error "Qt requires C++11 support"
   
+# XXX this should be retried once moving to ports-gcc>=8   
   
+.if ${CHOSEN_COMPILER} == "ports-gcc"
+MAKE_ENV += CXXFLAGS="${CXXFLAGS} -std=c++11"  
   
+.endif

Unbreak net/haproxy on macppc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi Daniel, ports,

> http://build-failures.rhaalovely.net//powerpc/2019-02-04/net/haproxy.log

This requires atomics at least on macppc, where it has been built 
sucessfully [1], and probably hppa. 

I've tested a very simple setup with 2 python3's http.server
instances behind it and it was just fine. 

Comments and feedback are welcome!

Charlène.


[1] http://ix.io/1D0l


Index: Makefile
===
RCS file: /cvs/ports/net/haproxy/Makefile,v
retrieving revision 1.55
diff -u -p -u -p -r1.55 Makefile
--- Makefile14 Jan 2019 18:18:59 -  1.55
+++ Makefile9 Mar 2019 16:18:58 -
@@ -38,6 +38,12 @@ EXAMPLES =   acl-content-sw content-sw-sam
 DOCSDIR =  ${PREFIX}/share/doc/haproxy
 EXAMPLESDIR =  ${PREFIX}/share/examples/haproxy
 
+# Fix undefined reference to __atomic_*
+.if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "hppa"
+LDFLAGS += "-latomic"
+WANTLIB += atomic
+.endif
+
 
 pre-install:
${SUBST_CMD} ${WRKSRC}/doc/haproxy.1

Unbreak www/webkitgtk4 on macppc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi ports,

> http://build-failures.rhaalovely.net//powerpc/2019-02-04/www/webkitgtk4.log

On top of jca@'s recent ports-gcc commits, macppc needs some additional
linking bits.

This diff brings two things: 

1) Use long calls and address relaxing. This avoids relocation
   overflows.

2) clang generates code using the __mulodi4 symbol for
   __builtin_mul_overflow. __mulodi4 is only available on archs with
   base-clang. I've modified that upstream submitted patch [1], so it
   targets only clang+powerpc. It will require some changes if other 
   !base-clang archs can really go up to this port very final 
   linking (or a smarter conditional).

Testing:

Runtime is as bad as it is on sparc64. I can only render local static
HTML with www/surf, all the rest results to an "internal Webkit error".
Building with debug flags causes an OOM error so i can't report 
anything sadly.

Comments are very welcome :)

Charlène. 


[1] https://bugs.webkit.org/show_bug.cgi?id=190208


Index: Makefile
===
RCS file: /cvs/ports/www/webkitgtk4/Makefile,v
retrieving revision 1.97
diff -u -p -u -p -r1.97 Makefile
--- Makefile5 Mar 2019 16:24:23 -   1.97
+++ Makefile9 Mar 2019 00:01:57 -
@@ -13,7 +13,7 @@ PORTROACH =   limitw:1,even
 COMMENT =  GTK+ port of the WebKit rendering engine
 
 V =2.22.7
-REVISION = 0
+REVISION = 1
 DISTNAME = webkitgtk-${V}
 PKGNAME =  webkitgtk4-${V}
 EXTRACT_SUFX = .tar.xz
@@ -110,6 +110,13 @@ LDFLAGS += -Wl,--no-keep-memory
 .if ${MACHINE_ARCH} == "i386"
 CFLAGS +=  -march=i686
 CXXFLAGS +=-march=i686
+.endif
+
+# Workaround relocation overflow. 
+.if ${MACHINE_ARCH} == "powerpc"
+CFLAGS +=  -mlongcall
+CXXFLAGS +=-mlongcall
+LDFLAGS += -Wl,--relax
 .endif
 
 post-extract:
Index: patches/patch-Source_WTF_wtf_CheckedArithmetic_h
===
RCS file: patches/patch-Source_WTF_wtf_CheckedArithmetic_h
diff -N patches/patch-Source_WTF_wtf_CheckedArithmetic_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-Source_WTF_wtf_CheckedArithmetic_h9 Mar 2019 00:01:57 
-
@@ -0,0 +1,52 @@
+$OpenBSD$
+
+macppc linking fix: with ports-clang, libgcc is used instead of compiler-rt,
+and it does not provide the __mulodi4 symbol used by clang for
+__builtin_mul_overflow.
+
+Other !base-clang archs should be added if they can
+go up to the final linking parts.
+
+see https://bugs.webkit.org/show_bug.cgi?id=190208
+
+Index: Source/WTF/wtf/CheckedArithmetic.h
+--- Source/WTF/wtf/CheckedArithmetic.h.orig
 Source/WTF/wtf/CheckedArithmetic.h
+@@ -32,6 +32,10 @@
+ #include 
+ #include 
+ 
++#if COMPILER(GCC_OR_CLANG) && !(defined(__clang__) && defined(__powerpc__))
++#define USE_MUL_OVERFLOW 1
++#endif 
++
+ /* Checked
+  *
+  * This class provides a mechanism to perform overflow-safe integer arithmetic
+@@ -317,7 +321,7 @@ template  struct ArithmeticOperat
+ 
+ static inline bool multiply(int64_t lhs, int64_t rhs, ResultType& result)
+ {
+-#if COMPILER(GCC_OR_CLANG)
++#if USE(MUL_OVERFLOW)
+ ResultType temp;
+ if (__builtin_mul_overflow(lhs, rhs, ))
+ return false;

Unbreak net/bro on macppc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi ports,

> http://build-failures.rhaalovely.net//powerpc/2019-02-04/net/bro.log

It requires libatomic. According to what i read in the ports tree, hppa
would need that as well, so i added it.

It builds fine on macppc [1], i've seen nothing wrong during runtime as
well, but i've nothing fancy to monitor tbh.

Any comments? 

Charlène. 

[1] http://ix.io/1CxH


Index: Makefile
===
RCS file: /cvs/ports/net/bro/Makefile,v
retrieving revision 1.48
diff -u -p -u -p -r1.48 Makefile
--- Makefile30 Dec 2018 14:14:14 -  1.48
+++ Makefile4 Mar 2019 14:23:24 -
@@ -62,6 +62,12 @@ RUN_DEPENDS +=   net/curl
 
 CONFIGURE_STYLE=   simple
 
+# Fix undefined reference to __atomic_load_8
+.if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "hppa"
+LDFLAGS += "-latomic"
+WANTLIB += atomic
+.endif
+
 CONFIGURE_ENV= LDFLAGS="${LDFLAGS} -L$
{LOCALBASE}/lib/libbind \ -lbind -Wl,-rpath ${LOCALBASE}/lib/libbind"
 

Unbreak editors/neovim on macppc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi ports, Edd,

> http://build-failures.rhaalovely.net//powerpc/2019-02-04/editors/neovim.log

It seems the issue has been introduced when upstream added OpenBSD
support [1].

The diff drops the global -lc++abi flag to use it only on base-clang
archs. I've bumped revision, as it may change flags on some archs, i'm
thinking especially at other ports-gcc archs (it has been bulk built on
sparc64).

I'm not sure about how it should be done. I could have changed 
CMakeLists.txt to target macppc as well. Any thought on this?

Testing: 

- macppc/ports-gcc: it builds [2] and runs [3] fine
- amd64/base-clang: it builds [4] and runs fine as well.


Feedback and comments are welcome!

Charlène. 


[1]
https://github.com/neovim/neovim/pull/8215/commits/9d767d3d948f1fdd90c614d23ea7c98e3bfcda6a
[2] http://ix.io/1CrW
[3] https://bsd.network/@julianaito/101686351316975478
[4] http://ix.io/1Csb

Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 Makefile
--- Makefile24 Oct 2018 14:28:01 -  1.12
+++ Makefile3 Mar 2019 11:51:07 -
@@ -5,7 +5,7 @@ COMMENT =   continuation and extension of 
 GH_ACCOUNT =   neovim
 GH_PROJECT =   neovim
 GH_TAGNAME =   v0.3.1
-REVISION = 1
+REVISION = 2
 
 CATEGORIES =   editors devel
 HOMEPAGE = http://neovim.org
@@ -57,5 +57,11 @@ TEST_DEPENDS =   shells/bash \
 do-test:
cd ${WRKSRC} && env LC_CTYPE=en_US.UTF-8 ${MAKE_PROGRAM} \
-C src/nvim/testdir NVIM_PRG=${WRKBUILD}/bin/nvim ${MAKE_FLAGS}
+
+.include 
+
+.if ${PROPERTIES:Mclang}
+CONFIGURE_ARGS += -DNVIM_LINK_LIBRARIES="-lc++abi"
+.endif
 
 .include 
Index: patches/patch-src_nvim_CMakeLists_txt
===
RCS file: patches/patch-src_nvim_CMakeLists_txt
diff -N patches/patch-src_nvim_CMakeLists_txt
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_nvim_CMakeLists_txt   3 Mar 2019 11:51:07 -
@@ -0,0 +1,15 @@
+$OpenBSD$
+Fix build with ports-gcc by removing c++abi here to put it in
+the port Makefile instead.
+Index: src/nvim/CMakeLists.txt
+--- src/nvim/CMakeLists.txt.orig
 src/nvim/CMakeLists.txt
+@@ -360,7 +360,7 @@ endforeach()
+ # Our dependencies come first.
+ 
+ if (CMAKE_SYSTEM_NAME MATCHES "OpenBSD")
+-  list(APPEND NVIM_LINK_LIBRARIES pthread c++abi)
++  list(APPEND NVIM_LINK_LIBRARIES pthread)
+ endif()
+ 
+ if (LibIntl_FOUND)

Fix games/dangerdeep build with ports-gcc (was: Re: powerpc bulk build report)

[Charlene Wendling]

Hi ports!

> http://build-failures.rhaalovely.net//powerpc/2019-01-01/games/dangerdeep.log

There was just a missing header. It builds [1] and runs fine on macppc
and doesn't break the amd64 build.

Charlène. 

[1] http://ix.io/1yAF

Index: Makefile
===
RCS file: /cvs/ports/games/dangerdeep/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile24 Oct 2018 14:28:02 -  1.7
+++ Makefile18 Jan 2019 09:53:58 -
@@ -3,7 +3,7 @@
 COMMENT =  WWII German submarine simulator
 
 PKGNAME =  dangerdeep-0.3.99.3327
-REVISION = 3
+REVISION = 4
 
 CATEGORIES =   games
 
Index: patches/patch-src_matrix3_h
===
RCS file: patches/patch-src_matrix3_h
diff -N patches/patch-src_matrix3_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_matrix3_h 18 Jan 2019 09:53:58 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/matrix3.h
+--- src/matrix3.h.orig
 src/matrix3.h
+@@ -24,6 +24,7 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, 
+ #ifndef MATRIX3_H
+ #define MATRIX3_H
+ 
++#include 
+ #include "matrix.h"
+ 
+ /// a 3x3 matrix, reimplemented for 3x3 case for speed issues

Re: haproxy on gcc archs (was: Re: powerpc bulk build report)

[Daniel Jakots]

On Mon, 14 Jan 2019 19:01:26 +0100, Jeremie Courreges-Anglas
 wrote:

> On Fri, Jan 11 2019, lan...@openbsd.org wrote:
> 
> [...]
> 
> > http://build-failures.rhaalovely.net//powerpc/2019-01-01/net/haproxy.log  
> 
> Fails to build on powerpc and sparc64 because base-gcc has no TLS
> emulation support.  Here's a diff that makes haproxy use ports-gcc on
> non-clang archs, successfully tested on sparc64.
> 
> While here, ports-gcc should bring support for atomic ops on hppa, so
> the special case shouldn't be needed.
> 
> ok?

no objection :)

haproxy on gcc archs (was: Re: powerpc bulk build report)

[Jeremie Courreges-Anglas]

On Fri, Jan 11 2019, lan...@openbsd.org wrote:

[...]

> http://build-failures.rhaalovely.net//powerpc/2019-01-01/net/haproxy.log

Fails to build on powerpc and sparc64 because base-gcc has no TLS
emulation support.  Here's a diff that makes haproxy use ports-gcc on
non-clang archs, successfully tested on sparc64.

While here, ports-gcc should bring support for atomic ops on hppa, so
the special case shouldn't be needed.

ok?


Index: Makefile
===
RCS file: /cvs/ports/net/haproxy/Makefile,v
retrieving revision 1.53
diff -u -p -r1.53 Makefile
--- Makefile11 Jan 2019 01:09:50 -  1.53
+++ Makefile14 Jan 2019 17:56:02 -
@@ -26,11 +26,7 @@ MAKE_FLAGS +=CFLAGS="${CFLAGS} -fno-str
 MAKE_FLAGS +=  CC="${CC}" LD="${CC}" TARGET="openbsd"
 MAKE_FLAGS +=  USE_OPENSSL=1 USE_PCRE=1
 
-# The shared SSL session cache needs either atomics ops unsupported on
-# hppa or pthreads features unsupported on OpenBSD.
-.if ${MACHINE_ARCH:Mhppa}
-MAKE_FLAGS +=  USE_PRIVATE_CACHE=1
-.endif
+COMPILER = base-clang ports-gcc
 
 LIB_DEPENDS =  devel/pcre
 


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: powerpc bulk build report

[Charlene Wendling]

On Sat, 12 Jan 2019 22:28:38 +0100
Christian Weisgerber wrote:

> Charlene Wendling:
> 
> > > http://build-failures.rhaalovely.net//powerpc/2019-01-01/x11/bbpager.log
> > 
> > It fails because some headers are missing.  With those patches, it 
> > builds [1] and runs [2] fine on macppc, and doesn't break amd64
> > build.
> > 
> > Comments/feedback are welcome! 
> 
> Personally, I try to follow the existing style of the source, i.e.,
> if C headers are included in their C form like
> 
> #include 
> 
> then I'll add  and not .
> 
> -- 
> Christian "naddy" Weisgerber
> na...@mips.inka.de
> 

Hi, 

Here it is. I'm unhappy as well with Baseresource.cxx, but it would 
make the patch intent's less clear. 

Charlène. 

Index: Makefile
===
RCS file: /cvs/ports/x11/bbpager/Makefile,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 Makefile
--- Makefile24 Oct 2018 14:28:12 -  1.27
+++ Makefile13 Jan 2019 13:39:23 -
@@ -3,7 +3,7 @@
 COMMENT =  pager for the Blackbox window manager
 
 DISTNAME = bbpager-0.4.7
-REVISION = 6
+REVISION = 7
 
 CATEGORIES =   x11
 MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=bbtools/}
Index: patches/patch-src_Baseresource_cxx
===
RCS file: patches/patch-src_Baseresource_cxx
diff -N patches/patch-src_Baseresource_cxx
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_Baseresource_cxx  13 Jan 2019 13:39:23 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/Baseresource.cxx
+--- src/Baseresource.cxx.orig
 src/Baseresource.cxx
+@@ -22,6 +22,7 @@
+ #include 
+ #include "Baseresource.h"
+ #include 
++#include 
+ #include "Menu.hh"
+ 
+ BaseResource::BaseResource(bt::Application &_app, unsigned int _screen, const 
std::string _rc_filename, const std::string ) : 
Index: patches/patch-src_main_cxx
===
RCS file: patches/patch-src_main_cxx
diff -N patches/patch-src_main_cxx
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_main_cxx  13 Jan 2019 13:39:23 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/main.cxx
+--- src/main.cxx.orig
 src/main.cxx
+@@ -24,6 +24,7 @@
+ #include "config.h"
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ 
Index: patches/patch-src_resource_cxx
===
RCS file: patches/patch-src_resource_cxx
diff -N patches/patch-src_resource_cxx
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_resource_cxx  13 Jan 2019 13:39:23 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/resource.cxx
+--- src/resource.cxx.orig
 src/resource.cxx
+@@ -19,6 +19,7 @@
+ // (See the included file COPYING / GPL-2.0)
+ //
+ 
++#include 
+ #include "resource.h"
+ #include "blackboxstyle.h"
+ 

Re: powerpc bulk build report

[Christian Weisgerber]

Charlene Wendling:

> > http://build-failures.rhaalovely.net//powerpc/2019-01-01/x11/bbpager.log
> 
> It fails because some headers are missing.  With those patches, it 
> builds [1] and runs [2] fine on macppc, and doesn't break amd64 build.
> 
> Comments/feedback are welcome! 

Personally, I try to follow the existing style of the source, i.e.,
if C headers are included in their C form like

#include 

then I'll add  and not .

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: powerpc bulk build report

[Charlene Wendling]

Hi ports, Landry, 

On Fri, 11 Jan 2019 15:33:47 -0700 (MST)
lan...@openbsd.org wrote:


> http://build-failures.rhaalovely.net//powerpc/2019-01-01/x11/bbpager.log

It fails because some headers are missing.  With those patches, it 
builds [1] and runs [2] fine on macppc, and doesn't break amd64 build.

Comments/feedback are welcome! 

Charlène. 

[1] http://ix.io/1y7P
[2] https://bsd.network/@julianaito/101404040478256794


Index: Makefile
===
RCS file: /cvs/ports/x11/bbpager/Makefile,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 Makefile
--- Makefile24 Oct 2018 14:28:12 -  1.27
+++ Makefile12 Jan 2019 14:00:05 -
@@ -3,7 +3,7 @@
 COMMENT =  pager for the Blackbox window manager
 
 DISTNAME = bbpager-0.4.7
-REVISION = 6
+REVISION = 7
 
 CATEGORIES =   x11
 MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=bbtools/}
Index: patches/patch-src_Baseresource_cxx
===
RCS file: patches/patch-src_Baseresource_cxx
diff -N patches/patch-src_Baseresource_cxx
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_Baseresource_cxx  12 Jan 2019 14:00:05 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/Baseresource.cxx
+--- src/Baseresource.cxx.orig
 src/Baseresource.cxx
+@@ -20,6 +20,7 @@
+ //
+ 
+ #include 
++#include 
+ #include "Baseresource.h"
+ #include 
+ #include "Menu.hh"
Index: patches/patch-src_main_cxx
===
RCS file: patches/patch-src_main_cxx
diff -N patches/patch-src_main_cxx
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_main_cxx  12 Jan 2019 14:00:05 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/main.cxx
+--- src/main.cxx.orig
 src/main.cxx
+@@ -25,6 +25,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ 
Index: patches/patch-src_resource_cxx
===
RCS file: patches/patch-src_resource_cxx
diff -N patches/patch-src_resource_cxx
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_resource_cxx  12 Jan 2019 14:00:05 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Fix missing header for ports-gcc
+Index: src/resource.cxx
+--- src/resource.cxx.orig
 src/resource.cxx
+@@ -21,6 +21,7 @@
+ 
+ #include "resource.h"
+ #include "blackboxstyle.h"
++#include 
+ 
+ Resource::Resource(ToolWindow *toolwindow, const std::string 
_rc_file, const std::string _file): 
+ BaseResource(*toolwindow, toolwindow->getCurrentScreen(), 
blackbox_rc_file, rc_file), bbtool(toolwindow)

Re: llvm dep on g++ (was: Re: powerpc bulk build report)

[Stuart Henderson]

On 2019/01/04 12:47, Jeremie Courreges-Anglas wrote:
> On Mon, Dec 31 2018, George Koehler  wrote:
> > On Mon, 31 Dec 2018 00:15:56 -0700 (MST)
> > lan...@openbsd.org wrote:
> >
> >> http://build-failures.rhaalovely.net//powerpc/2018-12-14/x11/qt5/qtbase.log
> >
> > Fails to #include , a C++ standard library header.
> > Is llvm missing a dependency on g++?
> 
> Yup.  On sparc64:
> 
> -->8--
> @depend devel/gtest:gtest-*:gtest-1.8.0p3
> @depend lang/gcc/4.9,-libs:gcc-libs->=4.9,<4.10:gcc-libs-4.9.4p12
> @depend lang/python/2.7,-main:python->=2.7,<2.8:python-2.7.15p1
> --8<--
> 
> > At the top of the log, gcc-4.9.4p15 and gcc-libs-4.9.4p15 and
> > llvm-6.0.1p19 get installed, but g++ doesn't.
> >
> >> ===>  Compiler link: gcc -> /usr/local/bin/clang
> >> ===>  Compiler link: cc -> /usr/local/bin/clang
> >> ===>  Compiler link: clang -> /usr/local/bin/clang
> >> ===>  Compiler link: g++ -> /usr/local/bin/clang++
> >> ===>  Compiler link: c++ -> /usr/local/bin/clang++
> >> ===>  Compiler link: clang++ -> /usr/local/bin/clang++
> >
> > The compiler is ports-clang from the llvm package.  The compiler
> > needs a C++ library.  It can't use libc++ from base-clang because
> > powerpc doesn't have base-clang.  It can't use libstdc++ from
> > base-gcc because that lib can't do C++11.
> >
> > It must use libestdc++ from ports-gcc.  The library is in the
> > gcc-libs package but its headers are in the g++ package!  This is
> > odd because most libraries have their headers in the same package.
> >
> > lang/clang/clang.port.mk uses `MODULES += gcc4` to find libestdc++
> > and add the dependency on gcc-libs.  Then lang/gcc/4.9/gcc4.port.mk
> > does `MODGCC4_LANGS += c` to add a dependency on the gcc package.
> > There seems to be no dependency on the g++ package.  This might
> > allow dpb to junk g++ after it builds llvm (using g++) and before
> > it builds qtbase.
> 
> Thanks a lot for the analysis.  The problem is the way the dep on g++ is
> added: CHOSEN_COMPILER can only be known after including ,
> but IIUC at that time it's too late to amend RUN/TEST_DEPENDS.
> 
> cc'ing Marc in case he has more input, and Landry since he's probably
> hitting this issue since a long time.
> 
> Build on ongoing on sparc64 with the diff below:

I think that's a reasonable fix. I've just been pondering whether to
move the headers to gcc-libs, but it seems enough of a special case
that it's probably better done that way.

Okay with me if tests go well.

Re: llvm dep on g++ (was: Re: powerpc bulk build report)

[Marc Espie]

On Fri, Jan 04, 2019 at 12:47:26PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Dec 31 2018, George Koehler  wrote:
> > On Mon, 31 Dec 2018 00:15:56 -0700 (MST)
> > lan...@openbsd.org wrote:
> >
> >> http://build-failures.rhaalovely.net//powerpc/2018-12-14/x11/qt5/qtbase.log
> >
> > Fails to #include , a C++ standard library header.
> > Is llvm missing a dependency on g++?
> 
> Yup.  On sparc64:
> 
> -->8--
> @depend devel/gtest:gtest-*:gtest-1.8.0p3
> @depend lang/gcc/4.9,-libs:gcc-libs->=4.9,<4.10:gcc-libs-4.9.4p12
> @depend lang/python/2.7,-main:python->=2.7,<2.8:python-2.7.15p1
> --8<--
> 
> > At the top of the log, gcc-4.9.4p15 and gcc-libs-4.9.4p15 and
> > llvm-6.0.1p19 get installed, but g++ doesn't.
> >
> >> ===>  Compiler link: gcc -> /usr/local/bin/clang
> >> ===>  Compiler link: cc -> /usr/local/bin/clang
> >> ===>  Compiler link: clang -> /usr/local/bin/clang
> >> ===>  Compiler link: g++ -> /usr/local/bin/clang++
> >> ===>  Compiler link: c++ -> /usr/local/bin/clang++
> >> ===>  Compiler link: clang++ -> /usr/local/bin/clang++
> >
> > The compiler is ports-clang from the llvm package.  The compiler
> > needs a C++ library.  It can't use libc++ from base-clang because
> > powerpc doesn't have base-clang.  It can't use libstdc++ from
> > base-gcc because that lib can't do C++11.
> >
> > It must use libestdc++ from ports-gcc.  The library is in the
> > gcc-libs package but its headers are in the g++ package!  This is
> > odd because most libraries have their headers in the same package.
> >
> > lang/clang/clang.port.mk uses `MODULES += gcc4` to find libestdc++
> > and add the dependency on gcc-libs.  Then lang/gcc/4.9/gcc4.port.mk
> > does `MODGCC4_LANGS += c` to add a dependency on the gcc package.
> > There seems to be no dependency on the g++ package.  This might
> > allow dpb to junk g++ after it builds llvm (using g++) and before
> > it builds qtbase.
> 
> Thanks a lot for the analysis.  The problem is the way the dep on g++ is
> added: CHOSEN_COMPILER can only be known after including ,
> but IIUC at that time it's too late to amend RUN/TEST_DEPENDS.
> 
> cc'ing Marc in case he has more input, and Landry since he's probably
> hitting this issue since a long time.
> 
> Build on ongoing on sparc64 with the diff below:

Yep, using PROPERTIES is the way to go... 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/llvm/Makefile,v
> retrieving revision 1.203
> diff -u -p -r1.203 Makefile
> --- Makefile  4 Jan 2019 00:14:57 -   1.203
> +++ Makefile  4 Jan 2019 11:36:37 -
> @@ -20,7 +20,7 @@ PKGSPEC-main =  llvm-=${LLVM_V}
>  PKGNAME-main =   llvm-${LLVM_V}
>  PKGNAME-python = py-llvm-${LLVM_V}
>  PKGNAME-lldb =   lldb-${LLVM_V}
> -REVISION-main =  21
> +REVISION-main =  22
>  REVISION-python = 4
>  REVISION-lldb =  1
>  CATEGORIES = devel
> @@ -61,6 +61,13 @@ BUILD_DEPENDS +=   devel/swig \
>   textproc/py-sphinx
>  RUN_DEPENDS +=   devel/gtest
>  
> +.include 
> +
> +.if !${PROPERTIES:Mclang}
> +TEST_DEPENDS +=  lang/gcc/${MODGCC4_VERSION},-c++
> +RUN_DEPENDS +=   lang/gcc/${MODGCC4_VERSION},-c++
> +.endif
> +
>  # clang python module loads libclang.so dynamically with cdll.LoadLibrary()
>  WANTLIB-python = clang
>  RUN_DEPENDS-python = ${MODPY_RUN_DEPENDS}
> @@ -108,8 +115,6 @@ GCC_CONFIG =  ${MACHINE_ARCH}-unknown-op
>  CLANG_INCLUDE_PATH = lib/clang/${LLVM_V}/include
>  SUBST_VARS +=CLANG_INCLUDE_PATH LLVM_V GCC_VER GCC_CONFIG
>  
> -.include 
> -
>  post-extract:
>   mv ${WRKDIR}/cfe-${LLVM_V}.src ${WRKSRC}/tools/clang
>   mv ${WRKDIR}/lld-${LLVM_V}.src ${WRKSRC}/tools/lld
> @@ -146,8 +151,3 @@ post-install:
>  .endif
>  
>  .include 
> -
> -.if ${CHOSEN_COMPILER} == "ports-gcc"
> -TEST_DEPENDS +=  lang/gcc/${MODGCC4_VERSION},-c++
> -RUN_DEPENDS +=   lang/gcc/${MODGCC4_VERSION},-c++
> -.endif
> 
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

llvm dep on g++ (was: Re: powerpc bulk build report)

[Jeremie Courreges-Anglas]

On Mon, Dec 31 2018, George Koehler  wrote:
> On Mon, 31 Dec 2018 00:15:56 -0700 (MST)
> lan...@openbsd.org wrote:
>
>> http://build-failures.rhaalovely.net//powerpc/2018-12-14/x11/qt5/qtbase.log
>
> Fails to #include , a C++ standard library header.
> Is llvm missing a dependency on g++?

Yup.  On sparc64:

-->8--
@depend devel/gtest:gtest-*:gtest-1.8.0p3
@depend lang/gcc/4.9,-libs:gcc-libs->=4.9,<4.10:gcc-libs-4.9.4p12
@depend lang/python/2.7,-main:python->=2.7,<2.8:python-2.7.15p1
--8<--

> At the top of the log, gcc-4.9.4p15 and gcc-libs-4.9.4p15 and
> llvm-6.0.1p19 get installed, but g++ doesn't.
>
>> ===>  Compiler link: gcc -> /usr/local/bin/clang
>> ===>  Compiler link: cc -> /usr/local/bin/clang
>> ===>  Compiler link: clang -> /usr/local/bin/clang
>> ===>  Compiler link: g++ -> /usr/local/bin/clang++
>> ===>  Compiler link: c++ -> /usr/local/bin/clang++
>> ===>  Compiler link: clang++ -> /usr/local/bin/clang++
>
> The compiler is ports-clang from the llvm package.  The compiler
> needs a C++ library.  It can't use libc++ from base-clang because
> powerpc doesn't have base-clang.  It can't use libstdc++ from
> base-gcc because that lib can't do C++11.
>
> It must use libestdc++ from ports-gcc.  The library is in the
> gcc-libs package but its headers are in the g++ package!  This is
> odd because most libraries have their headers in the same package.
>
> lang/clang/clang.port.mk uses `MODULES += gcc4` to find libestdc++
> and add the dependency on gcc-libs.  Then lang/gcc/4.9/gcc4.port.mk
> does `MODGCC4_LANGS += c` to add a dependency on the gcc package.
> There seems to be no dependency on the g++ package.  This might
> allow dpb to junk g++ after it builds llvm (using g++) and before
> it builds qtbase.

Thanks a lot for the analysis.  The problem is the way the dep on g++ is
added: CHOSEN_COMPILER can only be known after including ,
but IIUC at that time it's too late to amend RUN/TEST_DEPENDS.

cc'ing Marc in case he has more input, and Landry since he's probably
hitting this issue since a long time.

Build on ongoing on sparc64 with the diff below:


Index: Makefile
===
RCS file: /cvs/ports/devel/llvm/Makefile,v
retrieving revision 1.203
diff -u -p -r1.203 Makefile
--- Makefile4 Jan 2019 00:14:57 -   1.203
+++ Makefile4 Jan 2019 11:36:37 -
@@ -20,7 +20,7 @@ PKGSPEC-main =llvm-=${LLVM_V}
 PKGNAME-main = llvm-${LLVM_V}
 PKGNAME-python =   py-llvm-${LLVM_V}
 PKGNAME-lldb = lldb-${LLVM_V}
-REVISION-main =21
+REVISION-main =22
 REVISION-python = 4
 REVISION-lldb =1
 CATEGORIES =   devel
@@ -61,6 +61,13 @@ BUILD_DEPENDS += devel/swig \
textproc/py-sphinx
 RUN_DEPENDS += devel/gtest
 
+.include 
+
+.if !${PROPERTIES:Mclang}
+TEST_DEPENDS +=lang/gcc/${MODGCC4_VERSION},-c++
+RUN_DEPENDS += lang/gcc/${MODGCC4_VERSION},-c++
+.endif
+
 # clang python module loads libclang.so dynamically with cdll.LoadLibrary()
 WANTLIB-python =   clang
 RUN_DEPENDS-python =   ${MODPY_RUN_DEPENDS}
@@ -108,8 +115,6 @@ GCC_CONFIG =${MACHINE_ARCH}-unknown-op
 CLANG_INCLUDE_PATH =   lib/clang/${LLVM_V}/include
 SUBST_VARS +=  CLANG_INCLUDE_PATH LLVM_V GCC_VER GCC_CONFIG
 
-.include 
-
 post-extract:
mv ${WRKDIR}/cfe-${LLVM_V}.src ${WRKSRC}/tools/clang
mv ${WRKDIR}/lld-${LLVM_V}.src ${WRKSRC}/tools/lld
@@ -146,8 +151,3 @@ post-install:
 .endif
 
 .include 
-
-.if ${CHOSEN_COMPILER} == "ports-gcc"
-TEST_DEPENDS +=lang/gcc/${MODGCC4_VERSION},-c++
-RUN_DEPENDS += lang/gcc/${MODGCC4_VERSION},-c++
-.endif


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: powerpc bulk build report

[Landry Breuil]

On Mon, Dec 31, 2018 at 06:01:03PM -0500, George Koehler wrote:
> On Mon, 31 Dec 2018 00:15:56 -0700 (MST)
> lan...@openbsd.org wrote:
> 
> > http://build-failures.rhaalovely.net//powerpc/2018-12-14/x11/qt5/qtbase.log
> 
> Fails to #include , a C++ standard library header.
> Is llvm missing a dependency on g++?
> 
> At the top of the log, gcc-4.9.4p15 and gcc-libs-4.9.4p15 and
> llvm-6.0.1p19 get installed, but g++ doesn't.
> 
> > ===>  Compiler link: gcc -> /usr/local/bin/clang
> > ===>  Compiler link: cc -> /usr/local/bin/clang
> > ===>  Compiler link: clang -> /usr/local/bin/clang
> > ===>  Compiler link: g++ -> /usr/local/bin/clang++
> > ===>  Compiler link: c++ -> /usr/local/bin/clang++
> > ===>  Compiler link: clang++ -> /usr/local/bin/clang++
> 
> The compiler is ports-clang from the llvm package.  The compiler
> needs a C++ library.  It can't use libc++ from base-clang because
> powerpc doesn't have base-clang.  It can't use libstdc++ from
> base-gcc because that lib can't do C++11.

ports-clang should never be used for c++-code. It almost always break
with configure errors about 'c compiler not being able to compile code'.
i think i have it removed locally from COMPILER in x11/qt5/qt5.port.mk
but i dont remember if this is on sparc64 or macppc or both.

Landry

Re: powerpc bulk build report

[George Koehler]

On Mon, 31 Dec 2018 00:15:56 -0700 (MST)
lan...@openbsd.org wrote:

> http://build-failures.rhaalovely.net//powerpc/2018-12-14/x11/qt5/qtbase.log

Fails to #include , a C++ standard library header.
Is llvm missing a dependency on g++?

At the top of the log, gcc-4.9.4p15 and gcc-libs-4.9.4p15 and
llvm-6.0.1p19 get installed, but g++ doesn't.

> ===>  Compiler link: gcc -> /usr/local/bin/clang
> ===>  Compiler link: cc -> /usr/local/bin/clang
> ===>  Compiler link: clang -> /usr/local/bin/clang
> ===>  Compiler link: g++ -> /usr/local/bin/clang++
> ===>  Compiler link: c++ -> /usr/local/bin/clang++
> ===>  Compiler link: clang++ -> /usr/local/bin/clang++

The compiler is ports-clang from the llvm package.  The compiler
needs a C++ library.  It can't use libc++ from base-clang because
powerpc doesn't have base-clang.  It can't use libstdc++ from
base-gcc because that lib can't do C++11.

It must use libestdc++ from ports-gcc.  The library is in the
gcc-libs package but its headers are in the g++ package!  This is
odd because most libraries have their headers in the same package.

lang/clang/clang.port.mk uses `MODULES += gcc4` to find libestdc++
and add the dependency on gcc-libs.  Then lang/gcc/4.9/gcc4.port.mk
does `MODGCC4_LANGS += c` to add a dependency on the gcc package.
There seems to be no dependency on the g++ package.  This might
allow dpb to junk g++ after it builds llvm (using g++) and before
it builds qtbase.

-- 
George Koehler 

Re: powerpc bulk build report

[Marc Espie]

On Sat, Dec 15, 2018 at 03:08:26AM +0100, Charlene Wendling wrote:
> Hi, 
> 
> Marc, i'm CC-ing you because there is a x11/xglobe diff with "surprising"
> results (at the bottom). 

Nothing surprising about it.

Okay for that part.
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/xglobe/Makefile,v
> retrieving revision 1.77
> diff -u -p -u -p -r1.77 Makefile
> --- Makefile  24 Oct 2018 14:28:14 -  1.77
> +++ Makefile  15 Dec 2018 00:25:47 -
> @@ -9,7 +9,7 @@ HOMEPAGE= http://www.shaderwrangler.com/
>  MASTER_SITES=https://distfiles.nl/
>  DISTNAME=xglobe-0.5p2
>  PKGNAME= xglobe-0.5
> -REVISION=43
> +REVISION=44
>  
>  MAINTAINER=  Marc Espie 
>  
> Index: patches/patch-desktopwidget_cpp
> ===
> RCS file: patches/patch-desktopwidget_cpp
> diff -N patches/patch-desktopwidget_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-desktopwidget_cpp   15 Dec 2018 00:25:47 -
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +Fix for ports-gcc-4.9:
> +desktopwidget.cpp:34:5: error: '::exit' has not been declared
> +Index: desktopwidget.cpp
> +--- desktopwidget.cpp.orig
>  desktopwidget.cpp
> +@@ -31,7 +31,7 @@ DesktopWidget::DesktopWidget(QWidget *parent, const ch
> +   if(!currentImage)
> +   {
> + fprintf(stderr, "Not enough memory!\n");
> +-::exit(1);
> ++std::exit(1);
> +   }
> + //  fprintf(stderr, "Desktop size: %dx%d\n",width(), height());
> + }
> Index: patches/patch-desktopwidget_h
> ===
> RCS file: patches/patch-desktopwidget_h
> diff -N patches/patch-desktopwidget_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-desktopwidget_h 15 Dec 2018 00:25:47 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +Fix for ports-gcc-4.9:
> +desktopwidget.cpp:34:5: error: '::exit' has not been declared
> +Index: desktopwidget.h
> +--- desktopwidget.h.orig
>  desktopwidget.h
> +@@ -26,6 +26,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + 
> + class DesktopWidget : public QWidget
> + {
> Index: patches/patch-renderer_cpp
> ===
> RCS file: /cvs/ports/x11/xglobe/patches/patch-renderer_cpp,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 patch-renderer_cpp
> --- patches/patch-renderer_cpp23 Nov 2002 15:45:19 -  1.5
> +++ patches/patch-renderer_cpp15 Dec 2018 00:25:47 -
> @@ -1,7 +1,8 @@
>  $OpenBSD: patch-renderer_cpp,v 1.5 2002/11/23 15:45:19 espie Exp $
>  renderer.cpp.origSat Nov 23 16:34:35 2002
> -+++ renderer.cpp Sat Nov 23 16:34:49 2002
> -@@ -91,6 +91,8 @@ Renderer::Renderer(const QSize , co
> +Index: renderer.cpp
> +--- renderer.cpp.orig
>  renderer.cpp
> +@@ -91,6 +91,8 @@ Renderer::Renderer(const QSize , const char *mapf
> mapcloud = NULL;
> track_clouds = NULL;
> 
> @@ -10,7 +11,7 @@ $OpenBSD: patch-renderer_cpp,v 1.5 2002/
> renderedImage = new QImage(size, 32);
> if(!renderedImage)
> {
> -@@ -98,8 +100,6 @@ Renderer::Renderer(const QSize , co
> +@@ -98,8 +100,6 @@ Renderer::Renderer(const QSize , const char *mapf
>   ::exit(1);
> }
>   
> 
> 
> Charlène. 

Re: powerpc bulk build report

[Charlene Wendling]

Hi, 

Marc, i'm CC-ing you because there is a x11/xglobe diff with "surprising"
results (at the bottom). 

Here is another round of macppc fixes that should also help for other gcc4
archs. 


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/net/xprobe.log

Yet another one with missing includes. Build [1] and runtime is ok.
But honestly OS signatures are super old ;) It doesn't break on amd64.

[1] http://ix.io/1vZJ


Index: Makefile
===
RCS file: /cvs/ports/net/xprobe/Makefile,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 Makefile
--- Makefile24 Oct 2018 14:28:09 -  1.23
+++ Makefile14 Dec 2018 17:45:07 -
@@ -3,7 +3,7 @@
 COMMENT=   ICMP active OS fingerprint scanner
 
 DISTNAME=  xprobe2-0.3
-REVISION = 3
+REVISION = 4
 CATEGORIES=net security
 
 HOMEPAGE=  http://xprobe.sourceforge.net/
Index: patches/patch-libs-external_USI++_src_ip_cc
===
RCS file: patches/patch-libs-external_USI++_src_ip_cc
diff -N patches/patch-libs-external_USI++_src_ip_cc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-libs-external_USI++_src_ip_cc 14 Dec 2018 17:45:07 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+ip.cc:34:19: error: 'srand' was not declared in this scope with ports-gcc
+Index: libs-external/USI++/src/ip.cc
+--- libs-external/USI++/src/ip.cc.orig
 libs-external/USI++/src/ip.cc
+@@ -16,6 +16,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ 
Index: patches/patch-libs-external_USI++_usi++_tcp_h
===
RCS file: patches/patch-libs-external_USI++_usi++_tcp_h
diff -N patches/patch-libs-external_USI++_usi++_tcp_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-libs-external_USI++_usi++_tcp_h   14 Dec 2018 17:45:07 
-
@@ -0,0 +1,13 @@
+$OpenBSD$
+usi++/tcp.h:175:47: 'memset' was not declared in this scope with ports-gcc
+Index: libs-external/USI++/usi++/tcp.h
+--- libs-external/USI++/usi++/tcp.h.orig
 libs-external/USI++/usi++/tcp.h
+@@ -12,6 +12,7 @@
+ #ifndef _TCP_H_
+ #define _TCP_H_
+ 
++#include 
+ #include "usi-structs.h"
+ #include "datalink.h"
+ #include "ip.h"


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/productivity/devtodo.log

A single missing include. Build is fine [2], and so is runtime [3].
Doesn't break the amd64 build.

[2] http://ix.io/1w03
[3] https://bsd.network/web/statuses/101241080087100263

Index: Makefile
===
RCS file: /cvs/ports/productivity/devtodo/Makefile,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 Makefile
--- Makefile24 Oct 2018 14:28:10 -  1.28
+++ Makefile14 Dec 2018 19:39:36 -
@@ -3,7 +3,7 @@
 COMMENT=   reminder/task program aimed at developers
 
 DISTNAME=  devtodo-0.1.20
-REVISION = 4
+REVISION = 5
 CATEGORIES=productivity devel
 
 HOMEPAGE=  http://swapoff.org/devtodo1.html
Index: patches/patch-src_todoterm_cc
===
RCS file: patches/patch-src_todoterm_cc
diff -N patches/patch-src_todoterm_cc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_todoterm_cc   14 Dec 2018 19:39:36 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+fix for ports-gcc-4.9
+todoterm.cc:18:38: error: 'getenv' was not declared in this scope
+Index: src/todoterm.cc
+--- src/todoterm.cc.orig
 src/todoterm.cc
+@@ -7,6 +7,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ static char info[2048];
+ static bool term_initialized;


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/x11/xglobe%2Cno_map.log

Once again a missing include. I built the standard [4] and no_map [5]
flavors without issues. Runtime works as expected [6]. 

For some reason an old patch is present in the diff, to me it looks like
the diff(1) algo probably changed meanwhile and it's reflecting that? 

[4] http://ix.io/1w1A
[5] http://ix.io/1w1M
[6] https://bsd.network/@julianaito/101242469086735925


Index: Makefile
===
RCS file: /cvs/ports/x11/xglobe/Makefile,v
retrieving revision 1.77
diff -u -p -u -p -r1.77 Makefile
--- Makefile24 Oct 2018 14:28:14 -  1.77
+++ Makefile15 Dec 2018 00:25:47 -
@@ -9,7 +9,7 @@ HOMEPAGE=   http://www.shaderwrangler.com/
 MASTER_SITES=  https://distfiles.nl/
 DISTNAME=  xglobe-0.5p2
 PKGNAME=   xglobe-0.5
-REVISION=  43
+REVISION=  44
 
 MAINTAINER=Marc Espie 
 
Index: patches/patch-desktopwidget_cpp
===
RCS file: patches/patch-desktopwidget_cpp
diff -N patches/patch-desktopwidget_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ 

Re: powerpc bulk build report

[Landry Breuil]

On Thu, Dec 13, 2018 at 03:26:55AM +0100, Charlene Wendling wrote:
> 
> Sorry for the extra noise, but i managed to unbreak more of them. It 
> should do the job on other gcc4 arches as well. 
> 
> 
> > http://build-failures.rhaalovely.net//powerpc/2018-12-01/converters/lastools.log
> 
> 
> The log explains itself the issue, i added it, it builds [1] and
> runs fine. It doesn't break the build on amd64.

Fwiw i've put those 3 diffs in the macppc bulk that started now.

Re: powerpc bulk build report

[Charlene Wendling]

Sorry for the extra noise, but i managed to unbreak more of them. It 
should do the job on other gcc4 arches as well. 


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/converters/lastools.log


The log explains itself the issue, i added it, it builds [1] and
runs fine. It doesn't break the build on amd64.

[1] http://ix.io/1vTp


Index: Makefile
===
RCS file: /cvs/ports/converters/lastools/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile24 Oct 2018 14:27:59 -  1.7
+++ Makefile13 Dec 2018 00:07:07 -
@@ -5,7 +5,7 @@ DISTNAME =  lastools-0.20170108
 GH_ACCOUNT =   LAStools
 GH_PROJECT =   LAStools
 GH_TAGNAME =   f00fa125075ea984993057c5916d746cb605835c
-REVISION = 2
+REVISION = 3
 
 CATEGORIES =   converters textproc devel
 
@@ -14,10 +14,15 @@ PERMIT_PACKAGE_CDROM =  Yes
 
 WANTLIB += c m ${COMPILER_LIBCXX}
 
+#c++11
 COMPILER = base-clang ports-gcc base-gcc
 
 MAKE_FLAGS =   COMPILER="${CXX}" \
LINKER="${CXX}"
+# building with ports-gcc generates the following error: 
+# warning.h:32:2: error: #error This file requires compiler
+# and library support for the ISO C++ 2011 standard.
+CXXFLAGS +=-std=c++11
 
 post-patch:
find ${WRKSRC} -name Makefile | xargs sed -i 's/-O3/${CXXFLAGS}/'


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/games/late.log

It's just about missing includes, the build log is here [2], 
and it runs fine [3].

[2] http://ix.io/1vTr
[3] https://bsd.network/web/statuses/101230576378175694

Index: Makefile
===
RCS file: /cvs/ports/games/late/Makefile,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 Makefile
--- Makefile24 Oct 2018 14:28:03 -  1.20
+++ Makefile12 Dec 2018 23:39:44 -
@@ -2,7 +2,7 @@
 
 COMMENT=   puzzle game resembling the arcade game Qix
 DISTNAME=  late-0.1.0
-REVISION=  4
+REVISION=  5
 EXTRACT_SUFX=  .tar.bz2
 CATEGORIES=games x11
 MASTER_SITES=  ${MASTER_SITE_SOURCEFORGE:=late/}
Index: patches/patch-src_ball_h
===
RCS file: patches/patch-src_ball_h
diff -N patches/patch-src_ball_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_ball_h12 Dec 2018 23:39:44 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+ball.h:113:19: error: 'NULL' was not declared in this scope
+Index: src/ball.h
+--- src/ball.h.orig
 src/ball.h
+@@ -25,6 +25,7 @@
+ class ball;
+ 
+ #include "square.h"
++#include 
+ 
+ class ball_base
+ {
Index: patches/patch-src_init_cpp
===
RCS file: patches/patch-src_init_cpp
diff -N patches/patch-src_init_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_init_cpp  12 Dec 2018 23:39:44 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+init.cpp:139:34: error: 'strcmp' was not declared in this scope
+init.cpp:196:12: error: 'exit' was not declared in this scope
+Index: src/init.cpp
+--- src/init.cpp.orig
 src/init.cpp
+@@ -26,8 +26,9 @@
+ #include "scorescreen.h"
+ #include 
+ #include 
++#include 
++#include 
+ using namespace std; 
+-
+ 
+ int cheat   = 0;
+ int zappy;


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/devel/codeworker.log

There are dozens of missing includes errors here. Once they're fixed,
it builds properly [4]. I'm also attaching the diff because i'm not
sure of how DOS line endings in the source code will be dealt with.

The basic "get started" stuff from HOMEPAGE runs fine. That diff
doesn't break the build on amd64. 

[4] http://ix.io/1vTH


Index: Makefile
===
RCS file: /cvs/ports/devel/codeworker/Makefile,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile
--- Makefile28 Oct 2018 09:02:40 -  1.14
+++ Makefile13 Dec 2018 02:11:11 -
@@ -4,7 +4,7 @@ COMMENT =   universal parsing tool & sour
 
 V =4.5.4
 PKGNAME =  codeworker-${V}
-REVISION = 5
+REVISION = 6
 
 CATEGORIES =   devel
 
Index: patches/patch-CGRuntime_h
===
RCS file: patches/patch-CGRuntime_h
diff -N patches/patch-CGRuntime_h
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-CGRuntime_h   13 Dec 2018 02:11:11 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+Fix a lot of include errors with ports-gcc
+Index: CGRuntime.h
+--- CGRuntime.h.orig
 CGRuntime.h
+@@ -24,6 +24,8 @@ To contact the author: codewor...@free.fr
+ 
+ #include 
+ #include 
++#include 
++#include 
+ 
+ #include "UtlException.h"
+ #include "CppParsingTree.h"
Index: patches/patch-CppParsingTree_cpp
===
RCS file: patches/patch-CppParsingTree_cpp
diff -N 

Re: powerpc bulk build report

[Charlene Wendling]

On Wed, 12 Dec 2018 15:56:51 -0500
Brian Callahan wrote:

> > I think it would be better if you kept the same comment but
> > simplified the rest to:
> > COMPILER = base-clang ports-gcc
> >
> > Since that's effectively what you're asking for (and is more 
> > generalizable to all archs).
> >
> > ~Brian
> >
> 
> Oh, and if this is C code only,
> COMPILER_LANGS = c
> 

Yes, it's C only. There was a space that should be a tab, that i've
fixed by the way. Here it is. 

Charlène. 

Index: Makefile
===
RCS file: /cvs/ports/games/prboom-plus/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile4 Sep 2018 12:46:13 -   1.5
+++ Makefile12 Dec 2018 21:11:22 -
@@ -10,7 +10,12 @@ HOMEPAGE =   http://prboom-plus.sourceforg
 MAINTAINER =   Ryan Freeman 
 
 # GPLv2+
-PERMIT_PACKAGE_CDROM = Yes
+PERMIT_PACKAGE_CDROM = Yes
+
+# undefined reference to `__builtin_bswap32'
+# requires gcc >= 4.3 for gcc4 archs.
+COMPILER = base-clang ports-gcc
+COMPILER_LANGS =   c
 
 BUILD_DEPENDS =archivers/unzip
 

Re: powerpc bulk build report

[Brian Callahan]

On 12/12/18 3:55 PM, Brian Callahan wrote:



On 12/12/18 3:51 PM, Charlene Wendling wrote:

On Tue, 11 Dec 2018 16:29:13 -0700 (MST)
lan...@openbsd.org wrote:


http://build-failures.rhaalovely.net//powerpc/2018-12-01/games/prboom-plus.log 


Hi,

The diff says it all ;) As sparc64 has the same issue, it should fix the
build there as well. The build log is here [1].

Lightly tested [2], sadly (i have motion sickness when playing FPSes).

Charlène.

[1] http://ix.io/1vSK
[2] https://bsd.network/web/statuses/101230014606063596

Index: Makefile
===
RCS file: /cvs/ports/games/prboom-plus/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile    4 Sep 2018 12:46:13 -    1.5
+++ Makefile    12 Dec 2018 20:06:05 -
@@ -12,6 +12,12 @@ MAINTAINER =    Ryan Freeman = 4.3 for gcc4 archs.
+.if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "sparc64"
+COMPILER =    ports-gcc
+.endif
+
  BUILD_DEPENDS =    archivers/unzip
    WANTLIB += SDL c m pthread GL GLU SDL_mixer SDL_net



I think it would be better if you kept the same comment but simplified 
the rest to:

COMPILER = base-clang ports-gcc

Since that's effectively what you're asking for (and is more 
generalizable to all archs).


~Brian



Oh, and if this is C code only,
COMPILER_LANGS = c

Re: powerpc bulk build report

[Brian Callahan]

On 12/12/18 3:51 PM, Charlene Wendling wrote:

On Tue, 11 Dec 2018 16:29:13 -0700 (MST)
lan...@openbsd.org wrote:



http://build-failures.rhaalovely.net//powerpc/2018-12-01/games/prboom-plus.log

Hi,

The diff says it all ;) As sparc64 has the same issue, it should fix the
build there as well. The build log is here [1].

Lightly tested [2], sadly (i have motion sickness when playing FPSes).

Charlène.

[1] http://ix.io/1vSK
[2] https://bsd.network/web/statuses/101230014606063596

Index: Makefile
===
RCS file: /cvs/ports/games/prboom-plus/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile4 Sep 2018 12:46:13 -   1.5
+++ Makefile12 Dec 2018 20:06:05 -
@@ -12,6 +12,12 @@ MAINTAINER = Ryan Freeman   
+# undefined reference to `__builtin_bswap32'

+# requires gcc >= 4.3 for gcc4 archs.
+.if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "sparc64"
+COMPILER = ports-gcc
+.endif
+
  BUILD_DEPENDS =   archivers/unzip
  
  WANTLIB += SDL c m pthread GL GLU SDL_mixer SDL_net




I think it would be better if you kept the same comment but simplified 
the rest to:

COMPILER = base-clang ports-gcc

Since that's effectively what you're asking for (and is more 
generalizable to all archs).


~Brian

Re: powerpc bulk build report

[Charlene Wendling]

On Tue, 11 Dec 2018 16:29:13 -0700 (MST)
lan...@openbsd.org wrote:


> http://build-failures.rhaalovely.net//powerpc/2018-12-01/games/prboom-plus.log

Hi, 

The diff says it all ;) As sparc64 has the same issue, it should fix the
build there as well. The build log is here [1]. 

Lightly tested [2], sadly (i have motion sickness when playing FPSes). 

Charlène. 

[1] http://ix.io/1vSK
[2] https://bsd.network/web/statuses/101230014606063596

Index: Makefile
===
RCS file: /cvs/ports/games/prboom-plus/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile4 Sep 2018 12:46:13 -   1.5
+++ Makefile12 Dec 2018 20:06:05 -
@@ -12,6 +12,12 @@ MAINTAINER = Ryan Freeman = 4.3 for gcc4 archs.
+.if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "sparc64"
+COMPILER = ports-gcc
+.endif
+
 BUILD_DEPENDS =archivers/unzip
 
 WANTLIB += SDL c m pthread GL GLU SDL_mixer SDL_net

Re: powerpc bulk build report

[Landry Breuil]

On Thu, Nov 29, 2018 at 03:19:49PM -0700, lan...@openbsd.org wrote:
> bulk build on macppc-1.ports.openbsd.org
> started on  Tue Nov 20 01:17:37 MST 2018
> finished at Thu Nov 29 15:19:14 MST 2018
> lasted 10D07h01m
> done with kern.version=OpenBSD 6.4-current (GENERIC.MP) #282: Mon Nov 19 
> 20:42:01 MST 2018
> 
> built packages:7017
> Nov 20:748
> Nov 21:580
> Nov 22:675
> Nov 23:402
> Nov 24:463
> Nov 25:375
> Nov 26:527
> Nov 27:581
> Nov 28:388
> Nov 29:2277
> 
> 
> 
> critical path missing pkgs: 
> http://build-failures.rhaalovely.net//powerpc/2018-11-20/summary.log

Same thing as sparc64, this bulk was done with the gcc6 diff (and some
others..) - failure logs are available for anyone to poke - i'll revert
back to a "no diff" portstree for the upcoming bulks.

Landry

Re: powerpc bulk build report

[Charlene Wendling]

On Sun, 11 Nov 2018 18:13:05 +0100
Landry Breuil wrote:

> On Sun, Nov 11, 2018 at 04:53:49PM +0100, Charlene Wendling wrote:
> > On Tue, 30 Oct 2018 23:45:14 -0600 (MDT)
> > lan...@openbsd.org wrote:
> > 
> > > bulk build on macppc-1.ports.openbsd.org
> > > started on  Fri Oct 12 09:46:26 MDT 2018
> > > finished at Tue Oct 30 18:15:58 MDT 2018
> > > lasted 19D01h29m
> > > done with kern.version=OpenBSD 6.4 (GENERIC) #231: Thu Oct 11
> > > 17:55:03 MDT 2018
> > > 
> > 
> > >  failures/multimedia/swfmill.log
> > 
> > Hi ports! 
> > 
> > I'm proposing a diff that unbreaks swfmill on macppc here. The swf
> > files generated are valid (tested with swfdump from
> > multimedia/swftools). 
> 
> I dont really understand *why* this diff would change anything, since
> on macppc 'base-clang ports-gcc' should use gcc/g++ from ports, to my
> understanding base-gcc is just here for archs where lang/gcc doesnt
> build (if there are still some).
> 
> Have you checked which compiler is used with/without your diff ?
> 

You're right, i've looked at the failure log, but not how the vanilla
port builds *right now*, and it builds. Sorry for the noise.

Re: powerpc bulk build report

[Landry Breuil]

On Sun, Nov 11, 2018 at 04:53:49PM +0100, Charlene Wendling wrote:
> On Tue, 30 Oct 2018 23:45:14 -0600 (MDT)
> lan...@openbsd.org wrote:
> 
> > bulk build on macppc-1.ports.openbsd.org
> > started on  Fri Oct 12 09:46:26 MDT 2018
> > finished at Tue Oct 30 18:15:58 MDT 2018
> > lasted 19D01h29m
> > done with kern.version=OpenBSD 6.4 (GENERIC) #231: Thu Oct 11
> > 17:55:03 MDT 2018
> > 
> 
> >  failures/multimedia/swfmill.log
> 
> Hi ports! 
> 
> I'm proposing a diff that unbreaks swfmill on macppc here. The swf
> files generated are valid (tested with swfdump from
> multimedia/swftools). 

I dont really understand *why* this diff would change anything, since on
macppc 'base-clang ports-gcc' should use gcc/g++ from ports, to my
understanding base-gcc is just here for archs where lang/gcc doesnt
build (if there are still some).

Have you checked which compiler is used with/without your diff ?

Re: powerpc bulk build report

[Charlene Wendling]

On Tue, 30 Oct 2018 23:45:14 -0600 (MDT)
lan...@openbsd.org wrote:

> bulk build on macppc-1.ports.openbsd.org
> started on  Fri Oct 12 09:46:26 MDT 2018
> finished at Tue Oct 30 18:15:58 MDT 2018
> lasted 19D01h29m
> done with kern.version=OpenBSD 6.4 (GENERIC) #231: Thu Oct 11
> 17:55:03 MDT 2018
> 

>  failures/multimedia/swfmill.log

Hi ports! 

I'm proposing a diff that unbreaks swfmill on macppc here. The swf
files generated are valid (tested with swfdump from
multimedia/swftools). 

I've also moved HOMEPAGE to https. 

Charlène. 

Index: Makefile
===
RCS file: /cvs/ports/multimedia/swfmill/Makefile,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 Makefile
--- Makefile24 Oct 2018 14:28:08 -  1.12
+++ Makefile11 Nov 2018 15:41:39 -
@@ -5,9 +5,9 @@ COMMENT=xml2swf and swf2xml processor w
 DISTNAME=  swfmill-0.3.6
 CATEGORIES=multimedia
 MASTER_SITES=  ${HOMEPAGE}releases/
-REVISION=  0
+REVISION=  1
 
-HOMEPAGE=  http://swfmill.org/
+HOMEPAGE=  https://swfmill.org/
 
 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes
@@ -15,7 +15,8 @@ PERMIT_PACKAGE_CDROM= Yes
 WANTLIB += c exslt freetype gcrypt gpg-error iconv intl lzma m png
pthread WANTLIB += ${COMPILER_LIBCXX} xml2 xslt z
 
-COMPILER = base-clang ports-gcc base-gcc
+# C++11
+COMPILER=  base-clang ports-gcc
 
 LIB_DEPENDS=   graphics/png \
textproc/libxslt


swfmill.diff
Description: Binary data

Re: powerpc bulk build report

[Landry Breuil]

On Thu, Nov 01, 2018 at 12:10:19AM +, Stuart Henderson wrote:
> On 2018/10/31 15:00, George Koehler wrote:
> > mupdf's MD5 code is broken on all big-endian machines.
> > https://bugs.ghostscript.com/show_bug.cgi?id=699395
> > 
> > I added a small patch (not the one in the bug report) and mailed it to
> > maintainer Stuart Henderson on Monday.  I don't know if MD5 works, but
> > I can open a few PDF files.
> 
> I am looking into mupdf, I was already partway through updating to the newer
> version but ran into lld-related problems that need figuring out (there is
> the libssl-related thing you noticed too, actually that code is disabled
> completely at the moment as it doesn't pass the pkg-config version check,
> but if that's hacked away build fails due to libressl not having 
> PKCS12_SAFEBAG
> accessors yet).
> 
> > A copy of patch-thirdparty_lcms2_src_cmsmd5_c:
> > =begin
> > $OpenBSD$
> > 
> > Fix "error: 'ContextID' undeclared" on big-endian machines.
> > The argument will get ignored, so it can be NULL.
> > 
> > Index: thirdparty/lcms2/src/cmsmd5.c
> > --- thirdparty/lcms2/src/cmsmd5.c.orig
> > +++ thirdparty/lcms2/src/cmsmd5.c
> > @@ -33,7 +33,7 @@ void byteReverse(cmsUInt8Number * buf, cmsUInt32Number
> >  {
> >  do {
> >  
> > -cmsUInt32Number t = _cmsAdjustEndianess32(ContextID, 
> > *(cmsUInt32Number *) buf);
> > +cmsUInt32Number t = _cmsAdjustEndianess32(NULL, *(cmsUInt32Number 
> > *) buf);
> >  *(cmsUInt32Number *) buf = t;
> >  buf += sizeof(cmsUInt32Number);
> >  
> > =end

Fwid mupdf packaged fine in the current powerpc bulk with this diff.

Landry

Re: powerpc bulk build report

[Landry Breuil]

On Wed, Oct 31, 2018 at 03:00:51PM -0400, George Koehler wrote:
> On Tue, 30 Oct 2018 23:45:14 -0600 (MDT)
> lan...@openbsd.org wrote:
> 
> > bulk build on macppc-1.ports.openbsd.org
> > started on  Fri Oct 12 09:46:26 MDT 2018
> > finished at Tue Oct 30 18:15:58 MDT 2018
> 
> I recently built some packages on my OpenBSD/macppc machine,
> and fixed failures in devel/vte3, textproc/mupdf, multimedia/x265.
> 
> > http://build-failures.rhaalovely.net//powerpc/2018-10-12/devel/vte3.log
> 
> ports-gcc can't build devel/vte3; this blocks x11/xfce4/terminal and
> some other terminal emulators.  I added a patch to build it (and get a
> working xfce4-terminal).  I mailed the patch to maintainers Jasper
> Lievisse Adriaanse and Antoine Jacoutot on Monday 29 Oct 2018.
> 
> I don't know how to use cvs diff,
> but here's a copy of patch-src_app_app_cc:
> =begin
> $OpenBSD$
> 
> Prevent error from ports-gcc.
> 
> app.cc:309:39: error: cannot convert 'const GdkRGBA {aka const _GdkRGBA}
> to 'gdouble {aka double}' in initialization
> 
> Index: src/app/app.cc
> --- src/app/app.cc.orig
> +++ src/app/app.cc
> @@ -306,7 +306,7 @@ class Options { (public)
>  else
>  alpha = get_alpha();
>  
> -GdkRGBA color{bg_color};
> +GdkRGBA color(bg_color);
>  color.alpha = alpha;
>  return color;
>  }
> =end

Confirmed that this oneline fixes sparc64 too. jasper, care to commit it
? Can do otherwise.

Re: powerpc bulk build report

[Landry Breuil]

On Wed, Oct 31, 2018 at 03:00:51PM -0400, George Koehler wrote:
> On Tue, 30 Oct 2018 23:45:14 -0600 (MDT)
> lan...@openbsd.org wrote:
> 
> > bulk build on macppc-1.ports.openbsd.org
> > started on  Fri Oct 12 09:46:26 MDT 2018
> > finished at Tue Oct 30 18:15:58 MDT 2018
> 
> I recently built some packages on my OpenBSD/macppc machine,
> and fixed failures in devel/vte3, textproc/mupdf, multimedia/x265.

Thanks for the patches, i will locally apply them so hopefully those
ports will be fine in the next bulk, with results in about two or three
weeks. Will let the respective maintainers handle the patches
themselves, but your analysis reads fine to me. Thanks for giving some
care to powerpc !!

Landry

Re: powerpc bulk build report

[Stuart Henderson]

On 2018/10/31 15:00, George Koehler wrote:
> mupdf's MD5 code is broken on all big-endian machines.
> https://bugs.ghostscript.com/show_bug.cgi?id=699395
> 
> I added a small patch (not the one in the bug report) and mailed it to
> maintainer Stuart Henderson on Monday.  I don't know if MD5 works, but
> I can open a few PDF files.

I am looking into mupdf, I was already partway through updating to the newer
version but ran into lld-related problems that need figuring out (there is
the libssl-related thing you noticed too, actually that code is disabled
completely at the moment as it doesn't pass the pkg-config version check,
but if that's hacked away build fails due to libressl not having PKCS12_SAFEBAG
accessors yet).

> A copy of patch-thirdparty_lcms2_src_cmsmd5_c:
> =begin
> $OpenBSD$
> 
> Fix "error: 'ContextID' undeclared" on big-endian machines.
> The argument will get ignored, so it can be NULL.
> 
> Index: thirdparty/lcms2/src/cmsmd5.c
> --- thirdparty/lcms2/src/cmsmd5.c.orig
> +++ thirdparty/lcms2/src/cmsmd5.c
> @@ -33,7 +33,7 @@ void byteReverse(cmsUInt8Number * buf, cmsUInt32Number
>  {
>  do {
>  
> -cmsUInt32Number t = _cmsAdjustEndianess32(ContextID, 
> *(cmsUInt32Number *) buf);
> +cmsUInt32Number t = _cmsAdjustEndianess32(NULL, *(cmsUInt32Number *) 
> buf);
>  *(cmsUInt32Number *) buf = t;
>  buf += sizeof(cmsUInt32Number);
>  
> =end

Re: powerpc bulk build report

[George Koehler]

On Tue, 30 Oct 2018 23:45:14 -0600 (MDT)
lan...@openbsd.org wrote:

> bulk build on macppc-1.ports.openbsd.org
> started on  Fri Oct 12 09:46:26 MDT 2018
> finished at Tue Oct 30 18:15:58 MDT 2018

I recently built some packages on my OpenBSD/macppc machine,
and fixed failures in devel/vte3, textproc/mupdf, multimedia/x265.

> http://build-failures.rhaalovely.net//powerpc/2018-10-12/devel/vte3.log

ports-gcc can't build devel/vte3; this blocks x11/xfce4/terminal and
some other terminal emulators.  I added a patch to build it (and get a
working xfce4-terminal).  I mailed the patch to maintainers Jasper
Lievisse Adriaanse and Antoine Jacoutot on Monday 29 Oct 2018.

I don't know how to use cvs diff,
but here's a copy of patch-src_app_app_cc:
=begin
$OpenBSD$

Prevent error from ports-gcc.

app.cc:309:39: error: cannot convert 'const GdkRGBA {aka const _GdkRGBA}
to 'gdouble {aka double}' in initialization

Index: src/app/app.cc
--- src/app/app.cc.orig
+++ src/app/app.cc
@@ -306,7 +306,7 @@ class Options { (public)
 else
 alpha = get_alpha();
 
-GdkRGBA color{bg_color};
+GdkRGBA color(bg_color);
 color.alpha = alpha;
 return color;
 }
=end

> http://build-failures.rhaalovely.net//powerpc/2018-10-12/textproc/mupdf.log

mupdf's MD5 code is broken on all big-endian machines.
https://bugs.ghostscript.com/show_bug.cgi?id=699395

I added a small patch (not the one in the bug report) and mailed it to
maintainer Stuart Henderson on Monday.  I don't know if MD5 works, but
I can open a few PDF files.

A copy of patch-thirdparty_lcms2_src_cmsmd5_c:
=begin
$OpenBSD$

Fix "error: 'ContextID' undeclared" on big-endian machines.
The argument will get ignored, so it can be NULL.

Index: thirdparty/lcms2/src/cmsmd5.c
--- thirdparty/lcms2/src/cmsmd5.c.orig
+++ thirdparty/lcms2/src/cmsmd5.c
@@ -33,7 +33,7 @@ void byteReverse(cmsUInt8Number * buf, cmsUInt32Number
 {
 do {
 
-cmsUInt32Number t = _cmsAdjustEndianess32(ContextID, *(cmsUInt32Number 
*) buf);
+cmsUInt32Number t = _cmsAdjustEndianess32(NULL, *(cmsUInt32Number *) 
buf);
 *(cmsUInt32Number *) buf = t;
 buf += sizeof(cmsUInt32Number);
 
=end

> http://build-failures.rhaalovely.net//powerpc/2018-10-12/x11/xfce4/xfce4-whiskermenu.log

"error: expected primary-expression before '{' token"
I didn't fix this one.  The '{' begins an initializer list.  The error
is from base-gcc; this port might need C++11 and ports-gcc.

I got the error from xfce4-whiskermenu-2.3.0.  CVS now has 2.3.0p0,
which adds a line "COMPILER = base-clang ports-gcc base-gcc", so it
will use ports-gcc and might have a chance to build.  I have not tried
to build 2.3.0p0.  I wonder if base-gcc should not be in COMPILER?

I forgot to contact maintainer Landry Breuil.  I would have sent my
build log, but now I see that you already have one.


I have one more failure: multimedia/x265 version 2.9 is broken on all
non-x86 machines, https://bitbucket.org/multicoreware/x265/issues/442

That report has a patch; I mailed that patch (with my own comment) to
maintainer Brad Smith on Monday.  I can build x265 but don't know if
it can encode or decode video.

A copy of patch-source_common_cpu_cpp:
=begin
$OpenBSD$

Move the definition of x265::detect512() outside of #if X265_ARCH_X86
to prevent a linker error on non-x86 platforms:
.../libx265.so.16.0: undefined reference to `x265::detect512()'

Patch from Adam Sampson,
https://bitbucket.org/multicoreware/x265/issues/442

Index: source/common/cpu.cpp
--- source/common/cpu.cpp.orig
+++ source/common/cpu.cpp
@@ -110,6 +110,11 @@ const cpu_name_t cpu_names[] =
 { "", 0 },
 };
 
+bool detect512()
+{
+return(enable512);
+}
+
 #if X265_ARCH_X86
 
 extern "C" {
@@ -123,10 +128,6 @@ uint64_t PFX(cpu_xgetbv)(int xcr);
 #pragma warning(disable: 4309) // truncation of constant value
 #endif
 
-bool detect512()
-{
-return(enable512);
-}
 uint32_t cpu_detect(bool benableavx512 )
 {
 
=end

-- 
George Koehler 

Re: powerpc bulk build report

[Landry Breuil]

On Fri, Oct 12, 2018 at 10:28:55AM +0200, Sascha Paunovic wrote:
> On 12.10.2018 10:19, Landry Breuil wrote:
> > On Fri, Oct 12, 2018 at 11:16:18AM +0300, Kirill Bychkov wrote:
> > > On Fri, October 12, 2018 09:26, lan...@openbsd.org wrote:
> > > > bulk build on macppc-1.ports.openbsd.org
> > > > started on  Tue Jul 31 12:02:13 MDT 2018
> > > > finished at Thu Oct 11 16:19:16 MDT 2018
> > > > lasted 13D21h17m
> > > > done with kern.version=OpenBSD 6.4-beta (GENERIC.MP) #193: Tue Sep 18 
> > > > 14:07:13
> > > > MDT 2018
> > > > 
> > > > built packages:8773
> > > > Sep 19:1
> > > > Sep 20:931
> > > > Sep 21:786
> > > > Sep 22:564
> > > > Sep 23:415
> > > > Sep 24:597
> > > > Sep 25:617
> > > > Sep 26:614
> > > > Sep 27:1178
> > > > Sep 28:1655
> > > > Sep 30:113
> > > > Oct 1:242
> > > > Oct 2:196
> > > > Oct 3:249
> > > > Oct 4:54
> > > > Oct 5:127
> > > > Oct 6:107
> > > > Oct 7:112
> > > > Oct 8:90
> > > > Oct 9:124
> > > > Oct 10:101
> > > > Oct 11:25
> > > > 
> > > > 
> > > > build failures: 55
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/audio/gimmix.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/benchmarks/wrk.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/cad/gtkwave.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/cad/yosys.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/databases/sqlports,-compact.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/avr/gcc.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/catch2.log
> > > > http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/geany.log
> > > 
> > > Hi!
> > > Your tree seems to be outdated. devel/geany was fixed recently:
> > > revision 1.59
> > > date: 2018/10/01 20:45:07;  author: sthen;  state: Exp;  lines: +3 -1;
> > 
> > Well given that the bulk started mid-september..
> > 
> 
> "started on  Tue Jul 31 12:02:13 MDT 2018"
> 
> Looks like end of July for me.

Well, given that *i* started it, i think i know when it was :)

Previous bulks this summer had had errors, and the reporting script took
the previous startup date..

Re: powerpc bulk build report

[Sascha Paunovic]

On 12.10.2018 10:19, Landry Breuil wrote:

On Fri, Oct 12, 2018 at 11:16:18AM +0300, Kirill Bychkov wrote:

On Fri, October 12, 2018 09:26, lan...@openbsd.org wrote:

bulk build on macppc-1.ports.openbsd.org
started on  Tue Jul 31 12:02:13 MDT 2018
finished at Thu Oct 11 16:19:16 MDT 2018
lasted 13D21h17m
done with kern.version=OpenBSD 6.4-beta (GENERIC.MP) #193: Tue Sep 18 14:07:13
MDT 2018

built packages:8773
Sep 19:1
Sep 20:931
Sep 21:786
Sep 22:564
Sep 23:415
Sep 24:597
Sep 25:617
Sep 26:614
Sep 27:1178
Sep 28:1655
Sep 30:113
Oct 1:242
Oct 2:196
Oct 3:249
Oct 4:54
Oct 5:127
Oct 6:107
Oct 7:112
Oct 8:90
Oct 9:124
Oct 10:101
Oct 11:25


build failures: 55
http://build-failures.rhaalovely.net//powerpc/2018-07-31/audio/gimmix.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/benchmarks/wrk.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/cad/gtkwave.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/cad/yosys.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/databases/sqlports,-compact.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/avr/gcc.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/catch2.log
http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/geany.log


Hi!
Your tree seems to be outdated. devel/geany was fixed recently:
revision 1.59
date: 2018/10/01 20:45:07;  author: sthen;  state: Exp;  lines: +3 -1;


Well given that the bulk started mid-september..



"started on  Tue Jul 31 12:02:13 MDT 2018"

Looks like end of July for me.

Re: powerpc bulk build report

[Landry Breuil]

On Fri, Oct 12, 2018 at 11:16:18AM +0300, Kirill Bychkov wrote:
> On Fri, October 12, 2018 09:26, lan...@openbsd.org wrote:
> > bulk build on macppc-1.ports.openbsd.org
> > started on  Tue Jul 31 12:02:13 MDT 2018
> > finished at Thu Oct 11 16:19:16 MDT 2018
> > lasted 13D21h17m
> > done with kern.version=OpenBSD 6.4-beta (GENERIC.MP) #193: Tue Sep 18 
> > 14:07:13
> > MDT 2018
> >
> > built packages:8773
> > Sep 19:1
> > Sep 20:931
> > Sep 21:786
> > Sep 22:564
> > Sep 23:415
> > Sep 24:597
> > Sep 25:617
> > Sep 26:614
> > Sep 27:1178
> > Sep 28:1655
> > Sep 30:113
> > Oct 1:242
> > Oct 2:196
> > Oct 3:249
> > Oct 4:54
> > Oct 5:127
> > Oct 6:107
> > Oct 7:112
> > Oct 8:90
> > Oct 9:124
> > Oct 10:101
> > Oct 11:25
> >
> >
> > build failures: 55
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/audio/gimmix.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/benchmarks/wrk.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/cad/gtkwave.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/cad/yosys.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/databases/sqlports,-compact.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/avr/gcc.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/catch2.log
> > http://build-failures.rhaalovely.net//powerpc/2018-07-31/devel/geany.log
> 
> Hi!
> Your tree seems to be outdated. devel/geany was fixed recently:
> revision 1.59
> date: 2018/10/01 20:45:07;  author: sthen;  state: Exp;  lines: +3 -1; 

Well given that the bulk started mid-september..

Re: powerpc bulk build report

[Landry Breuil]

On Thu, May 17, 2018 at 06:34:51PM +0300, Kirill Bychkov wrote:
> On Sat, May 12, 2018 17:21, lan...@openbsd.org wrote:
> > bulk build on macppc-1.ports.openbsd.org
> > started on  Tue Apr 17 11:23:22 MDT 2018
> > finished at Sat May 12 06:46:31 MDT 2018
> 
> Hi!
> The patch below fixes build of simgear on powerpc (and probably other
> !clang arches)
> OK?

Fwiw, if you have trivial fixes like this, just commit them, don't
hope/wait for okays :)