Re: sparc64 bulk build report
summary of a few of these, until I got bored ;) > http://build-failures.rhaalovely.net/sparc64/2024-07-18/devel/arm-none-eabi/gcc,aarch64.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/print/texlive/texmf.log xz "compressed data is corrupt" > http://build-failures.rhaalovely.net/sparc64/2024-07-18/devel/boost.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/print/texlive/base.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/math/libqalculate.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/textproc/xerces-c.log looks like icu4c > http://build-failures.rhaalovely.net/sparc64/2024-07-18/graphics/rawstudio.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/games/fheroes2.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/mail/grommunio/index.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/emulators/snes9x.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/graphics/tesseract/tesseract.log undefined reference to `std::filesystem::__cxx11::[...] > http://build-failures.rhaalovely.net/sparc64/2024-07-18/lang/bacon.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/inputmethods/ibus.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/games/widelands.log bus error > http://build-failures.rhaalovely.net/sparc64/2024-07-18/devel/avr/gcc.log segfault > http://build-failures.rhaalovely.net/sparc64/2024-07-18/archivers/blosc2.log #error Cannot determine how to allocate aligned memory on the target platform. > http://build-failures.rhaalovely.net/sparc64/2024-07-18/astro/wmglobe.log /usr/local/lib/libwraster.so.6.0: undefined reference to `libintl_bindtextdomain' > http://build-failures.rhaalovely.net/sparc64/2024-07-18/www/hiawatha.log multiple definition of `mbedtls_[...] > http://build-failures.rhaalovely.net/sparc64/2024-07-18/audio/libcanberra.log Missing library for estdc++>=19.0 > http://build-failures.rhaalovely.net/sparc64/2024-07-18/sysutils/libvirt.log /usr/bin/ld: attempted static link of dynamic object `/usr/local/lib/libglib-2.0.so.4201.12' > http://build-failures.rhaalovely.net/sparc64/2024-07-18/math/gunits.log relocation truncated to fit: R_SPARC_GOT13 against symbol `[...]' defined in .data section > http://build-failures.rhaalovely.net/sparc64/2024-07-18/games/nblood.log needs ucontext on sparc64 > http://build-failures.rhaalovely.net/sparc64/2024-07-18/wayland/gtk-layer-shell.log > http://build-failures.rhaalovely.net/sparc64/2024-07-18/wayland/gtk4-layer-shell.log cc1: error: unrecognized command line option "-std=gnu11" cc1: error: unrecognized command line option "-Wno-pedantic" > http://build-failures.rhaalovely.net/sparc64/2024-07-18/wayland/wlroots.log Check usable header "vulkan/vulkan.h" with dependency vulkan: NO > http://build-failures.rhaalovely.net/sparc64/2024-07-18/math/openfst.log .libs/libfst.so.2.0: undefined reference to `pthread_rwlock_rdlock'
Re: sparc64 bulk build report
On Sat Jul 20, 2024 at 08:03:32PM GMT, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Thu Jul 18 21:06:41 MDT 2024
> Finished: Sat Jul 20 20:02:40 MDT 2024
> Duration: 1 Days 22 hours 56 minutes
>
> Built using OpenBSD 7.5-current (GENERIC.MP) #2208: Thu Jul 18 10:53:29 MDT
> 2024
>
> Built 8805 packages
>
> Number of packages built each day:
> Jul 18: 3829
> Jul 19: 3640
> Jul 20: 1336
>
>
>
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/sparc64/2024-07-18/summary.log
>
> Build failures: 74
> http://build-failures.rhaalovely.net/sparc64/2024-07-18/x11/qt6/qtbase.log
Could you try this diff?
diff --git a/x11/qt6/qtbase/Makefile b/x11/qt6/qtbase/Makefile
index b16aa8c7afe..eeef6c2affc 100644
--- a/x11/qt6/qtbase/Makefile
+++ b/x11/qt6/qtbase/Makefile
@@ -131,10 +131,15 @@ CONFIGURE_ARGS += -DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DFEATURE_openssl_linked=ON \
-DFEATURE_system_sqlite=ON \
-DFEATURE_system_xcb_xinput=ON \
- -DFEATURE_no_direct_extern_access=ON \
-DFEATURE_libproxy=ON \
-DFEATURE_dtls=OFF
+.if ${MACHINE_ARCH} == "sparc64"
+CONFIGURE_ARGS += -DFEATURE_no_direct_extern_access=OFF
+.else
+CONFIGURE_ARGS += -DFEATURE_no_direct_extern_access=ON
+.endif
+
# TODO
#CONFIGURE_ARGS += -DQT_BUILD_TESTS=ON
Re: sparc64 bulk build report
On 2024/07/13 03:32, k...@openbsd.org wrote: > http://build-failures.rhaalovely.net/sparc64/2024-07-11/devel/boost.log packaging fails due to boost.locale not being built; looks like icu fallout - icu : no [2] - Boost.Locale needs either iconv or ICU library to be built. - iconv (libc) : no [6] - iconv (separate) : no [6] - icu : no [6] - Boost.Locale needs either iconv or ICU library to be built.
Re: sparc64 bulk build report
On 2024/06/30 05:47, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Thu Jun 27 14:15:05 MDT 2024
> Finished: Sun Jun 30 05:46:14 MDT 2024
> Duration: 2 Days 15 hours 31 minutes
>
> Built using OpenBSD 7.5-current (GENERIC.MP) #2182: Thu Jun 27 00:39:17 MDT
> 2024
>
> Built 9061 packages
>
> Number of packages built each day:
> Jun 27: 6061
> Jun 28: 1567
> Jun 29: 1427
> Jun 30: 6
>
>
>
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/summary.log
>
Looking at the most impactful failures...
563 x11/qt6/qtbase
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/x11/qt6/qtbase.log
CMake Error at cmake/QtBuildInformation.cmake:523 (message):
Feature "no_direct_extern_access": Forcing to "ON" breaks its condition:
NOT WIN32 AND TEST_no_direct_extern_access
223 mail/alpine,-c-client
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/mail/alpine,-c-client.log
tar: Invalid header, starting valid header search.
xz: (stdin): Compressed data is corrupt
53 x11/gnome/gjs
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/x11/gnome/gjs.log
libestdc++ / libc++ conflict in GjsTestTools-1.0 binary run during build
52 www/webkitgtk4,webkitgtk41
11 www/webkitgtk4,webkitgtk60
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/www/webkitgtk4,webkitgtk41.log
"GCC 10.2 or newer is required to build WebKit. Use a newer GCC version or
Clang."
20 sysutils/libvirt
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/sysutils/libvirt.log
/usr/bin/ld: attempted static link of dynamic object
`/usr/local/lib/libglib-2.0.so.4201.12'
16 audio/libcanberra
11 audio/libcanberra,-gtk3
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/audio/libcanberra.log
"Missing library for estdc++>=19.0" when packaging; probably needs
${LIB_DEPENDS} adding to LIB_DEPENDS-gtk3
11 x11/qt5/qtwebkit
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/x11/qt5/qtwebkit.log
/usr/obj/ports/qtwebkit-5.212.0alpha4/qtwebkit-5.212.0-alpha4/Source/WebCore/platform/audio/gstreamer/AudioFileReaderGStreamer.cpp:
In member function 'void
WebCore::AudioFileReader::handleNewDeinterleavePad(GstPad*)':
/usr/obj/ports/qtwebkit-5.212.0alpha4/qtwebkit-5.212.0-alpha4/Source/WebCore/platform/audio/gstreamer/AudioFileReaderGStreamer.cpp:235:5:
error: braces around scalar initializer for type 'gboolean (*)(GstAppSink*,
GstQuery*, gpointer)' {aka 'int (*)(_GstAppSink*, _GstQuery*, void*)'}
};
^
8 devel/libwnck3
> http://build-failures.rhaalovely.net/sparc64/2024-06-27/devel/libwnck3.log
- dep change, no changes in cvs since updating to 43.0, so it looks like
it must have been done as a test build on sparc64*.p with COMPILER set
sometime? probably wants cleaning on build machine.
Re: sparc64 bulk build report
On Mon, 22 Apr 2024 21:07:16 -0600 (MDT) k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org I don't run sparc64. This arch doesn't use base-clang and falls back to ports-gcc in "COMPILER = base-clang ports-gcc", but our lang/gcc/8 is missing features from C++20. I used https://en.cppreference.com/ to identify C++20 features. These ports failed because of C++20, > http://build-failures.rhaalovely.net/sparc64/2024-04-20/audio/ncmpc.log No such file... #include > http://build-failures.rhaalovely.net/sparc64/2024-04-20/devel/mtxclient.log No such file... #include > http://build-failures.rhaalovely.net/sparc64/2024-04-20/devel/rgbds.log > http://build-failures.rhaalovely.net/sparc64/2024-04-20/games/openttd.log No such file... #include The recent update to games/openttd 14.0 newly requires C++20. > http://build-failures.rhaalovely.net/sparc64/2024-04-20/emulators/openmsx.log > http://build-failures.rhaalovely.net/sparc64/2024-04-20/games/scid.log eg++: error: unrecognized command line option '-std=c++20'; \ did you mean '-std=c++2a'? > http://build-failures.rhaalovely.net/sparc64/2024-04-20/games/bugdom.log > http://build-failures.rhaalovely.net/sparc64/2024-04-20/games/bugdom2.log > http://build-failures.rhaalovely.net/sparc64/2024-04-20/games/cromagrally.log > http://build-failures.rhaalovely.net/sparc64/2024-04-20/games/ottomatic.log 'u8string' in namespace 'std' does not name a type... std::u8string > http://build-failures.rhaalovely.net/sparc64/2024-04-20/mail/rspamd,hyperscan.log 'std::__cxx11::string'... has no member named 'ends_with'
Re: sparc64 bulk build report
Folks Sorry for not picking this up sooner I will fix nsh by the end of January ... sorry for the delay in getting back to you on this Tom Smyth On Wed, 20 Dec 2023 at 09:30, wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Sun Dec 17 01:48:55 MST 2023 > Finished: Wed Dec 20 02:23:35 MST 2023 > Duration: 3 Days 0 hours 35 minutes > > Built using OpenBSD 7.4-current (GENERIC.MP) #1963: Fri Dec 15 16:52:31 > MST 2023 > > Built 8470 packages > > Number of packages built each day: > Dec 17: 7222 > Dec 18: 1235 > Dec 19: 4 > Dec 20: 9 > > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2023-12-17/summary.log > > Build failures: 41 > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/audio/libsmackerdec.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/audio/ncmpc.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/audio/xmms2.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/databases/ruby-amalgalite,ruby31.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/arm-none-eabi/gdb.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/avr/gcc.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/jdk/1.8.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/mtxclient.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/py-debugpy,python3.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/py-thrift,python3.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/vim-command-t.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/xsd.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/devel/yder.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/emulators/libretro-pcsx-rearmed.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/cataclysm-dda,no_x11.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/choria.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/emptyclip.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/ezquake.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/fheroes2.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/gnukem.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/scid.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/games/widelands.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/graphics/spirv-tools.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/graphics/tesseract/tesseract.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/lang/rust.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/mail/rspamd,hyperscan.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/math/flintlib.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/math/gunits.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/math/openfst.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/net/iperf3.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/shells/nsh.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/borgmatic.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/flashrom.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/libvirt.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/pftop.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/sysutils/u-boot-asahi.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/textproc/libmarisa,,-main.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/textproc/rapidjson.log > > http://build-failures.rhaalovely.net/sparc64/2023-12-17/textproc/redland-bindings,-main.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/wayland/wlroots.log > http://build-failures.rhaalovely.net/sparc64/2023-12-17/x11/polybar.log > > -- Kindest regards, Tom Smyth.
[Re: sparc64 bulk build report] - devel/llvm failed
> http://build-failures.rhaalovely.net/sparc64/2023-09-28/archivers/snappy.log (DIST_TUPLE issue in this and a couple of other ports, should now be fixed) > http://build-failures.rhaalovely.net/sparc64/2023-09-28/devel/llvm/13.log Error: /usr/obj/ports/llvm-13.0.0/fake-sparc64/usr/local/llvm13/lib/clang/13.0.0/include/unwind.h does not exist pkg_create: can't continue Ideally this could do with fixing for release .. > http://build-failures.rhaalovely.net/sparc64/2023-09-28/devel/llvm/16,-lldb.log /usr/bin/ld: unrecognized option '-Bsymbolic-functions'
Re: sparc64 bulk build report
On Sat, Jun 03, 2023 at 09:55:03AM -0600, k...@openbsd.org wrote: [...] > http://build-failures.rhaalovely.net/sparc64/2023-05-31/devel/sdl2-ttf.log This is looking for C++11 features, so should be fixed with this commit: https://marc.info/?l=openbsd-ports-cvs=168582158701697=2
Re: sparc64 bulk build report
Looks like something slipped through with the ocaml-menhir update. On 4/9/23 09:13, k...@openbsd.org wrote: http://build-failures.rhaalovely.net/sparc64/2023-04-04/devel/ocaml-menhir.logIndex: pkg/PFRAG.native === RCS file: /cvs/ports/devel/ocaml-menhir/pkg/PFRAG.native,v retrieving revision 1.5 diff -u -p -r1.5 PFRAG.native --- pkg/PFRAG.native 4 Apr 2023 10:28:14 - 1.5 +++ pkg/PFRAG.native 9 Apr 2023 08:24:45 - @@ -1,6 +1,8 @@ %%dynlink%% +lib/ocaml/menhirLib/menhirLib.a lib/ocaml/menhirLib/menhirLib.cmx lib/ocaml/menhirLib/menhirLib.cmxa +lib/ocaml/menhirSdk/menhirSdk.a lib/ocaml/menhirSdk/menhirSdk.cmx lib/ocaml/menhirSdk/menhirSdk.cmxa lib/ocaml/menhirSdk/menhirSdk__Cmly_api.cmx Index: pkg/PLIST === RCS file: /cvs/ports/devel/ocaml-menhir/pkg/PLIST,v retrieving revision 1.14 diff -u -p -r1.14 PLIST --- pkg/PLIST 4 Apr 2023 10:28:14 - 1.14 +++ pkg/PLIST 9 Apr 2023 08:24:45 - @@ -9,7 +9,6 @@ lib/ocaml/menhir/dune-package lib/ocaml/menhirLib/ lib/ocaml/menhirLib/META lib/ocaml/menhirLib/dune-package -lib/ocaml/menhirLib/menhirLib.a lib/ocaml/menhirLib/menhirLib.cma lib/ocaml/menhirLib/menhirLib.cmi lib/ocaml/menhirLib/menhirLib.cmt @@ -25,7 +24,6 @@ lib/ocaml/menhirSdk/cmly_read.mli lib/ocaml/menhirSdk/dune-package lib/ocaml/menhirSdk/keyword.ml lib/ocaml/menhirSdk/keyword.mli -lib/ocaml/menhirSdk/menhirSdk.a lib/ocaml/menhirSdk/menhirSdk.cma lib/ocaml/menhirSdk/menhirSdk.cmi lib/ocaml/menhirSdk/menhirSdk.cmt
unbreak net/weechat (Re: sparc64 bulk build report)
On Mon, Mar 20, 2023 at 08:50:01AM -0600, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2023-03-18/net/weechat,-lua.log
weechat has no FLAVORS, so unless I'm missing something, this failed
MULTI_PACKAGES was just the first to be built and it means all weechat
packages are unavailable on sparc64, no?
> /usr/obj/ports/weechat-3.8/weechat-3.8/tests/unit/core/test-core-utf8.cpp:492:
> error: \u007f is not a valid universal character
These are the errors, there are more warnings, but they are all in tests.
Disabling tests packages fine, without PLIST or WANTLIB change on sparc64.
I can 'pkg_add weechat' and start it on sparc64 with this, but otherwise
don't use it; should it make release?
diff --git a/net/weechat/Makefile b/net/weechat/Makefile
index 1d9fc36ee1c..a43fa1deac5 100644
--- a/net/weechat/Makefile
+++ b/net/weechat/Makefile
@@ -85,6 +87,10 @@ MODCMAKE_LDFLAGS = -L${LOCALBASE}/lib
CONFIGURE_ENV= CFLAGS="${CFLAGS} -fdeclspec"
.endif
+.if ${MACHINE_ARCH} == sparc64
+CONFIGURE_ARGS+= -DENABLE_TESTS=OFF
+.endif
+
pre-configure:
rm -f ${WRKSRC}/cmake/{FindLua,FindRuby,FindTCL}.cmake
Re: sparc64 bulk build report
On Fri, Mar 17, 2023 at 02:23:02PM +0100, Theo Buehler wrote: > > > http://build-failures.rhaalovely.net/sparc64/2023-03-13/lang/guile2.log > > no idea why it hanged :/ > I think these guild compile steps just take forever to complete, so it > hits the time limit. I started a build 90 minutes ago on a machine that > is about as fast as the machines in kmos's cluster and it is now ten > minutes into building psyntax-pp.scm The timeout is 8 hours. I know the steps take a long time, but yikes. --Kurt
Re: sparc64 bulk build report
On Fri, Mar 17, 2023 at 10:34:54AM +0100, Omar Polo wrote: > > http://build-failures.rhaalovely.net/sparc64/2023-03-13/games/love/11.log > > love-11 doesn't seem to support big-endians (yet?). > ok? ok for both broken markers. > > http://build-failures.rhaalovely.net/sparc64/2023-03-13/lang/guile2.log > > no idea why it hanged :/ I think these guild compile steps just take forever to complete, so it hits the time limit. I started a build 90 minutes ago on a machine that is about as fast as the machines in kmos's cluster and it is now ten minutes into building psyntax-pp.scm > > http://build-failures.rhaalovely.net/sparc64/2023-03-13/lang/guile3.log > > : GUILE_BOOTSTRAP_STAGE=stage0 ../meta/build-env guild compile > --target="sparc64-unknown-openbsd7.3" -W0 -O1 -L > "/usr/obj/ports/guile3-3.0.9/guile-3.0.9/module" -o "system/vm/frame.go" > "../module/system/vm/frame.scm" > : Abort trap (core dumped) > > maybe the same issue powerpc has, bad prebuilt stage0 ? fwiw: Continuing the build after this gave me a working guile3.
Re: sparc64 bulk build report
> http://build-failures.rhaalovely.net/sparc64/2023-03-13/games/love/11.log
love-11 doesn't seem to support big-endians (yet?).
ok?
Index: Makefile
===
RCS file: /home/cvs/ports/games/love/11/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile27 Feb 2023 10:53:43 - 1.1.1.1
+++ Makefile17 Mar 2023 09:28:07 -
@@ -1,3 +1,7 @@
+# ./modules/data/HashFunction.cpp:25:3: error:
+# Hashing not yet implemented for big endian
+NOT_FOR_ARCHS =${BE_ARCHS}
+
VERSION = 11.4
SHARED_LIBS = love-${VERSION} 0.0
> http://build-failures.rhaalovely.net/sparc64/2023-03-13/lang/guile2.log
no idea why it hanged :/
> http://build-failures.rhaalovely.net/sparc64/2023-03-13/lang/guile3.log
: GUILE_BOOTSTRAP_STAGE=stage0 ../meta/build-env guild compile
--target="sparc64-unknown-openbsd7.3" -W0 -O1 -L
"/usr/obj/ports/guile3-3.0.9/guile-3.0.9/module" -o "system/vm/frame.go"
"../module/system/vm/frame.scm"
: Abort trap (core dumped)
maybe the same issue powerpc has, bad prebuilt stage0 ?
Index: Makefile
===
RCS file: /home/cvs/ports/lang/guile3/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile26 Feb 2023 18:06:35 - 1.5
+++ Makefile17 Mar 2023 09:33:15 -
@@ -1,5 +1,6 @@
# https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26854#11
BROKEN-powerpc = stage0 abort trap, bad prebuilt/32-bit-big-endian
+BROKEN-sparc64 = stage0 abort trap, bad prebuilt/64-bit-big-endian ?
DPB_PROPERTIES = parallel
Re: sparc64 bulk build report
On Thu, Jan 12 2023, "Kirill Bychkov" wrote: > On Fri, January 6, 2023 07:19, k...@openbsd.org wrote: >> Bulk build on sparc64-0a.ports.openbsd.org >> >> Started : Mon Jan 2 03:05:44 MST 2023 >> Finished: Thu Jan 5 21:19:11 MST 2023 >> Duration: 3 Days 18 hours 13 minutes >> >> Built using OpenBSD 7.2-current (GENERIC.MP) #1578: Sat Dec 31 14:17:49 MST >> 2022 >> > >> http://build-failures.rhaalovely.net/sparc64/2023-01-02/games/cataclysm-dda,no_x11.log > > Hi, > cc1plus: warning: unrecognized command line option > '-Wno-unknown-warning-option' > This option is supported by clang, not gcc. > Should we switch to ports-clang or just drop this option from Makefile? The warning is funny. Maybe we should support for it to base-gcc. More seriously, the log doesn't show an error and I managed to build/package cataclysm-dda successfully on sparc64. So I don't know what happened for this port to be flagged as an error and I don't know either why it's not listed on http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/sparc64/ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE signature.asc Description: PGP signature
Re: sparc64 bulk build report
On Fri, January 6, 2023 07:19, k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Mon Jan 2 03:05:44 MST 2023 > Finished: Thu Jan 5 21:19:11 MST 2023 > Duration: 3 Days 18 hours 13 minutes > > Built using OpenBSD 7.2-current (GENERIC.MP) #1578: Sat Dec 31 14:17:49 MST > 2022 > > http://build-failures.rhaalovely.net/sparc64/2023-01-02/games/cataclysm-dda,no_x11.log Hi, cc1plus: warning: unrecognized command line option '-Wno-unknown-warning-option' This option is supported by clang, not gcc. Should we switch to ports-clang or just drop this option from Makefile?
Re: sparc64 bulk build report
On Fri, Aug 19, 2022 at 01:32:53AM +0200, Jeremie Courreges-Anglas wrote:
> Here's a diff for samba. It would be possible to just ditch __thread in
> the embedded heimdal source code since base-gcc doesn't support TLS
> emulation. But samba is moving fast and I suspect that other parts
> will start requiring features not supported by base-gcc.
> Does this fix the build on sparc64? ok?
It fixes sparc64. ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/samba/Makefile,v
> retrieving revision 1.316
> diff -u -p -r1.316 Makefile
> --- Makefile 29 Jul 2022 10:43:01 - 1.316
> +++ Makefile 18 Aug 2022 23:20:17 -
> @@ -61,6 +61,9 @@ MASTER_SITES = https://download.samba.o
> MULTI_PACKAGES = -main -docs
> DEBUG_PACKAGES = ${BUILD_PACKAGES}
>
> +COMPILER = base-clang ports-gcc
> +COMPILER_LANGS = c
> +
> MODULES =lang/python perl
>
> BUILD_DEPENDS = converters/p5-JSON \
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
Re: sparc64 bulk build report
On Wed, Aug 17 2022, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Sun Aug 14 16:33:59 MDT 2022
> Finished: Wed Aug 17 22:13:39 MDT 2022
> Duration: 3 Days 5 hours 40 minutes
>
> Built using OpenBSD 7.2-beta (GENERIC.MP) #1422: Sun Aug 14 12:54:32 MDT 2022
>
> Built 9336 packages
>
> Number of packages built each day:
> Aug 14: 4669
> Aug 15: 3493
> Aug 16: 1104
> Aug 17: 70
>
>
>
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/sparc64/2022-08-14/summary.log
>
> Build failures: 46
> http://build-failures.rhaalovely.net/sparc64/2022-08-14/net/samba.log
>
> Recurrent failures:
> failures/net/samba.log
Here's a diff for samba. It would be possible to just ditch __thread in
the embedded heimdal source code since base-gcc doesn't support TLS
emulation. But samba is moving fast and I suspect that other parts
will start requiring features not supported by base-gcc.
Does this fix the build on sparc64? ok?
Index: Makefile
===
RCS file: /cvs/ports/net/samba/Makefile,v
retrieving revision 1.316
diff -u -p -r1.316 Makefile
--- Makefile29 Jul 2022 10:43:01 - 1.316
+++ Makefile18 Aug 2022 23:20:17 -
@@ -61,6 +61,9 @@ MASTER_SITES =https://download.samba.o
MULTI_PACKAGES = -main -docs
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+COMPILER = base-clang ports-gcc
+COMPILER_LANGS = c
+
MODULES = lang/python perl
BUILD_DEPENDS =converters/p5-JSON \
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sparc64 bulk build report
Am 15.08.22 um 17:12 schrieb Stuart Henderson:
> On 2022/08/15 11:06, Kurt Mosiejczuk wrote:
>> On Fri, Aug 12, 2022 at 10:21:18AM +0100, Stuart Henderson wrote:
>>> I think that wants "COMPILER_LANGS= c" as well
>>
>> Nope. It uses C++ as well. ok kmos for Martin's version. It fixed the build
>> for sparc64
>
> hmm, you're right... surprised at the lack of C++ libraries in WANTLIB then
It's only a handful of tests that are c++, maybe that's why.
>> --Kurt
>>
>>> On 12 August 2022 08:03:28 Martin Reindl wrote:
>>>
On Thu, Aug 11, 2022 at 11:55:46PM -0600, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> http://build-failures.rhaalovely.net/sparc64/2022-08-09/math/arpack.log
Can anyone test please?
Index: Makefile
===
RCS file: /cvs/ports/math/arpack/Makefile,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile
--- Makefile 24 May 2022 19:28:58 - 1.24
+++ Makefile 12 Aug 2022 06:51:28 -
@@ -7,7 +7,7 @@ PKGNAME = arpack-${GH_TAGNAME}
GH_ACCOUNT = opencollab
GH_PROJECT = arpack-ng
EPOCH =0
-REVISION =0
+REVISION =1
MULTI_PACKAGES = -main -mpi
FLAVORS = no_mpi
@@ -22,6 +22,8 @@ HOMEPAGE = https://github.com/opencollab
# BSD 3-Clause
PERMIT_PACKAGE = Yes
+
+COMPILER =base-clang ports-gcc
MODULES = fortran \
devel/cmake
>>>
Re: sparc64 bulk build report
On 2022/08/15 11:06, Kurt Mosiejczuk wrote:
> On Fri, Aug 12, 2022 at 10:21:18AM +0100, Stuart Henderson wrote:
> > I think that wants "COMPILER_LANGS= c" as well
>
> Nope. It uses C++ as well. ok kmos for Martin's version. It fixed the build
> for sparc64
hmm, you're right... surprised at the lack of C++ libraries in WANTLIB then
> --Kurt
>
> > On 12 August 2022 08:03:28 Martin Reindl wrote:
> >
> > > On Thu, Aug 11, 2022 at 11:55:46PM -0600, k...@openbsd.org wrote:
> > > > Bulk build on sparc64-0a.ports.openbsd.org
> > > >
> > > > http://build-failures.rhaalovely.net/sparc64/2022-08-09/math/arpack.log
> > >
> > > Can anyone test please?
> > >
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/math/arpack/Makefile,v
> > > retrieving revision 1.24
> > > diff -u -p -u -p -r1.24 Makefile
> > > --- Makefile 24 May 2022 19:28:58 - 1.24
> > > +++ Makefile 12 Aug 2022 06:51:28 -
> > > @@ -7,7 +7,7 @@ PKGNAME = arpack-${GH_TAGNAME}
> > > GH_ACCOUNT = opencollab
> > > GH_PROJECT = arpack-ng
> > > EPOCH = 0
> > > -REVISION = 0
> > > +REVISION = 1
> > >
> > > MULTI_PACKAGES = -main -mpi
> > > FLAVORS = no_mpi
> > > @@ -22,6 +22,8 @@ HOMEPAGE = https://github.com/opencollab
> > >
> > > # BSD 3-Clause
> > > PERMIT_PACKAGE = Yes
> > > +
> > > +COMPILER = base-clang ports-gcc
> > >
> > > MODULES = fortran \
> > > devel/cmake
> >
Re: sparc64 bulk build report
On Fri, Aug 12, 2022 at 10:21:18AM +0100, Stuart Henderson wrote:
> I think that wants "COMPILER_LANGS= c" as well
Nope. It uses C++ as well. ok kmos for Martin's version. It fixed the build
for sparc64
--Kurt
> On 12 August 2022 08:03:28 Martin Reindl wrote:
>
> > On Thu, Aug 11, 2022 at 11:55:46PM -0600, k...@openbsd.org wrote:
> > > Bulk build on sparc64-0a.ports.openbsd.org
> > >
> > > http://build-failures.rhaalovely.net/sparc64/2022-08-09/math/arpack.log
> >
> > Can anyone test please?
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/math/arpack/Makefile,v
> > retrieving revision 1.24
> > diff -u -p -u -p -r1.24 Makefile
> > --- Makefile24 May 2022 19:28:58 - 1.24
> > +++ Makefile12 Aug 2022 06:51:28 -
> > @@ -7,7 +7,7 @@ PKGNAME = arpack-${GH_TAGNAME}
> > GH_ACCOUNT =opencollab
> > GH_PROJECT =arpack-ng
> > EPOCH = 0
> > -REVISION = 0
> > +REVISION = 1
> >
> > MULTI_PACKAGES =-main -mpi
> > FLAVORS = no_mpi
> > @@ -22,6 +22,8 @@ HOMEPAGE =https://github.com/opencollab
> >
> > # BSD 3-Clause
> > PERMIT_PACKAGE =Yes
> > +
> > +COMPILER = base-clang ports-gcc
> >
> > MODULES = fortran \
> > devel/cmake
>
Re: sparc64 bulk build report
On 2022/08/12 11:45, Martin REINDL wrote: > Am 12.08.2022 um 11:21 schrieb Stuart Henderson: > > I think that wants "COMPILER_LANGS= c" as well > > > > Even though it is mostly egfortran? The COMPILER mechanism only deals with c/c++; the default is "c c++" and in that case you will get library dependencies on C++ libraries added on ports-gcc archs MODGCC4_LANGS is a separate thing and that still includes fortran, check by setting COMPILER=ports-gcc, with and without using COMPILER_LANGS, and e.g. "make show=MODGCC4_LANGS" and "make show=WANTLIB".
Re: sparc64 bulk build report
Am 12.08.2022 um 11:21 schrieb Stuart Henderson: I think that wants "COMPILER_LANGS= c" as well Even though it is mostly egfortran?
Re: sparc64 bulk build report
I think that wants "COMPILER_LANGS= c" as well
--
Sent from a phone, apologies for poor formatting.
On 12 August 2022 08:03:28 Martin Reindl wrote:
On Thu, Aug 11, 2022 at 11:55:46PM -0600, k...@openbsd.org wrote:
Bulk build on sparc64-0a.ports.openbsd.org
http://build-failures.rhaalovely.net/sparc64/2022-08-09/math/arpack.log
Can anyone test please?
Index: Makefile
===
RCS file: /cvs/ports/math/arpack/Makefile,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile
--- Makefile24 May 2022 19:28:58 - 1.24
+++ Makefile12 Aug 2022 06:51:28 -
@@ -7,7 +7,7 @@ PKGNAME = arpack-${GH_TAGNAME}
GH_ACCOUNT =opencollab
GH_PROJECT =arpack-ng
EPOCH = 0
-REVISION = 0
+REVISION = 1
MULTI_PACKAGES =-main -mpi
FLAVORS = no_mpi
@@ -22,6 +22,8 @@ HOMEPAGE =https://github.com/opencollab
# BSD 3-Clause
PERMIT_PACKAGE =Yes
+
+COMPILER = base-clang ports-gcc
MODULES = fortran \
devel/cmake
Re: sparc64 bulk build report
On Thu, Aug 11, 2022 at 11:55:46PM -0600, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> http://build-failures.rhaalovely.net/sparc64/2022-08-09/math/arpack.log
Can anyone test please?
Index: Makefile
===
RCS file: /cvs/ports/math/arpack/Makefile,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 Makefile
--- Makefile24 May 2022 19:28:58 - 1.24
+++ Makefile12 Aug 2022 06:51:28 -
@@ -7,7 +7,7 @@ PKGNAME = arpack-${GH_TAGNAME}
GH_ACCOUNT = opencollab
GH_PROJECT = arpack-ng
EPOCH =0
-REVISION = 0
+REVISION = 1
MULTI_PACKAGES = -main -mpi
FLAVORS = no_mpi
@@ -22,6 +22,8 @@ HOMEPAGE =https://github.com/opencollab
# BSD 3-Clause
PERMIT_PACKAGE = Yes
+
+COMPILER = base-clang ports-gcc
MODULES = fortran \
devel/cmake
Re: sparc64 bulk build report
On Thu Aug 11, 2022 at 11:55:46PM -0600, k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Tue Aug 9 08:45:07 MDT 2022 > Finished: Thu Aug 11 23:55:09 MDT 2022 > Duration: 2 Days 15 hours 10 minutes > > Built using OpenBSD 7.2-beta (GENERIC.MP) #1412: Mon Aug 8 22:27:49 MDT 2022 > > Built 9348 packages > > Number of packages built each day: > Aug 9: 7369 > Aug 10: 1336 > Aug 11: 643 > > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2022-08-09/summary.log > > Build failures: 46 > http://build-failures.rhaalovely.net/sparc64/2022-08-09/devel/qcoro.log Index: Makefile === RCS file: /cvs/ports/devel/qcoro/Makefile,v retrieving revision 1.3 diff -u -p -u -p -r1.3 Makefile --- Makefile14 Jul 2022 08:09:07 - 1.3 +++ Makefile12 Aug 2022 06:14:14 - @@ -3,6 +3,7 @@ COMMENT = C++ coroutines for Qt GH_ACCOUNT = danvratil GH_PROJECT = qcoro GH_TAGNAME = v0.6.0 +REVISION = 0 CATEGORIES = devel @@ -12,6 +13,9 @@ MAINTAINER = Rafael Sadowski
Re: sparc64 bulk build report
On Jul 25, 2022, at 12:40 AM, k...@openbsd.org wrote: > Build failures: 38 > http://build-failures.rhaalovely.net/sparc64/2022-07-22/devel/jdk/1.8.log I’ve noticed an intermittent jdk crash on my sparc64 build machine too. I’ve investigated it at length but have not determined the cause yet. Please let me know if if this build failure is persistent. Thanks, -Kurt
Re: sparc64 bulk build report
On Tue, Jul 26, 2022 at 10:32:15PM +0200, Rafael Sadowski wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt6/qtdeclarative.log
> https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
> OpenSUSE confirmed that with following patch they can build Qt on SPARC:
> https://github.com/bmwiedemann/openSUSE/blob/934d586b71984cbf31d8ecb30dc8ac7f90369929/packages/q/qt6-shadertools/0001-Fix-encoding-decoding-of-string-literals-for-big-end.patch
> OK?
ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/qt6/qtshadertools/Makefile,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 Makefile
> --- Makefile 12 May 2022 09:40:33 - 1.4
> +++ Makefile 26 Jul 2022 20:27:24 -
> @@ -1,6 +1,7 @@
> QT6NAME =QtShaderTools
>
> COMMENT =Qt6 shader tools module
> +REVISION = 0
>
> PKGSPEC =qt6-qtshadertools-${QT6_PKGSPEC}
>
> Index: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
> ===
> RCS file: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
> diff -N patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp 26 Jul 2022
> 20:27:24 -
> @@ -0,0 +1,39 @@
> +Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
> +words with little-endian convention. Explicitly perform that encoding
> +instead of assuming that the host system is little-endian.
> +
> +Note that this change requires corresponding fixes in SPIRV-Tools.
> +
> +Fixes #202
> +https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
> +Index: src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
> +--- src/3rdparty/glslang/SPIRV/SPVRemapper.cpp.orig
> src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
> +@@ -297,15 +297,21 @@ namespace spv {
> + std::string spirvbin_t::literalString(unsigned word) const
> + {
> + std::string literal;
> ++const spirword_t * pos = spv.data() + word;
> +
> + literal.reserve(16);
> +
> +-const char* bytes = reinterpret_cast(spv.data() +
> word);
> +-
> +-while (bytes && *bytes)
> +-literal += *bytes++;
> +-
> +-return literal;
> ++do {
> ++spirword_t word = *pos;
> ++for (int i = 0; i < 4; i++) {
> ++char c = word & 0xff;
> ++if (c == '\0')
> ++return literal;
> ++literal += c;
> ++word >>= 8;
> ++}
> ++pos++;
> ++} while (true);
> + }
> +
> + void spirvbin_t::applyMap()
> Index: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
> ===
> RCS file: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
> diff -N patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp 26 Jul 2022
> 20:27:24 -
> @@ -0,0 +1,104 @@
> +Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
> +words with little-endian convention. Explicitly perform that encoding
> +instead of assuming that the host system is little-endian.
> +
> +Note that this change requires corresponding fixes in SPIRV-Tools.
> +
> +Fixes #202
> +https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
> +Index: src/3rdparty/glslang/SPIRV/disassemble.cpp
> +--- src/3rdparty/glslang/SPIRV/disassemble.cpp.orig
> src/3rdparty/glslang/SPIRV/disassemble.cpp
> +@@ -43,6 +43,7 @@
> + #include
> + #include
> + #include
> ++#include
> +
> + #include "disassemble.h"
> + #include "doc.h"
> +@@ -100,6 +101,7 @@ class SpirvStream { (protected)
> + void outputMask(OperandClass operandClass, unsigned mask);
> + void disassembleImmediates(int numOperands);
> + void disassembleIds(int numOperands);
> ++std::pair decodeString();
> + int disassembleString();
> + void disassembleInstruction(Id resultId, Id typeId, Op opCode, int
> numOperands);
> +
> +@@ -290,31 +292,44 @@ void SpirvStream::disassembleIds(int numOperands)
> + }
> + }
> +
> +-// return the number of operands consumed by the string
> +-int SpirvStream::disassembleString()
> ++// decode string from words at current position (non-consuming)
> ++std::pair SpirvStream::decodeString()
> + {
> +-int startWord = word;
> +-
> +-out << " \"";
> +-
> +-const char* wordString;
> ++std::string res;
> ++int wordPos = word;
> ++char c;
> + bool done = false;
> ++
> + do {
> +-unsigned int content = stream[word];
> +-wordString = (const char*)
> ++unsigned int content = stream[wordPos];
> + for (int charCount = 0; charCount < 4;
Re: sparc64 bulk build report
On Tue, Jul 26, 2022 at 10:39:09PM +0200, Rafael Sadowski wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt5/qttranslations.log > "Project ERROR: failed to parse default search paths from compiler output" > Bulk build issue? I don't know. Lots of ports that use qmake are failing with that error. Off the top of my head textproc/xxdiff is another example. --Kurt
Re: sparc64 bulk build report
On Sun Jul 24, 2022 at 10:40:00PM -0600, k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Fri Jul 22 09:17:32 MDT 2022 > Finished: Sun Jul 24 22:39:26 MDT 2022 > Duration: 2 Days 13 hours 22 minutes > > Built using OpenBSD 7.2-beta (GENERIC.MP) #1386: Thu Jul 21 08:50:25 MDT 2022 > > Built 9315 packages > > Number of packages built each day: > Jul 22: 7026 > Jul 23: 1482 > Jul 24: 807 > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2022-07-22/summary.log > > Build failures: 38 > http://build-failures.rhaalovely.net/sparc64/2022-07-22/devel/kf5/kio.log kio use std::transform_reduce which is not supported by our libestdc++ lib?! > http://build-failures.rhaalovely.net/sparc64/2022-07-22/devel/qcoro.log "eg++: error: unrecognized command line option '-fcoroutines'; did you mean '-fc-prototypes'?" No coroutines support in your old ports g++ > http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt5/qttranslations.log "Project ERROR: failed to parse default search paths from compiler output" Bulk build issue?
Re: sparc64 bulk build report
On Sun Jul 24, 2022 at 10:40:00PM -0600, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Fri Jul 22 09:17:32 MDT 2022
> Finished: Sun Jul 24 22:39:26 MDT 2022
> Duration: 2 Days 13 hours 22 minutes
>
> Built using OpenBSD 7.2-beta (GENERIC.MP) #1386: Thu Jul 21 08:50:25 MDT 2022
>
> Built 9315 packages
>
> Number of packages built each day:
> Jul 22: 7026
> Jul 23: 1482
> Jul 24: 807
>
>
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/sparc64/2022-07-22/summary.log
>
> Build failures: 38
> http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt6/qtdeclarative.log
>
https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
OpenSUSE confirmed that with following patch they can build Qt on SPARC:
https://github.com/bmwiedemann/openSUSE/blob/934d586b71984cbf31d8ecb30dc8ac7f90369929/packages/q/qt6-shadertools/0001-Fix-encoding-decoding-of-string-literals-for-big-end.patch
OK?
Index: Makefile
===
RCS file: /cvs/ports/x11/qt6/qtshadertools/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- Makefile12 May 2022 09:40:33 - 1.4
+++ Makefile26 Jul 2022 20:27:24 -
@@ -1,6 +1,7 @@
QT6NAME = QtShaderTools
COMMENT = Qt6 shader tools module
+REVISION = 0
PKGSPEC = qt6-qtshadertools-${QT6_PKGSPEC}
Index: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
===
RCS file: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
diff -N patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp26 Jul 2022
20:27:24 -
@@ -0,0 +1,39 @@
+Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
+words with little-endian convention. Explicitly perform that encoding
+instead of assuming that the host system is little-endian.
+
+Note that this change requires corresponding fixes in SPIRV-Tools.
+
+Fixes #202
+https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
+Index: src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
+--- src/3rdparty/glslang/SPIRV/SPVRemapper.cpp.orig
src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
+@@ -297,15 +297,21 @@ namespace spv {
+ std::string spirvbin_t::literalString(unsigned word) const
+ {
+ std::string literal;
++const spirword_t * pos = spv.data() + word;
+
+ literal.reserve(16);
+
+-const char* bytes = reinterpret_cast(spv.data() + word);
+-
+-while (bytes && *bytes)
+-literal += *bytes++;
+-
+-return literal;
++do {
++spirword_t word = *pos;
++for (int i = 0; i < 4; i++) {
++char c = word & 0xff;
++if (c == '\0')
++return literal;
++literal += c;
++word >>= 8;
++}
++pos++;
++} while (true);
+ }
+
+ void spirvbin_t::applyMap()
Index: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
===
RCS file: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
diff -N patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp26 Jul 2022
20:27:24 -
@@ -0,0 +1,104 @@
+Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
+words with little-endian convention. Explicitly perform that encoding
+instead of assuming that the host system is little-endian.
+
+Note that this change requires corresponding fixes in SPIRV-Tools.
+
+Fixes #202
+https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
+Index: src/3rdparty/glslang/SPIRV/disassemble.cpp
+--- src/3rdparty/glslang/SPIRV/disassemble.cpp.orig
src/3rdparty/glslang/SPIRV/disassemble.cpp
+@@ -43,6 +43,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #include "disassemble.h"
+ #include "doc.h"
+@@ -100,6 +101,7 @@ class SpirvStream { (protected)
+ void outputMask(OperandClass operandClass, unsigned mask);
+ void disassembleImmediates(int numOperands);
+ void disassembleIds(int numOperands);
++std::pair decodeString();
+ int disassembleString();
+ void disassembleInstruction(Id resultId, Id typeId, Op opCode, int
numOperands);
+
+@@ -290,31 +292,44 @@ void SpirvStream::disassembleIds(int numOperands)
+ }
+ }
+
+-// return the number of operands consumed by the string
+-int SpirvStream::disassembleString()
++// decode string from words at current position (non-consuming)
++std::pair SpirvStream::decodeString()
+ {
+-int startWord = word;
+-
+-out << " \"";
+-
+-const char* wordString;
++std::string res;
++int wordPos = word;
++
www/w3m on sparc64 (Re: sparc64 bulk build report)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Sun May 15 00:05:48 MDT 2022 > Finished: Tue May 17 11:30:21 MDT 2022 > Duration: 2 Days 11 hours 25 minutes > http://build-failures.rhaalovely.net/sparc64/2022-05-15/www/w3m.log the error is cc1: error: unrecognized command line option "-Wnull-dereference" it looks coming from gcc4, the base compiler for sparc64 I suppose. (see below) gcc provides "-Wnull-dereference" option since gcc6, so, how about adding COMPILER? COMPILER = base-clang ports-gcc [from http://build-failures.rhaalovely.net/sparc64/2022-05-15/www/w3m.log] >>> Building on sparc64-2b under www/w3m BDEPENDS = [archivers/xz;devel/boehm-gc;devel/gettext,-tools;devel/gettext,-runtime] DIST = [www/w3m:w3m_0.5.3+git20220429.orig.tar.xz] FULLPKGNAME = w3m-0.5.3pl20220429 RDEPENDS = [devel/gettext,-runtime;devel/boehm-gc] ===> Extracting for w3m-0.5.3pl20220429 ===> Patching for w3m-0.5.3pl20220429 ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Building for w3m-0.5.3pl20220429 cc -Wall -Wnull-dereference -I. -I. -O2 -pipe -I./libwc -I/usr/local/include -DHAVE_CONFIG_H -DAUXBIN_DIR=\"/usr/local/libexec/w3m\" -DCGIBIN_DIR=\"/usr/local/libexec/w3m/cgi-bin\" -DHELP_DIR=\"/usr/local/share/w3m\" -DETC_DIR=\"/etc\" -DCONF_DIR=\"/etc/w3m\" -DRC_DIR=\"~/.w3m\" -DLOCALEDIR=\"/usr/local/share/locale\" -I/usr/local/include -c main.c cc1: error: unrecognized command line option "-Wnull-dereference" *** Error 1 in /usr/obj/ports/w3m-0.5.3pl20220429/w3m-0.5.3+git20220429 (:87 'main.o') -- yozo. -BEGIN PGP SIGNATURE- iQHJBAEBCAAzFiEEXaBuNN3EAffFuoZQoSJsq/akOnEFAmKJ4/EVHHlvem9AdjAw Ny52YWlvLm5lLmpwAAoJEKEibKv2pDpxaHEL/2YwqB/32cGSLnYEtAdFEg5M2Vx9 5vz+/vlQq1YjArcFryJr8vPfC9bBJ6rzzrw5QdolJiVEEYbpmbrL4Vps8l1Zhosx 5f3mMRbZn9mWdKE049KQkyIT0WrwArF8KoxHxNX/iUCHjus6HZYOdnyM3rjsbNnM 9/sEcxolSNSr6N0CKLS34vciGJsxWr1w3lsVuGP1+9zYEvQTwmp9qG6o0J/3d5Ld iOnWpFplPm2fWSWdUDKsNvY8duEfxtWhGyjfUWIgG59SNEAwROcoLcx5of/BILaZ YNzyeBGfVnw4brQR9g9cNlAnjudRdrlhu+/eweLbsMUaVZ82ZKs6iLLYmpef0cfm 9o9dZK3ch1LPCKLL2oEggj8GloG7sbJWR/V/gMhd43r4SxX9xP9MAW4qyowk4bBd UEPfok3VOAWEAt6Rp2tIjnWLAc3CwCYYwebAcRvth2Kjnjv+aZS7izn6IkiHc1Jj oivFYBq7ZrV5/4y9Yf1COMe49LDMUBHSHG1UqA== =KRIl -END PGP SIGNATURE-
Re: sparc64 bulk build report
k...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-05-03/games/godot,-main.log
/usr/bin/ld:platform/x11/pck_embed.legacy.ld:10: syntax error
This is due the recent changes in the port to build the engine alone.
On GCC arches platform/x11/detect.py finds that we're using GNU ld and
tries to use a ld script to create an export template. We're not really
interested in those (*) and upstream says they don't work with llvm, so
I've just disable them. While here, bump revision for the -tools too
just to be sure.
I indend to commit this in a bit if someone don't object it.
(*): the export templates are used to "bundle" together the engine and
the game data/scripts in a single executable. they don't fit openbsd
well IMHO (plus I don't like the idea of people redistributing old godot
binaries) and for ports anyway we can just install the pck file and
launch it from a wrapper script.
Index: Makefile
===
RCS file: /home/cvs/ports/games/godot/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- Makefile28 Apr 2022 22:18:01 - 1.35
+++ Makefile6 May 2022 07:23:12 -
@@ -7,7 +7,8 @@ V = 3.4.4
GODOTSTEAM_V = g34-s152-gs311
DISTNAME = godot-${V}-stable
PKGNAME = godot-${V}
-REVISION-main =1
+REVISION-main =2
+REVISION-tools = 0
CATEGORIES = games
Index: patches/patch-platform_x11_detect_py
===
RCS file: /home/cvs/ports/games/godot/patches/patch-platform_x11_detect_py,v
retrieving revision 1.9
diff -u -p -r1.9 patch-platform_x11_detect_py
--- patches/patch-platform_x11_detect_py15 Apr 2022 20:23:19 -
1.9
+++ patches/patch-platform_x11_detect_py6 May 2022 07:17:18 -
@@ -1,5 +1,7 @@
-remove hardcoded -O2, found by bcallah@. Add sndio
-enable joydev
+- remove hardcoded -O2, found by bcallah@
+- add sndio
+- enable joydev
+- disable pck embedding (requires GNU ld and and is broken on GCC-arches)
Index: platform/x11/detect.py
--- platform/x11/detect.py.orig
@@ -45,13 +47,25 @@ Index: platform/x11/detect.py
if env["pulseaudio"]:
if os.system("pkg-config --exists libpulse") == 0: # 0 means found
env.Append(CPPDEFINES=["PULSEAUDIO_ENABLED"])
-@@ -347,6 +328,9 @@ def configure(env):
- print("Warning: libudev development libraries not found.
Disabling controller hotplugging support.")
+@@ -348,6 +329,9 @@ def configure(env):
else:
env["udev"] = False # Linux specific
-+
+
+if platform.system() == "OpenBSD":
+env.Append(CPPDEFINES=["JOYDEV_ENABLED"])
-
++
# Linkflags below this line should typically stay the last ones
if not env["builtin_zlib"]:
+ env.ParseConfig("pkg-config zlib --cflags --libs")
+@@ -375,11 +359,6 @@ def configure(env):
+ print(
+ "Warning: Creating template binaries enabled for PCK
embedding is currently only supported with GNU ld, not gold or LLD."
+ )
+-else:
+-if float(gnu_ld_version.group(1)) >= 2.30:
+-env.Append(LINKFLAGS=["-T", "platform/x11/pck_embed.ld"])
+-else:
+-env.Append(LINKFLAGS=["-T",
"platform/x11/pck_embed.legacy.ld"])
+
+ ## Cross-compilation
+
Re: sparc64 bulk build report (pmacct: AC_CHECK_LIB vs. COMPILER_LIBCXX version specs)
On Tue, Feb 22, 2022 at 03:01:45AM -0500, Brad Smith wrote: > My eyes are bleeding looking at this. It's using the wrong variable to try to > discover something and then adding more hacks on top. Hehe :) > Update libcdada to 0.3.5 and disable the examples. > For pmacct link with the C++ compiler driver. Much better, both configure and build fine on sparc64. No PLIST changes, either. I'll commit that, thanks Brad.
Re: sparc64 bulk build report (pmacct: AC_CHECK_LIB vs. COMPILER_LIBCXX version specs)
Ok sthen@
--
Sent from a phone, apologies for poor formatting.
On 22 February 2022 08:02:08 Brad Smith wrote:
On Tue, Feb 22, 2022 at 12:11:19AM +, Klemens Nanni wrote:
On Tue, Feb 22, 2022 at 12:02:08AM +, Klemens Nanni wrote:
> On Mon, Feb 21, 2022 at 11:27:37PM +, Stuart Henderson wrote:
> > On 2022/02/21 22:12, Klemens Nanni wrote:
> > > On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> > > >
http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/pmacct,postgresql.log
> > >
> > > > checking for cdada_get_ver in -lcdada... no
> > > > configure: error: Could not find libcdada
> > >
> > > The dependency is correctly handled, but AC_CHECK_LIB chokes on how
> > > ports-clang arches handle c++ libs.
> > >
> > > COMPILER_LIBCXX has "stdc++" and "estdc++>=17" for base-clang and
> > > ports-gcc, respectively.
> > >
> > > This ends up in configure.ac's libcdada AC_CHECK_LIB check as can be
> > > seen in the hackish diff below.
> > >
> > > ${WRKBUILD}/config.log shows the actual error:
> > >
> > > > configure:20504: checking for cdada_get_ver in -lcdada
> > > > configure:20529: cc -o conftest -O2 -pipe -I/usr/local/include
-L/usr/local/lib conftest.c -lcdada -lcdada -lestdc++>=17 -lpthread -lpcap
-lm -lpthread >&5
> > > > /usr/bin/ld: cannot find -lestdc++>=17
> > > > collect2: error: ld returned 1 exit status
> > >
> > > Removing the version spec makes configure work thus fixes the build,
> > > but this hackish attempt doesn't look like a solution.
> > >
> > > Leaving this here for others to chime in.
> >
> > it _ought_ to use $(CXX) to try and link rather than $(CC), but I don't
> > know if that's viable with this autoconf check.
>
> Good point, I missed that.
>
> >
> > > .for i in ${COMPILER_LIBCXX}
> > > -CXXLIB+= -l$i
> > > +CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
> > > .endfor
> >
> > I am okay with this with a comment to explain the regex, e.g.
> >
> > # strip off the library-specs(5) version number check
> >
> > the libcdada port itself should have the same change
> >
>
> Like that? Thanks, I'll go with in a few days unless we come up with
> something better.
Better this, also with correct manual section.
My eyes are bleeding looking at this. It's using the wrong variable to try to
discover something and then adding more hacks on top.
Update libcdada to 0.3.5 and disable the examples.
For pmacct link with the C++ compiler driver.
Index: devel/libcdada/Makefile
===
RCS file: /home/cvs/ports/devel/libcdada/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- devel/libcdada/Makefile 2 Nov 2021 00:00:24 - 1.4
+++ devel/libcdada/Makefile 22 Feb 2022 06:57:21 -
@@ -4,8 +4,7 @@ COMMENT=basic data structures in C (lib
GH_ACCOUNT= msune
GH_PROJECT= libcdada
-GH_TAGNAME=v0.3.4
-REVISION= 1
+GH_TAGNAME=v0.3.5
SHARED_LIBS += cdada 0.0 # 0.0
@@ -27,13 +26,8 @@ AUTORECONF= ${WRKSRC}/autogen.sh
AUTOCONF_VERSION= 2.69
AUTOMAKE_VERSION= 1.16
-CONFIGURE_ARGS=--disable-valgrind
+CONFIGURE_ARGS=--disable-valgrind \
+ --without-examples
SEPARATE_BUILD= Yes
-post-patch:
- sed -i 's,-lstdc++,${CXXLIB},' ${WRKSRC}/examples/Makefile.am
-
.include
-.for i in ${COMPILER_LIBCXX}
-CXXLIB+= -l$i
-.endfor
Index: devel/libcdada/distinfo
===
RCS file: /home/cvs/ports/devel/libcdada/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- devel/libcdada/distinfo 18 Feb 2021 13:23:22 - 1.1.1.1
+++ devel/libcdada/distinfo 22 Feb 2022 06:57:28 -
@@ -1,2 +1,2 @@
-SHA256 (libcdada-0.3.4.tar.gz) = yqIpwT/zjVeSpMmeHrefjM4TeCzk9xz3q/rE93abbos=
-SIZE (libcdada-0.3.4.tar.gz) = 1772957
+SHA256 (libcdada-0.3.5.tar.gz) = hkF/mtWvnZYdHiF4nuBNRgnsmhF3rg2EsItg72UJqjA=
+SIZE (libcdada-0.3.5.tar.gz) = 1776937
Index: net/pmacct/Makefile
===
RCS file: /home/cvs/ports/net/pmacct/Makefile,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 Makefile
--- net/pmacct/Makefile 18 Feb 2021 13:24:04 - 1.34
+++ net/pmacct/Makefile 22 Feb 2022 02:21:46 -
@@ -3,6 +3,7 @@
COMMENT=passive IP network monitoring tools: traffic accounting, etc
DISTNAME= pmacct-1.7.6
+REVISION= 0
CATEGORIES= net
HOMEPAGE= http://www.pmacct.net/
@@ -30,8 +31,7 @@ AUTOCONF_VERSION= 2.69
AUTOMAKE_VERSION= 1.16
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib" \
- CXXLIB="${CXXLIB}"
+ LDFLAGS="-L${LOCALBASE}/lib"
CONFIGURE_ARGS= --enable-geoipv2 \
--enable-jansson \
--enable-sqlite3 \
@@ -75,6 +75,3 @@ post-install:
.endif
.include
-.for i in ${COMPILER_LIBCXX}
-CXXLIB+= -l$i
Re: sparc64 bulk build report (pmacct: AC_CHECK_LIB vs. COMPILER_LIBCXX version specs)
On Tue, Feb 22, 2022 at 12:02:08AM +, Klemens Nanni wrote:
> On Mon, Feb 21, 2022 at 11:27:37PM +, Stuart Henderson wrote:
> > On 2022/02/21 22:12, Klemens Nanni wrote:
> > > On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> > > > http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/pmacct,postgresql.log
> > >
> > > > checking for cdada_get_ver in -lcdada... no
> > > > configure: error: Could not find libcdada
> > >
> > > The dependency is correctly handled, but AC_CHECK_LIB chokes on how
> > > ports-clang arches handle c++ libs.
> > >
> > > COMPILER_LIBCXX has "stdc++" and "estdc++>=17" for base-clang and
> > > ports-gcc, respectively.
> > >
> > > This ends up in configure.ac's libcdada AC_CHECK_LIB check as can be
> > > seen in the hackish diff below.
> > >
> > > ${WRKBUILD}/config.log shows the actual error:
> > >
> > > > configure:20504: checking for cdada_get_ver in -lcdada
> > > > configure:20529: cc -o conftest -O2 -pipe -I/usr/local/include
> > > > -L/usr/local/lib conftest.c -lcdada -lcdada -lestdc++>=17 -lpthread
> > > > -lpcap -lm -lpthread >&5
> > > > /usr/bin/ld: cannot find -lestdc++>=17
> > > > collect2: error: ld returned 1 exit status
> > >
> > > Removing the version spec makes configure work thus fixes the build,
> > > but this hackish attempt doesn't look like a solution.
> > >
> > > Leaving this here for others to chime in.
> >
> > it _ought_ to use $(CXX) to try and link rather than $(CC), but I don't
> > know if that's viable with this autoconf check.
>
> Good point, I missed that.
>
> >
> > > .for i in ${COMPILER_LIBCXX}
> > > -CXXLIB+= -l$i
> > > +CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
> > > .endfor
> >
> > I am okay with this with a comment to explain the regex, e.g.
> >
> > # strip off the library-specs(5) version number check
> >
> > the libcdada port itself should have the same change
> >
>
> Like that? Thanks, I'll go with in a few days unless we come up with
> something better.
Better this, also with correct manual section.
Index: devel/libcdada/Makefile
===
RCS file: /home/cvs/ports/devel/libcdada/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- devel/libcdada/Makefile 2 Nov 2021 00:00:24 - 1.4
+++ devel/libcdada/Makefile 22 Feb 2022 00:08:05 -
@@ -5,7 +5,7 @@ COMMENT=basic data structures in C (lib
GH_ACCOUNT=msune
GH_PROJECT=libcdada
GH_TAGNAME=v0.3.4
-REVISION= 1
+REVISION= 2
SHARED_LIBS += cdada 0.0 # 0.0
@@ -34,6 +34,9 @@ post-patch:
sed -i 's,-lstdc++,${CXXLIB},' ${WRKSRC}/examples/Makefile.am
.include
-.for i in ${COMPILER_LIBCXX}
+
+# strip library-specs(7) which ld.bfd(1) does not understand
+# to fix configure on non-clang architectures
+.for i in ${COMPILER_LIBCXX:C/[<>=]+[0-9.]+$//}
CXXLIB+= -l$i
.endfor
Index: net/pmacct/Makefile
===
RCS file: /home/cvs/ports/net/pmacct/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- net/pmacct/Makefile 18 Feb 2021 13:24:04 - 1.34
+++ net/pmacct/Makefile 22 Feb 2022 00:08:06 -
@@ -3,6 +3,7 @@
COMMENT= passive IP network monitoring tools: traffic accounting, etc
DISTNAME= pmacct-1.7.6
+REVISION= 0
CATEGORIES=net
HOMEPAGE= http://www.pmacct.net/
@@ -75,6 +76,9 @@ post-install:
.endif
.include
-.for i in ${COMPILER_LIBCXX}
+
+# strip library-specs(7) which ld.bfd(1) does not understand
+# to fix configure on non-clang architectures
+.for i in ${COMPILER_LIBCXX:C/[<>=]+[0-9.]+$//}
CXXLIB+= -l$i
.endfor
Re: sparc64 bulk build report (pmacct: AC_CHECK_LIB vs. COMPILER_LIBCXX version specs)
On Mon, Feb 21, 2022 at 11:27:37PM +, Stuart Henderson wrote:
> On 2022/02/21 22:12, Klemens Nanni wrote:
> > On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> > > http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/pmacct,postgresql.log
> >
> > > checking for cdada_get_ver in -lcdada... no
> > > configure: error: Could not find libcdada
> >
> > The dependency is correctly handled, but AC_CHECK_LIB chokes on how
> > ports-clang arches handle c++ libs.
> >
> > COMPILER_LIBCXX has "stdc++" and "estdc++>=17" for base-clang and
> > ports-gcc, respectively.
> >
> > This ends up in configure.ac's libcdada AC_CHECK_LIB check as can be
> > seen in the hackish diff below.
> >
> > ${WRKBUILD}/config.log shows the actual error:
> >
> > > configure:20504: checking for cdada_get_ver in -lcdada
> > > configure:20529: cc -o conftest -O2 -pipe -I/usr/local/include
> > > -L/usr/local/lib conftest.c -lcdada -lcdada -lestdc++>=17 -lpthread
> > > -lpcap -lm -lpthread >&5
> > > /usr/bin/ld: cannot find -lestdc++>=17
> > > collect2: error: ld returned 1 exit status
> >
> > Removing the version spec makes configure work thus fixes the build,
> > but this hackish attempt doesn't look like a solution.
> >
> > Leaving this here for others to chime in.
>
> it _ought_ to use $(CXX) to try and link rather than $(CC), but I don't
> know if that's viable with this autoconf check.
Good point, I missed that.
>
> > .for i in ${COMPILER_LIBCXX}
> > -CXXLIB+= -l$i
> > +CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
> > .endfor
>
> I am okay with this with a comment to explain the regex, e.g.
>
> # strip off the library-specs(5) version number check
>
> the libcdada port itself should have the same change
>
Like that? Thanks, I'll go with in a few days unless we come up with
something better.
Index: devel/libcdada/Makefile
===
RCS file: /home/cvs/ports/devel/libcdada/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- devel/libcdada/Makefile 2 Nov 2021 00:00:24 - 1.4
+++ devel/libcdada/Makefile 21 Feb 2022 23:58:11 -
@@ -5,7 +5,7 @@ COMMENT=basic data structures in C (lib
GH_ACCOUNT=msune
GH_PROJECT=libcdada
GH_TAGNAME=v0.3.4
-REVISION= 1
+REVISION= 2
SHARED_LIBS += cdada 0.0 # 0.0
@@ -34,6 +34,9 @@ post-patch:
sed -i 's,-lstdc++,${CXXLIB},' ${WRKSRC}/examples/Makefile.am
.include
+
.for i in ${COMPILER_LIBCXX}
-CXXLIB+= -l$i
+# strip library-specs(5) which ld.bfd(1) does not understand
+# to fix configure on non-clang architectures
+CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
.endfor
Index: net/pmacct/Makefile
===
RCS file: /home/cvs/ports/net/pmacct/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- net/pmacct/Makefile 18 Feb 2021 13:24:04 - 1.34
+++ net/pmacct/Makefile 21 Feb 2022 23:57:27 -
@@ -3,6 +3,7 @@
COMMENT= passive IP network monitoring tools: traffic accounting, etc
DISTNAME= pmacct-1.7.6
+REVISION= 0
CATEGORIES=net
HOMEPAGE= http://www.pmacct.net/
@@ -75,6 +76,9 @@ post-install:
.endif
.include
+
.for i in ${COMPILER_LIBCXX}
-CXXLIB+= -l$i
+# strip library-specs(5) which ld.bfd(1) does not understand
+# to fix configure on non-clang architectures
+CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
.endfor
Re: sparc64 bulk build report (pmacct: AC_CHECK_LIB vs. COMPILER_LIBCXX version specs)
On 2022/02/21 22:12, Klemens Nanni wrote:
> On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/pmacct,postgresql.log
>
> > checking for cdada_get_ver in -lcdada... no
> > configure: error: Could not find libcdada
>
> The dependency is correctly handled, but AC_CHECK_LIB chokes on how
> ports-clang arches handle c++ libs.
>
> COMPILER_LIBCXX has "stdc++" and "estdc++>=17" for base-clang and
> ports-gcc, respectively.
>
> This ends up in configure.ac's libcdada AC_CHECK_LIB check as can be
> seen in the hackish diff below.
>
> ${WRKBUILD}/config.log shows the actual error:
>
> > configure:20504: checking for cdada_get_ver in -lcdada
> > configure:20529: cc -o conftest -O2 -pipe -I/usr/local/include
> > -L/usr/local/lib conftest.c -lcdada -lcdada -lestdc++>=17 -lpthread -lpcap
> > -lm -lpthread >&5
> > /usr/bin/ld: cannot find -lestdc++>=17
> > collect2: error: ld returned 1 exit status
>
> Removing the version spec makes configure work thus fixes the build,
> but this hackish attempt doesn't look like a solution.
>
> Leaving this here for others to chime in.
it _ought_ to use $(CXX) to try and link rather than $(CC), but I don't
know if that's viable with this autoconf check.
> .for i in ${COMPILER_LIBCXX}
> -CXXLIB+= -l$i
> +CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
> .endfor
I am okay with this with a comment to explain the regex, e.g.
# strip off the library-specs(5) version number check
the libcdada port itself should have the same change
Re: sparc64 bulk build report (pmacct: AC_CHECK_LIB vs. COMPILER_LIBCXX version specs)
On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/pmacct,postgresql.log
> checking for cdada_get_ver in -lcdada... no
> configure: error: Could not find libcdada
The dependency is correctly handled, but AC_CHECK_LIB chokes on how
ports-clang arches handle c++ libs.
COMPILER_LIBCXX has "stdc++" and "estdc++>=17" for base-clang and
ports-gcc, respectively.
This ends up in configure.ac's libcdada AC_CHECK_LIB check as can be
seen in the hackish diff below.
${WRKBUILD}/config.log shows the actual error:
> configure:20504: checking for cdada_get_ver in -lcdada
> configure:20529: cc -o conftest -O2 -pipe -I/usr/local/include
> -L/usr/local/lib conftest.c -lcdada -lcdada -lestdc++>=17 -lpthread -lpcap
> -lm -lpthread >&5
> /usr/bin/ld: cannot find -lestdc++>=17
> collect2: error: ld returned 1 exit status
Removing the version spec makes configure work thus fixes the build,
but this hackish attempt doesn't look like a solution.
Leaving this here for others to chime in.
Index: Makefile
===
RCS file: /home/cvs/ports/net/pmacct/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- Makefile18 Feb 2021 13:24:04 - 1.34
+++ Makefile21 Feb 2022 21:51:38 -
@@ -3,6 +3,7 @@
COMMENT= passive IP network monitoring tools: traffic accounting, etc
DISTNAME= pmacct-1.7.6
+REVISION= 0
CATEGORIES=net
HOMEPAGE= http://www.pmacct.net/
@@ -75,6 +76,7 @@ post-install:
.endif
.include
+
.for i in ${COMPILER_LIBCXX}
-CXXLIB+= -l$i
+CXXLIB+= -l${i:C/[<>=]+[0-9.]+$//}
.endfor
Re: sparc64 bulk build report (link-grammar: use ports-gcc, fix python rundep)
On Mon, Feb 21, 2022 at 01:18:37AM +, Klemens Nanni wrote: > On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-02-16/textproc/link-grammar,,-main.log > Needs the usual compiler dance for this: > > /tmp/print-dict-f43ef2.s:4649: Error: operation combines symbols in > > different segments > > clang-13: error: assembler command failed with exit code 1 (use -v to see > > invocation) > Typofix deps while here. > update-plist still puts the python dir into PLIST-main (see diff) which > is wrong but I don't know how to convince it to account for it in > PLIST-python... by not listing it at all since it belongs to > lang/python-3.9 which is now a proper dependency. > OK for the diff *without the PLIST hunk*? ok kmos --Kurt
Re: sparc64 bulk build report (fuse-zip: fix ENODATA usage on non-clang arches)
On Mon, Feb 21, 2022 at 02:19:03AM +, Klemens Nanni wrote: > On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-02-16/archivers/fuse-zip.log > > > fuse-zip.cpp:492:17: error: 'ENODATA' was not declared in this scope > > So ENODATA from /usr/include/c++/v1/errno.h is only defined with > base-clang (I didn't follow the header maze) and a few other ports > already replace ENOADATA with ENOENT or ENOATTR, so do the same except > just pass it along as flags to avoid further patching. > > ENOENT is used in fuse-zip, ENOATTR is not, so pick the latter. > > Builds and tests fine on sparc64. > Feedback? OK? Looks good and works for me. ok kmos --Kurt
Re: sparc64 bulk build report (fuse-zip: fix ENODATA usage on non-clang arches)
On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-16/archivers/fuse-zip.log
> fuse-zip.cpp:492:17: error: 'ENODATA' was not declared in this scope
So ENODATA from /usr/include/c++/v1/errno.h is only defined with
base-clang (I didn't follow the header maze) and a few other ports
already replace ENOADATA with ENOENT or ENOATTR, so do the same except
just pass it along as flags to avoid further patching.
ENOENT is used in fuse-zip, ENOATTR is not, so pick the latter.
Builds and tests fine on sparc64.
Feedback? OK?
Index: Makefile
===
RCS file: /home/cvs/ports/archivers/fuse-zip/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile13 Oct 2021 08:49:03 - 1.16
+++ Makefile21 Feb 2022 02:17:23 -
@@ -3,6 +3,7 @@
COMMENT = navigate zip archives through FUSE
DISTNAME = fuse-zip-0.7.2
+REVISION = 0
CATEGORIES = archivers
@@ -15,7 +16,14 @@ WANTLIB += ${COMPILER_LIBCXX} c fuse m
MASTER_SITES = https://bitbucket.org/agalanin/fuse-zip/downloads/
-COMPILER = base-clang ports-gcc base-gcc
+COMPILER = base-clang ports-gcc
+
+.include
+.if !${PROPERTIES:Mclang}
+# fuse-zip.cpp:492:17: error: 'ENODATA' was not declared in this scope
+# only base-clang ends up defining this errno, so use an unused errno instead
+CXXFLAGS +=-DENODATA=ENOATTR
+.endif
LIB_DEPENDS = archivers/libzip>=0.11.2
Re: sparc64 bulk build report
On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote: > http://build-failures.rhaalovely.net/sparc64/2022-02-16/graphics/libgphoto2.log > Error: > /usr/obj/ports/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.map > does not exist > Error: > /usr/obj/ports/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.md5 > does not exist > Error: > /usr/obj/ports/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.png > does not exist > pkg_create: can't continue I cannot reproduce this on sparc64 or amd64: $ ls /usr/ports/pobj/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.* /usr/ports/pobj/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.map /usr/ports/pobj/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.md5 /usr/ports/pobj/libgphoto-2.5.28/fake-sparc64/usr/local/share/doc/libgphoto2/libgphoto2-api.html/libgphoto2_2i18n_8h__dep__incl.png One thing I noticed: > Running plantuml with JAVA... > Running dot... > Generating dot graphs using 5 parallel threads... > Running dot for graph 1/93 > Running dot for graph 2/93 So I got this on sparc64 which is probably counter-productive: > Generating dot graphs using 33 parallel threads... Not sure where/how to tell dot(1) to use MAKE_JOBS threads here instead.
Re: sparc64 bulk build report (link-grammar: use ports-gcc, fix python rundep)
On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-16/textproc/link-grammar,,-main.log
Needs the usual compiler dance for this:
> /tmp/print-dict-f43ef2.s:4649: Error: operation combines symbols in different
> segments
> clang-13: error: assembler command failed with exit code 1 (use -v to see
> invocation)
Typofix deps while here.
update-plist still puts the python dir into PLIST-main (see diff) which
is wrong but I don't know how to convince it to account for it in
PLIST-python... by not listing it at all since it belongs to
lang/python-3.9 which is now a proper dependency.
OK for the diff *without the PLIST hunk*?
Index: Makefile
===
RCS file: /home/cvs/ports/textproc/link-grammar/Makefile,v
retrieving revision 1.65
diff -u -p -r1.65 Makefile
--- Makefile2 Nov 2021 00:02:36 - 1.65
+++ Makefile21 Feb 2022 01:10:28 -
@@ -8,7 +8,8 @@ COMMENT-java = Java bindings for link-g
COMMENT-python = Python bindings for link-grammar
VERSION = 5.10.2
-REVISION-python= 0
+REVISION-main =0
+REVISION-python = 1
DISTNAME = link-grammar-${VERSION}
PKGNAME-main = ${DISTNAME}
@@ -42,8 +43,8 @@ MODPY_ADJ_FILES = bindings/python-exampl
USE_GMAKE =Yes
-# -std=c++03
-COMPILER = base-clang ports-clang
+# -std=c++03 -std=c11
+COMPILER = base-clang ports-gcc
MULTI_PACKAGES = -main -java -python
PSEUDO_FLAVORS = no_java
@@ -65,7 +66,7 @@ LIB_DEPENDS-python = ${MODPY_LIB_DEPENDS
RUN_DEPENDS-main = # empty
RUN_DEPENDS-java = ${MODJAVA_RUN_DEPENDS}
-RUN_DEPENDS-python = ${MODPYTHON_RUN_DEPENDS}
+RUN_DEPENDS-python = ${MODPY_RUN_DEPENDS}
TEST_DEPENDS = ${BUILD_PKGPATH},-python
Index: pkg/PLIST-main
===
RCS file: /home/cvs/ports/textproc/link-grammar/pkg/PLIST-main,v
retrieving revision 1.37
diff -u -p -r1.37 PLIST-main
--- pkg/PLIST-main 31 Oct 2021 15:02:58 - 1.37
+++ pkg/PLIST-main 21 Feb 2022 01:11:24 -
@@ -10,6 +10,7 @@ include/link-grammar/link-includes.h
lib/liblink-grammar.la
@lib lib/liblink-grammar.so.${LIBlink-grammar_VERSION}
lib/pkgconfig/link-grammar.pc
+lib/python${MODPY_VERSION}/
libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/
libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/clinkgrammar.pm
@so libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/clinkgrammar.so
Re: sparc64 bulk build report (net/zabbix: fix intptr detection on sparc/sparc64)
On Sun, Feb 20, 2022 at 08:38:11AM +0100, Robert Nagy wrote: > The pkg/ dir changes are all wrong. If you only commit the patch > and the Makefile, it is ok. Will do, thanks.
Re: sparc64 bulk build report (net/zabbix: fix intptr detection on sparc/sparc64)
On Sun, Feb 20, 2022 at 02:21:07PM +0100, Jeremie Courreges-Anglas wrote: > duktape is en embeddable javascript interpreter, also available as > lang/duktape. It would be good to either reuse lang/duktape instead of > patching n embedded copies, or to try to keep in sync the patches > between the duktape copies (lang/duktape/patches/patch-src_duk_config_h). I'll sync my patch to the port, thanks.
Re: sparc64 bulk build report (net/zabbix: fix intptr detection on sparc/sparc64)
On Sat, Feb 19 2022, Klemens Nanni wrote:
> [resending to ports@]
>
> On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
>> http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/zabbix,sqlite3,-main.log
>
>> In file included from duktape.h:196,
>> from duktape.c:189:
>> duk_config.h:1981:2: error: #error cannot determine intptr type
>
> Zabbix already has defines for sparc and sparc64 but this particular
> code ignored them.
>
> I bumped all revisions just to be sure, but there's PLIST churn anyway,
> so now they're justified ;)
>
> Only build-tested on sparc64.
> Feedback? OK?
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/zabbix/Makefile,v
> retrieving revision 1.180
> diff -u -p -r1.180 Makefile
> --- Makefile 18 Feb 2022 06:42:35 - 1.180
> +++ Makefile 19 Feb 2022 20:09:14 -
> @@ -15,8 +15,10 @@ FULLPKGNAME-web = zabbix-web-${VERSION}
> FULLPKGPATH-web =net/zabbix,-web
> CATEGORIES = net
>
> -REVISION-main = 1
> -REVISION-server =0
> +REVISION-main = 2
> +REVISION-server =1
> +REVISION-proxy = 0
> +REVISION-web = 0
>
> MAJV = ${VERSION:C/^([0-9]+\.[0-9]+).*/\1/}
>
> Index: patches/patch-src_libs_zbxembed_duk_config_h
> ===
> RCS file: patches/patch-src_libs_zbxembed_duk_config_h
> diff -N patches/patch-src_libs_zbxembed_duk_config_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_libs_zbxembed_duk_config_h 19 Feb 2022 20:14:49
> -
> @@ -0,0 +1,25 @@
> +$OpenBSD$
> +
> +Fix sparc and sparc64 detection for intptr type
> +
> +Index: src/libs/zbxembed/duk_config.h
> +--- src/libs/zbxembed/duk_config.h.orig
> src/libs/zbxembed/duk_config.h
> +@@ -1617,7 +1617,7 @@
> + */
> + #if defined(DUK_F_X86) || defined(DUK_F_X32) || \
> + defined(DUK_F_M68K) || defined(DUK_F_PPC32) || \
> +-defined(DUK_F_BCC) || \
> ++defined(DUK_F_BCC) || defined(DUK_F_SPARC32) || \
> + (defined(__WORDSIZE) && (__WORDSIZE == 32)) || \
> + ((defined(DUK_F_OLD_SOLARIS) || defined(DUK_F_AIX) || \
> + defined(DUK_F_HPUX)) && defined(_ILP32)) || \
> +@@ -1627,7 +1627,7 @@
> + (defined(__WORDSIZE) && (__WORDSIZE == 64)) || \
> +((defined(DUK_F_OLD_SOLARIS) || defined(DUK_F_AIX) || \
> + defined(DUK_F_HPUX)) && defined(_LP64)) || \
> +-defined(DUK_F_ARM64)
> ++defined(DUK_F_ARM64) || defined(DUK_F_SPARC64)
> + #define DUK_F_64BIT_PTRS
> + #else
> + /* not sure, not needed with C99 anyway */
duktape is en embeddable javascript interpreter, also available as
lang/duktape. It would be good to either reuse lang/duktape instead of
patching n embedded copies, or to try to keep in sync the patches
between the duktape copies (lang/duktape/patches/patch-src_duk_config_h).
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sparc64 bulk build report (net/zabbix: fix intptr detection on sparc/sparc64)
On 19/02/22 22:34 +, Klemens Nanni wrote:
> [resending to ports@]
>
> On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/zabbix,sqlite3,-main.log
>
> > In file included from duktape.h:196,
> > from duktape.c:189:
> > duk_config.h:1981:2: error: #error cannot determine intptr type
>
> Zabbix already has defines for sparc and sparc64 but this particular
> code ignored them.
>
> I bumped all revisions just to be sure, but there's PLIST churn anyway,
> so now they're justified ;)
>
> Only build-tested on sparc64.
> Feedback? OK?
The pkg/ dir changes are all wrong. If you only commit the patch
and the Makefile, it is ok.
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/zabbix/Makefile,v
> retrieving revision 1.180
> diff -u -p -r1.180 Makefile
> --- Makefile 18 Feb 2022 06:42:35 - 1.180
> +++ Makefile 19 Feb 2022 20:09:14 -
> @@ -15,8 +15,10 @@ FULLPKGNAME-web = zabbix-web-${VERSION}
> FULLPKGPATH-web =net/zabbix,-web
> CATEGORIES = net
>
> -REVISION-main = 1
> -REVISION-server =0
> +REVISION-main = 2
> +REVISION-server =1
> +REVISION-proxy = 0
> +REVISION-web = 0
>
> MAJV = ${VERSION:C/^([0-9]+\.[0-9]+).*/\1/}
>
> Index: patches/patch-src_libs_zbxembed_duk_config_h
> ===
> RCS file: patches/patch-src_libs_zbxembed_duk_config_h
> diff -N patches/patch-src_libs_zbxembed_duk_config_h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_libs_zbxembed_duk_config_h 19 Feb 2022 20:14:49
> -
> @@ -0,0 +1,25 @@
> +$OpenBSD$
> +
> +Fix sparc and sparc64 detection for intptr type
> +
> +Index: src/libs/zbxembed/duk_config.h
> +--- src/libs/zbxembed/duk_config.h.orig
> src/libs/zbxembed/duk_config.h
> +@@ -1617,7 +1617,7 @@
> + */
> + #if defined(DUK_F_X86) || defined(DUK_F_X32) || \
> + defined(DUK_F_M68K) || defined(DUK_F_PPC32) || \
> +-defined(DUK_F_BCC) || \
> ++defined(DUK_F_BCC) || defined(DUK_F_SPARC32) || \
> + (defined(__WORDSIZE) && (__WORDSIZE == 32)) || \
> + ((defined(DUK_F_OLD_SOLARIS) || defined(DUK_F_AIX) || \
> + defined(DUK_F_HPUX)) && defined(_ILP32)) || \
> +@@ -1627,7 +1627,7 @@
> + (defined(__WORDSIZE) && (__WORDSIZE == 64)) || \
> +((defined(DUK_F_OLD_SOLARIS) || defined(DUK_F_AIX) || \
> + defined(DUK_F_HPUX)) && defined(_LP64)) || \
> +-defined(DUK_F_ARM64)
> ++defined(DUK_F_ARM64) || defined(DUK_F_SPARC64)
> + #define DUK_F_64BIT_PTRS
> + #else
> + /* not sure, not needed with C99 anyway */
> Index: pkg/PLIST-main
> ===
> RCS file: /home/cvs/ports/net/zabbix/pkg/PLIST-main,v
> retrieving revision 1.14
> diff -u -p -r1.14 PLIST-main
> --- pkg/PLIST-main18 Feb 2022 06:42:35 - 1.14
> +++ pkg/PLIST-main19 Feb 2022 20:24:47 -
> @@ -7,24 +7,45 @@
> @newgroup _zabbix:623
> @newuser _zabbix:623:_zabbix::zabbix user:/nonexistent:/sbin/nologin
> @extraunexec rm -rf /var/log/zabbix/*
> +@rcscript ${RCDIR}/zabbix_agentd
> +@rcscript ${RCDIR}/zabbix_server
> +@sample ${SYSCONFDIR}/zabbix/
> @bin bin/zabbix_get
> +@bin bin/zabbix_js
> @bin bin/zabbix_sender
> +lib/modules/
> @man man/man1/zabbix_get.1
> @man man/man1/zabbix_sender.1
> @man man/man8/zabbix_agentd.8
> @bin sbin/zabbix_agentd
> +share/doc/zabbix/
> share/examples/zabbix/
> -@sample ${SYSCONFDIR}/zabbix/
> share/examples/zabbix/zabbix_agentd.conf
> @mode 640
> @group _zabbix
> @sample ${SYSCONFDIR}/zabbix/zabbix_agentd.conf
> -@comment share/examples/zabbix/zabbix_agentd.win.conf
> -@mode
> -@group
> @mode 0755
> @owner _zabbix
> +@group
> @sample /var/log/zabbix/
> -@owner
> +@comment share/examples/zabbix/zabbix_agentd.win.conf
> @mode
> -@rcscript ${RCDIR}/zabbix_agentd
> +@owner
> +share/examples/zabbix/zabbix_server.conf
> +share/zabbix-proxy/schema/mysql/Makefile
> +share/zabbix-proxy/schema/mysql/Makefile.am
> +share/zabbix-proxy/schema/mysql/Makefile.in
> +share/zabbix-proxy/schema/mysql/data.sql
> +share/zabbix-proxy/schema/mysql/double.sql
> +share/zabbix-proxy/schema/mysql/images.sql
> +share/zabbix-proxy/schema/mysql/schema.sql
> +share/zabbix-proxy/schema/postgresql/
> +share/zabbix-proxy/schema/postgresql/Makefile
> +share/zabbix-proxy/schema/postgresql/Makefile.am
> +share/zabbix-proxy/schema/postgresql/Makefile.in
> +share/zabbix-proxy/schema/postgresql/data.sql
> +share/zabbix-proxy/schema/postgresql/double.sql
> +share/zabbix-proxy/schema/postgresql/images.sql
> +share/zabbix-proxy/schema/postgresql/schema.sql
> +share/zabbix-proxy/schema/postgresql/timescaledb.sql
> +share/zabbix-server/
> Index: pkg/PLIST-proxy
> ===
> RCS file:
Re: sparc64 bulk build report (net/zabbix: fix intptr detection on sparc/sparc64)
[resending to ports@]
On Sat, Feb 19, 2022 at 02:40:24AM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-16/net/zabbix,sqlite3,-main.log
> In file included from duktape.h:196,
> from duktape.c:189:
> duk_config.h:1981:2: error: #error cannot determine intptr type
Zabbix already has defines for sparc and sparc64 but this particular
code ignored them.
I bumped all revisions just to be sure, but there's PLIST churn anyway,
so now they're justified ;)
Only build-tested on sparc64.
Feedback? OK?
Index: Makefile
===
RCS file: /home/cvs/ports/net/zabbix/Makefile,v
retrieving revision 1.180
diff -u -p -r1.180 Makefile
--- Makefile18 Feb 2022 06:42:35 - 1.180
+++ Makefile19 Feb 2022 20:09:14 -
@@ -15,8 +15,10 @@ FULLPKGNAME-web =zabbix-web-${VERSION}
FULLPKGPATH-web = net/zabbix,-web
CATEGORIES = net
-REVISION-main =1
-REVISION-server = 0
+REVISION-main =2
+REVISION-server = 1
+REVISION-proxy = 0
+REVISION-web = 0
MAJV = ${VERSION:C/^([0-9]+\.[0-9]+).*/\1/}
Index: patches/patch-src_libs_zbxembed_duk_config_h
===
RCS file: patches/patch-src_libs_zbxembed_duk_config_h
diff -N patches/patch-src_libs_zbxembed_duk_config_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_libs_zbxembed_duk_config_h19 Feb 2022 20:14:49
-
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+Fix sparc and sparc64 detection for intptr type
+
+Index: src/libs/zbxembed/duk_config.h
+--- src/libs/zbxembed/duk_config.h.orig
src/libs/zbxembed/duk_config.h
+@@ -1617,7 +1617,7 @@
+ */
+ #if defined(DUK_F_X86) || defined(DUK_F_X32) || \
+ defined(DUK_F_M68K) || defined(DUK_F_PPC32) || \
+-defined(DUK_F_BCC) || \
++defined(DUK_F_BCC) || defined(DUK_F_SPARC32) || \
+ (defined(__WORDSIZE) && (__WORDSIZE == 32)) || \
+ ((defined(DUK_F_OLD_SOLARIS) || defined(DUK_F_AIX) || \
+ defined(DUK_F_HPUX)) && defined(_ILP32)) || \
+@@ -1627,7 +1627,7 @@
+ (defined(__WORDSIZE) && (__WORDSIZE == 64)) || \
+((defined(DUK_F_OLD_SOLARIS) || defined(DUK_F_AIX) || \
+ defined(DUK_F_HPUX)) && defined(_LP64)) || \
+-defined(DUK_F_ARM64)
++defined(DUK_F_ARM64) || defined(DUK_F_SPARC64)
+ #define DUK_F_64BIT_PTRS
+ #else
+ /* not sure, not needed with C99 anyway */
Index: pkg/PLIST-main
===
RCS file: /home/cvs/ports/net/zabbix/pkg/PLIST-main,v
retrieving revision 1.14
diff -u -p -r1.14 PLIST-main
--- pkg/PLIST-main 18 Feb 2022 06:42:35 - 1.14
+++ pkg/PLIST-main 19 Feb 2022 20:24:47 -
@@ -7,24 +7,45 @@
@newgroup _zabbix:623
@newuser _zabbix:623:_zabbix::zabbix user:/nonexistent:/sbin/nologin
@extraunexec rm -rf /var/log/zabbix/*
+@rcscript ${RCDIR}/zabbix_agentd
+@rcscript ${RCDIR}/zabbix_server
+@sample ${SYSCONFDIR}/zabbix/
@bin bin/zabbix_get
+@bin bin/zabbix_js
@bin bin/zabbix_sender
+lib/modules/
@man man/man1/zabbix_get.1
@man man/man1/zabbix_sender.1
@man man/man8/zabbix_agentd.8
@bin sbin/zabbix_agentd
+share/doc/zabbix/
share/examples/zabbix/
-@sample ${SYSCONFDIR}/zabbix/
share/examples/zabbix/zabbix_agentd.conf
@mode 640
@group _zabbix
@sample ${SYSCONFDIR}/zabbix/zabbix_agentd.conf
-@comment share/examples/zabbix/zabbix_agentd.win.conf
-@mode
-@group
@mode 0755
@owner _zabbix
+@group
@sample /var/log/zabbix/
-@owner
+@comment share/examples/zabbix/zabbix_agentd.win.conf
@mode
-@rcscript ${RCDIR}/zabbix_agentd
+@owner
+share/examples/zabbix/zabbix_server.conf
+share/zabbix-proxy/schema/mysql/Makefile
+share/zabbix-proxy/schema/mysql/Makefile.am
+share/zabbix-proxy/schema/mysql/Makefile.in
+share/zabbix-proxy/schema/mysql/data.sql
+share/zabbix-proxy/schema/mysql/double.sql
+share/zabbix-proxy/schema/mysql/images.sql
+share/zabbix-proxy/schema/mysql/schema.sql
+share/zabbix-proxy/schema/postgresql/
+share/zabbix-proxy/schema/postgresql/Makefile
+share/zabbix-proxy/schema/postgresql/Makefile.am
+share/zabbix-proxy/schema/postgresql/Makefile.in
+share/zabbix-proxy/schema/postgresql/data.sql
+share/zabbix-proxy/schema/postgresql/double.sql
+share/zabbix-proxy/schema/postgresql/images.sql
+share/zabbix-proxy/schema/postgresql/schema.sql
+share/zabbix-proxy/schema/postgresql/timescaledb.sql
+share/zabbix-server/
Index: pkg/PLIST-proxy
===
RCS file: /home/cvs/ports/net/zabbix/pkg/PLIST-proxy,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST-proxy
--- pkg/PLIST-proxy 27 Jul 2020 14:32:03 - 1.7
+++ pkg/PLIST-proxy 19 Feb 2022 20:24:50 -
@@ -1,9 +1,10 @@
@comment $OpenBSD: PLIST-proxy,v 1.7 2020/07/27 14:32:03 jasper Exp $
@pkgpath net/zabbix,-proxy
@extraunexec rm -rf /var/log/zabbix/*
+@rcscript ${RCDIR}/zabbix_proxy
Re: sparc64 bulk build report
On Fri, Feb 18, 2022 at 06:46:08PM +, Klemens Nanni wrote:
> On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-09/net/bro.log
>
> > /tmp/sqlite3-1f089a.s:544060: Error: operation combines symbols in
> > different segments
> > clang-13: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
>
> Usually we ditch ports-clang for this, but this port has this:
>
> # c++11
> #COMPILER= base-clang ports-gcc
> # XXX src/modp_numtoa.c:174:30: error: use of undeclared identifier
> 'DBL_DECIMAL_DIG'
> COMPILER= ports-clang
>
> I suspect other non-clang arches fail similarly, so rather than marking it
> BROKEN-sparc64, how about limiting it to clang-arches?
OK but I don't think this needs a bump.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/bro/Makefile,v
> retrieving revision 1.83
> diff -u -p -r1.83 Makefile
> --- Makefile 26 Jan 2022 12:55:12 - 1.83
> +++ Makefile 18 Feb 2022 18:45:24 -
> @@ -8,6 +8,7 @@ COMMENT= network analysis and security
>
> V= 4.0.5
> DISTNAME=zeek-${V}
> +REVISION=0
>
> SHARED_LIBS += binpac2.0
> SHARED_LIBS += broccoli 9.0
> @@ -39,6 +40,10 @@ MODULES= lang/python
> #COMPILER= base-clang ports-gcc
> # XXX src/modp_numtoa.c:174:30: error: use of undeclared identifier
> 'DBL_DECIMAL_DIG'
> COMPILER=ports-clang
> +# XXX sparc64 and ports-clang don't go well together:
> +# /tmp/sqlite3-1f089a.s:544060: Error: operation combines symbols in
> different segments
> +# clang-13: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> +ONLY_FOR_ARCHS= ${CLANG_ARCHS}
>
> MODPY_ADJ_FILES= auxil/btest/btest \
> auxil/zeekctl/bin/stats-to-csv \
>
--
Antoine
Re: sparc64 bulk build report (lebiniou: ports-gcc for -std=c11, -
On Fri, Feb 18, 2022 at 03:26:44PM -0500, Kurt Mosiejczuk wrote:
> On Fri, Feb 18, 2022 at 08:09:16PM +, Klemens Nanni wrote:
>
> > > Index: patches/patch-src_Makefile_am
> > > ===
> > > RCS file: /cvs/ports/multimedia/lebiniou/patches/patch-src_Makefile_am,v
> > > retrieving revision 1.2
> > > diff -u -p -r1.2 patch-src_Makefile_am
> > > --- patches/patch-src_Makefile_am 9 Feb 2022 10:23:23 - 1.2
> > > +++ patches/patch-src_Makefile_am 18 Feb 2022 19:37:51 -
> > > @@ -52,7 +52,7 @@ Index: src/Makefile.am
> > > lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> > > ${ORCANIA_LIBS} ${YDER_LIBS}
> > > else
> > > -lebiniou_LDADD = -L. -l:liblebiniou.so.0 ${MAGICKWAND_LIBS}
> > > ${ULFIUS_LIBS} ${ORCANIA_LIBS} ${YDER_LIBS}
> > > -+lebiniou_LDADD = -L. -l:liblebiniou.so ${MAGICKWAND_LIBS}
> > > ${ULFIUS_LIBS} ${ORCANIA_LIBS} ${YDER_LIBS}
> > > ++lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> > > ${ORCANIA_LIBS} ${YDER_LIBS}
>
> > Oops, that what I have too (shouldn't manually edit the old patch in my
> > mail rather than recopying it...)
>
> :)
>
> Do note that I put in the missing COMPILER_LANGS = c line you missed.
>
> > OK?
>
> As long as you have that COMPILER_LANGS line too, ok kmos :)
No, I didn't. Please go ahead, OK kn.
>
> --Kurt
>
Re: sparc64 bulk build report (lebiniou: ports-gcc for -std=c11, -
On Fri, Feb 18, 2022 at 08:09:16PM +, Klemens Nanni wrote:
> > Index: patches/patch-src_Makefile_am
> > ===
> > RCS file: /cvs/ports/multimedia/lebiniou/patches/patch-src_Makefile_am,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 patch-src_Makefile_am
> > --- patches/patch-src_Makefile_am 9 Feb 2022 10:23:23 - 1.2
> > +++ patches/patch-src_Makefile_am 18 Feb 2022 19:37:51 -
> > @@ -52,7 +52,7 @@ Index: src/Makefile.am
> > lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> > ${ORCANIA_LIBS} ${YDER_LIBS}
> > else
> > -lebiniou_LDADD = -L. -l:liblebiniou.so.0 ${MAGICKWAND_LIBS}
> > ${ULFIUS_LIBS} ${ORCANIA_LIBS} ${YDER_LIBS}
> > -+lebiniou_LDADD = -L. -l:liblebiniou.so ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> > ${ORCANIA_LIBS} ${YDER_LIBS}
> > ++lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> > ${ORCANIA_LIBS} ${YDER_LIBS}
> Oops, that what I have too (shouldn't manually edit the old patch in my
> mail rather than recopying it...)
:)
Do note that I put in the missing COMPILER_LANGS = c line you missed.
> OK?
As long as you have that COMPILER_LANGS line too, ok kmos :)
--Kurt
Re: sparc64 bulk build report (lebiniou: ports-gcc for -std=c11, -
On Fri, Feb 18, 2022 at 03:00:49PM -0500, Kurt Mosiejczuk wrote:
> On Fri, Feb 18, 2022 at 06:36:00PM +, Klemens Nanni wrote:
> > On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> > > http://build-failures.rhaalovely.net/sparc64/2022-02-09/multimedia/lebiniou.log
>
> > This log seems to contain two builds, one with base-gcc and one with
> > ports-gcc:
>
> You noticed that, eh? :) I tried the simple swap to ports-gcc.
>
> > So is amd64 falling under OS_DARWIN here?
> > sparc64 definitely uses the latter, as can be confirmed by building with
> > the patch below which fixes the sparc64 build.
>
> > It seems correct and wrong at the same time...
> > Cc'ing the two involved in this new port.
>
> Your patch didn't work to fix it for me. This worked instead. It also still
> builds properly on amd64.
>
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/lebiniou/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- Makefile 9 Feb 2022 10:23:23 - 1.2
> +++ Makefile 18 Feb 2022 19:37:51 -
> @@ -5,6 +5,7 @@ COMMENT = music visualization & VJing to
> PKGNAME =${DISTNAME:S/-version//}
> DISTNAME = lebiniou-${V}
> V = version-3.65.0
> +REVISION = 0
>
> CATEGORIES = multimedia
>
> @@ -19,6 +20,10 @@ WANTLIB += pthread pulse pulse-simple sn
> WANTLIB += yder
>
> MASTER_SITES = https://gitlab.com/lebiniou/lebiniou/-/archive/${V}/
> +
> +# C11
> +COMPILER = base-clang ports-gcc
> +COMPILER_LANGS = c
>
> RUN_DEPENDS += devel/desktop-file-utils \
> x11/gtk+3,-guic
> Index: patches/patch-src_Makefile_am
> ===
> RCS file: /cvs/ports/multimedia/lebiniou/patches/patch-src_Makefile_am,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-src_Makefile_am
> --- patches/patch-src_Makefile_am 9 Feb 2022 10:23:23 - 1.2
> +++ patches/patch-src_Makefile_am 18 Feb 2022 19:37:51 -
> @@ -52,7 +52,7 @@ Index: src/Makefile.am
> lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> ${ORCANIA_LIBS} ${YDER_LIBS}
> else
> -lebiniou_LDADD = -L. -l:liblebiniou.so.0 ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> ${ORCANIA_LIBS} ${YDER_LIBS}
> -+lebiniou_LDADD = -L. -l:liblebiniou.so ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> ${ORCANIA_LIBS} ${YDER_LIBS}
> ++lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
> ${ORCANIA_LIBS} ${YDER_LIBS}
Oops, that what I have too (shouldn't manually edit the old patch in my
mail rather than recopying it...)
OK?
> endif
>
> commands.h: commands.h.head commands.c.in commands.h.tail commands_enum.awk
>
Re: sparc64 bulk build report (lebiniou: ports-gcc for -std=c11, -
On Fri, Feb 18, 2022 at 06:36:00PM +, Klemens Nanni wrote:
> On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-09/multimedia/lebiniou.log
> This log seems to contain two builds, one with base-gcc and one with
> ports-gcc:
You noticed that, eh? :) I tried the simple swap to ports-gcc.
> So is amd64 falling under OS_DARWIN here?
> sparc64 definitely uses the latter, as can be confirmed by building with
> the patch below which fixes the sparc64 build.
> It seems correct and wrong at the same time...
> Cc'ing the two involved in this new port.
Your patch didn't work to fix it for me. This worked instead. It also still
builds properly on amd64.
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/multimedia/lebiniou/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile9 Feb 2022 10:23:23 - 1.2
+++ Makefile18 Feb 2022 19:37:51 -
@@ -5,6 +5,7 @@ COMMENT = music visualization & VJing to
PKGNAME = ${DISTNAME:S/-version//}
DISTNAME = lebiniou-${V}
V =version-3.65.0
+REVISION = 0
CATEGORIES = multimedia
@@ -19,6 +20,10 @@ WANTLIB += pthread pulse pulse-simple sn
WANTLIB += yder
MASTER_SITES = https://gitlab.com/lebiniou/lebiniou/-/archive/${V}/
+
+# C11
+COMPILER = base-clang ports-gcc
+COMPILER_LANGS = c
RUN_DEPENDS += devel/desktop-file-utils \
x11/gtk+3,-guic
Index: patches/patch-src_Makefile_am
===
RCS file: /cvs/ports/multimedia/lebiniou/patches/patch-src_Makefile_am,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_Makefile_am
--- patches/patch-src_Makefile_am 9 Feb 2022 10:23:23 - 1.2
+++ patches/patch-src_Makefile_am 18 Feb 2022 19:37:51 -
@@ -52,7 +52,7 @@ Index: src/Makefile.am
lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
${ORCANIA_LIBS} ${YDER_LIBS}
else
-lebiniou_LDADD = -L. -l:liblebiniou.so.0 ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
${ORCANIA_LIBS} ${YDER_LIBS}
-+lebiniou_LDADD = -L. -l:liblebiniou.so ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
${ORCANIA_LIBS} ${YDER_LIBS}
++lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
${ORCANIA_LIBS} ${YDER_LIBS}
endif
commands.h: commands.h.head commands.c.in commands.h.tail commands_enum.awk
Re: sparc64 bulk build report
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/net/bro.log
> /tmp/sqlite3-1f089a.s:544060: Error: operation combines symbols in different
> segments
> clang-13: error: assembler command failed with exit code 1 (use -v to see
> invocation)
Usually we ditch ports-clang for this, but this port has this:
# c++11
#COMPILER= base-clang ports-gcc
# XXX src/modp_numtoa.c:174:30: error: use of undeclared identifier
'DBL_DECIMAL_DIG'
COMPILER= ports-clang
I suspect other non-clang arches fail similarly, so rather than marking it
BROKEN-sparc64, how about limiting it to clang-arches?
Index: Makefile
===
RCS file: /cvs/ports/net/bro/Makefile,v
retrieving revision 1.83
diff -u -p -r1.83 Makefile
--- Makefile26 Jan 2022 12:55:12 - 1.83
+++ Makefile18 Feb 2022 18:45:24 -
@@ -8,6 +8,7 @@ COMMENT=network analysis and security
V= 4.0.5
DISTNAME= zeek-${V}
+REVISION= 0
SHARED_LIBS += binpac2.0
SHARED_LIBS += broccoli 9.0
@@ -39,6 +40,10 @@ MODULES= lang/python
#COMPILER= base-clang ports-gcc
# XXX src/modp_numtoa.c:174:30: error: use of undeclared identifier
'DBL_DECIMAL_DIG'
COMPILER= ports-clang
+# XXX sparc64 and ports-clang don't go well together:
+# /tmp/sqlite3-1f089a.s:544060: Error: operation combines symbols in different
segments
+# clang-13: error: assembler command failed with exit code 1 (use -v to see
invocation)
+ONLY_FOR_ARCHS=${CLANG_ARCHS}
MODPY_ADJ_FILES= auxil/btest/btest \
auxil/zeekctl/bin/stats-to-csv \
Re: sparc64 bulk build report (lebiniou: ports-gcc for -std=c11, -
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/multimedia/lebiniou.log
This log seems to contain two builds, one with base-gcc and one with
ports-gcc:
> ===> Compiler link: cc -> /usr/bin/cc
> ===> Compiler link: c++ -> /usr/bin/c++
> >>> Running configure in multimedia/lebiniou at 1644578989.70
This fails early:
> cc1: error: unrecognized command line option "-std=c11"
> ===> Compiler link: gcc -> /usr/local/bin/egcc
> ===> Compiler link: cc -> /usr/local/bin/egcc
> ===> Compiler link: c++ -> /usr/bin/c++
> >>> Running configure in multimedia/lebiniou at 1644589514.74
This fails late:
> cc -fPIE -fPIC -I/usr/local/include/ImageMagick -DMAGICKCORE_HDRI_ENABLE=0
> -DMAGICKCORE_QUANTUM_DEPTH=16 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Werror -fomit-frame-pointer -std=c11
> -fsigned-char -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> -I/usr/local/include -O2 -pipe -pthread -Wl,-z,relro -Wl,-z,now -rdynamic -o
> lebiniou lebiniou-main.o lebiniou-cmdline.o lebiniou-signals.o
> lebiniou-bulfius_vui.o lebiniou-bulfius_vui_callback.o
> lebiniou-bulfius_get_colormap.o lebiniou-bulfius_get_image.o
> lebiniou-bulfius_get_frame.o lebiniou-bulfius_get_parameters.o
> lebiniou-bulfius_get_plugins.o lebiniou-bulfius_get_sequence.o
> lebiniou-bulfius_get_statistics.o lebiniou-bulfius_options.o
> lebiniou-bulfius_post_sequence.o lebiniou-bulfius_post_sequences.o
> lebiniou-bulfius_post_command.o lebiniou-bulfius_post_parameters.o
> lebiniou-bulfius_post_plugins.o lebiniou-bulfius_preview.o
> lebiniou-bulfius_vui_get_settings.o lebiniou-bulfius_vui_post_settings.o
> lebiniou-context_free_commands.o lebiniou-context_new_delete.o
> lebiniou-context_playlist.o lebiniou-image_8bits.o lebiniou-images.o
> lebiniou-options.o lebiniou-biniou.o lebiniou-circle.o lebiniou-context_run.o
> lebiniou-context_statistics.o lebiniou-scheme.o lebiniou-schemes.o
> lebiniou-schemes_str2option.o lebiniou-sequences.o lebiniou-commands.o
> lebiniou-bulfius_get_commands.o lebiniou-bulfius_str2command.o
> lebiniou-bulfius_command2str.o -L. -l:liblebiniou.so -L/usr/X11R6/lib
> -L/usr/local/lib -lMagickWand-6.Q16 -lMagickCore-6.Q16 -L/usr/local/lib
> -lulfius -lorcania -lyder -L/usr/local/lib -lorcania -L/usr/local/lib -lyder
> -lorcania -L/usr/local/lib -lglib-2.0 -lintl -L/usr/local/lib -ljansson -lm
> /usr/bin/ld: cannot find -l:liblebiniou.so
Confusingly, this builds fine on amd64:
> cc -fPIC -I../../../src -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Werror -fomit-frame-pointer -std=c11
> -fsigned-char -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> -I/usr/local/include -O2 -pipe -shared -fPIC -pthread -L../../../src
> -Wl,-z,relro -Wl,-z,now -rdynamic -o caca.so caca_so-caca.o -llebiniou
> -L/usr/local/lib -lcaca -L/usr/local/lib -lglib-2.0 -lintl -L/usr/local/lib
> -ljansson -lm
Which is interesting, since the it uses -liblebiniou rather than
-liblebniniou -- the src/Makefile.am (after our current patch) part that
decides this goes like
if OS_DARWIN
lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
${ORCANIA_LIBS} ${YDER_LIBS}
else
lebiniou_LDADD = -L. -l:liblebiniou.so ${MAGICKWAND_LIBS}
${ULFIUS_LIBS} ${ORCANIA_LIBS} ${YDER_LIBS}
endif
So is amd64 falling under OS_DARWIN here?
sparc64 definitely uses the latter, as can be confirmed by building with
the patch below which fixes the sparc64 build.
It seems correct and wrong at the same time...
Cc'ing the two involved in this new port.
Index: Makefile
===
RCS file: /cvs/ports/multimedia/lebiniou/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile9 Feb 2022 10:23:23 - 1.2
+++ Makefile18 Feb 2022 18:11:39 -
@@ -5,6 +5,7 @@ COMMENT = music visualization & VJing to
PKGNAME = ${DISTNAME:S/-version//}
DISTNAME = lebiniou-${V}
V =version-3.65.0
+REVISION = 0
CATEGORIES = multimedia
@@ -19,6 +20,9 @@ WANTLIB +=pthread pulse pulse-simple sn
WANTLIB += yder
MASTER_SITES = https://gitlab.com/lebiniou/lebiniou/-/archive/${V}/
+
+# -std=c11
+COMPILER = base-clang ports-gcc
RUN_DEPENDS += devel/desktop-file-utils \
x11/gtk+3,-guic
Index: patches/patch-src_Makefile_am
===
RCS file: /cvs/ports/multimedia/lebiniou/patches/patch-src_Makefile_am,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_Makefile_am
--- patches/patch-src_Makefile_am 9 Feb 2022 10:23:23 - 1.2
+++ patches/patch-src_Makefile_am 18 Feb 2022 18:11:49 -
@@ -52,7 +52,7 @@ Index: src/Makefile.am
lebiniou_LDADD = -L. -llebiniou ${MAGICKWAND_LIBS} ${ULFIUS_LIBS}
${ORCANIA_LIBS} ${YDER_LIBS}
Re: sparc64 bulk build report (ports-gcc and -lstdc++fs: undefined std::filesystem references)
On Fri, Feb 18, 2022 at 05:21:34PM +, Klemens Nanni wrote: > Aja: You added the mkvtoolnix fix; has it worked in the passed? Sorry, that was Rafael, I mixed it up with a fix in net/bro you did.
Re: sparc64 bulk build report (ports-gcc and -lstdc++fs: undefined std::filesystem references)
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/multimedia/mkvtoolnix.log
This port uses the following but still fails to resolve
symbols; Apparently starting with 9, GCC automatically links against
this library when this include is used, but GCC 8 does not.
# need to add this for gcc
# revisit when gcc drops it
EXTRA_ports-gcc=-lstdc++fs
LDFLAGS+= ${EXTRA_${CHOSEN_COMPILER}}
Yet it still (or again?) fails to link:
> FAILED: bin/clazy-standalone
: && /usr/obj/ports/clazy-1.10/bin/c++ -O2 -pipe -std=c++14 -fno-common
-Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long
-Wall -W -Wno-unused-parameter -Wwrite-strings -fno-exceptions -fno-rtti -fPIC
-DNDEBUG CMakeFiles/clazy-standalone.dir/src/ClazyStandaloneMain.cpp.o -o
bin/clazy-standalone -L/usr/local/lib
-L/usr/obj/ports/clazy-1.10/build-sparc64/lib
-Wl,-z,origin,-rpath,/usr/obj/ports/clazy-1.10/build-sparc64/lib:
-lClazyPlugin -lclang-cpp -lLLVM-13 -Wl,-rpath-link,/usr/X11R6/lib && :
> /usr/obj/ports/clazy-1.10/build-sparc64/lib/libClazyPlugin.so: undefined
> reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
> /usr/obj/ports/clazy-1.10/build-sparc64/lib/libClazyPlugin.so: undefined
> reference to `std::filesystem::__cxx11::path::_M_find_extension() const'
lang/clazy uses -lstdc++11 on its own and fails the same way:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/lang/clazy.log
> c++ -fstack-protector-strong -lstdc++fs -L/usr/local/lib -L/usr/X11R6/lib
> -L/usr/local/lib/qt5 -L/usr/local/lib -Llib/avilib-0.6.10 -Llib/librmff
> -Lsrc/common -o src/tools/ebml_validator src/tools/ebml_validator.o
> src/tools/element_info.o -lmtxcommon -L/usr/local/lib -lmatroska
> -L/usr/local/lib -lebml -lFLAC -logg -lm -lz -L/usr/local/lib -lpugixml
> -lintl -liconv -lfmt -lQt5Core -lgmp -L/usr/local/lib -lcmark
> -L/usr/local/lib -ldvdread
> ...
> src/common/libmtxcommon.a(logger.o): In function
> `mtx::log::file_target_c::log_line(std::__cxx11::basic_string std::char_traits, std::allocator > const&)':
> logger.cpp:(.text+0x694): undefined reference to
> `std::filesystem::status(std::filesystem::__cxx11::path const&)'
> src/common/libmtxcommon.a(logger.o): In function
> `mtx::log::file_target_c::file_target_c(std::filesystem::__cxx11::path)':
> logger.cpp:(.text+0xa08): undefined reference to
> `std::filesystem::__cxx11::path::_M_split_cmpts()'
> ...
Aja: You added the mkvtoolnix fix; has it worked in the passed?
I don't immediately know how to fix this, hence my open question to the
list instead.
Re: sparc64 bulk build report (openjade -O0 build to fix docbook-utils)
On Thu, Feb 17, 2022 at 11:27:14PM +, Klemens Nanni wrote: > > > I rebuilt it with DEBUG='-g3 -O0' and its debug- package enabled, but > > > that made docbook-utils build fine without segfault on sparc64... > > I decided to not waste more time on this (openjade has more probblems), > > but we can still "fix" it for sparc64 like this. > > Regen PLIST while here. > > Feedback? Objections? OK? > None so far. Unless anyone speaks up, I'll just commit this in a bit. ok kmos Verified to fix the build on sparc64. Thanks! --Kurt
Re: sparc64 bulk build report (fix ipmitool with ports-gcc)
On Fri, Feb 18, 2022 at 12:39:06AM +, Klemens Nanni wrote:
> base-gcc is older than -std=gnu11 which is hardcoded in configure.ac's
> CFLAGS.
> Feedback? OK?
I have confirmed this fixes it. ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/sysutils/ipmitool/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- Makefile 12 Feb 2022 18:14:43 - 1.32
> +++ Makefile 18 Feb 2022 00:31:40 -
> @@ -10,6 +10,7 @@ GH_ACCOUNT= ipmitool
> GH_PROJECT= ipmitool
> GH_COMMIT= 39ca56bf33975b8a8b7e87928d67dc66366161da
> DISTNAME=ipmitool-1.8.18pl20220207
> +REVISION=0
> DISTFILES= ${GH_DISTFILE} enterprise-numbers.20220204.gz:0
> EXTRACT_ONLY=${GH_DISTFILE:C/{.*//}
>
> @@ -26,6 +27,9 @@ MAINTAINER= Stuart Henderson PERMIT_PACKAGE= Yes
>
> WANTLIB= m curses edit crypto c
> +
> +# -std=gnu11
> +COMPILER = base-clang ports-gcc
>
> #MASTER_SITES=
> https://github.com/ipmitool/ipmitool/releases/download/IPMITOOL_${V:C/\./_/g}/
> MASTER_SITES0= https://spacehopper.org/mirrors/
>
Re: sparc64 bulk build report (fix ipmitool with ports-gcc)
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/sysutils/ipmitool.log
> checking for library containing readline... no
> configure: error: ** Unable to find readline required by ipmishell.
$ grep -C3 -e -ledit `make show=WRKBUILD`/config.log
| ;
| return 0;
| }
configure:14604: cc -std=gnu99 -o conftest -O2 -pipe -std=gnu11
-pedantic -Wformat -fms-extensions conftest.c -ledit >&5
cc1: error: unrecognized command line option "-std=gnu11"
configure:14604: $? = 1
configure: failed program was:
base-gcc is older than -std=gnu11 which is hardcoded in configure.ac's
CFLAGS.
Feedback? OK?
Index: Makefile
===
RCS file: /home/cvs/ports/sysutils/ipmitool/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile12 Feb 2022 18:14:43 - 1.32
+++ Makefile18 Feb 2022 00:31:40 -
@@ -10,6 +10,7 @@ GH_ACCOUNT= ipmitool
GH_PROJECT=ipmitool
GH_COMMIT= 39ca56bf33975b8a8b7e87928d67dc66366161da
DISTNAME= ipmitool-1.8.18pl20220207
+REVISION= 0
DISTFILES= ${GH_DISTFILE} enterprise-numbers.20220204.gz:0
EXTRACT_ONLY= ${GH_DISTFILE:C/{.*//}
@@ -26,6 +27,9 @@ MAINTAINER= Stuart Henderson https://github.com/ipmitool/ipmitool/releases/download/IPMITOOL_${V:C/\./_/g}/
MASTER_SITES0= https://spacehopper.org/mirrors/
Re: sparc64 bulk build report (openjade -O0 build to fix docbook-utils)
On Sat, Feb 12, 2022 at 11:05:56AM +, Klemens Nanni wrote:
> On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-09/textproc/docbook-utils.log
>
>
> I'm reposting my earlier mail here with proper subject to keep track.
> We already build some ports without optimiziations on sparc64, macppc
> and powerpc64 to "fix" things.
>
> OpenJade is old and just a leaf port, so not much interest from my side
> in chasing this bug...
>
> On Thu, Feb 10, 2022 at 09:40:30PM +, Klemens Nanni wrote:
> > On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote:
> > > http://build-failures.rhaalovely.net/sparc64/2022-02-06/textproc/docbook-utils.log
> >
> > > SGML_SEARCH_PATH=../..:../../doc:.. \
> > > jade -t sgml -i html -d ../../docbook-utils.dsl\#html \
> > > -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml
> > > Segmentation fault (core dumped)
> >
> > This is textproc/openjade segfaulting:
> >
> > #0 0x006f5aedf698 in Collector::Block::Block(Collector::Block*,
> > unsigned long, unsigned long, Collector::Object*) () from
> > /usr/local/lib/libostyle.so.0.0
> > #1 0x006f5aedfdb0 in Collector::makeSpace() () from
> > /usr/local/lib/libostyle.so.0.0
> > #2 0x006f5af36d54 in
> > OpenJade_DSSSL::Interpreter::convertNumber(OpenSP::String
> > const&, int) () from /usr/local/lib/libostyle.so.0.0
> > #3 0x006f5af4a710 in
> > OpenJade_DSSSL::SchemeParser::parseSelfEvaluating(unsigned int,
> > OpenJade_DSSSL::ELObj*&, OpenJade_DSSSL::SchemeParser::Token&) () from
> > /usr/local/lib/libostyle.so.0.0
> > #4 0x006f5af4a988 in OpenJade_DSSSL::SchemeParser::parseDatum(unsigned
> > int, OpenJade_DSSSL::ELObj*&, OpenSP::Location&,
> > OpenJade_DSSSL::SchemeParser::Token&) () from
> > /usr/local/lib/libostyle.so.0.0
> > #5 0x006f5af4fa50 in
> > OpenJade_DSSSL::SchemeParser::parseCase(OpenSP::Owner&)
> > () from /usr/local/lib/libostyle.so.0.0
> > #6 0x006f5af4c034 in
> > OpenJade_DSSSL::SchemeParser::parseExpression(unsigned int,
> > OpenSP::Owner&,
> > OpenJade_DSSSL::Identifier::SyntacticKey&,
> > OpenJade_DSSSL::SchemeParser::Token&) () from
> > /usr/local/lib/libostyle.so.0.0
> > #7 0x006f5af4f5a0 in
> > OpenJade_DSSSL::SchemeParser::parseBegin(OpenSP::Owner&)
> > () from /usr/local/lib/libostyle.so.0.0
> > #8 0x006f5af5145c in OpenJade_DSSSL::SchemeParser::doDefine() () from
> > /usr/local/lib/libostyle.so.0.0
> > #9 0x006f5af529f0 in OpenJade_DSSSL::SchemeParser::parse() () from
> > /usr/local/lib/libostyle.so.0.0
> > #10 0x006f5af58ca4 in
> > OpenJade_DSSSL::StyleEngine::parseSpec(OpenSP::SgmlParser&,
> > OpenSP::CharsetInfo const&, OpenSP::String const&,
> > OpenSP::Messenger&) () from /usr/local/lib/libostyle.so.0.0
> > #11 0x006f5aee1064 in OpenJade_DSSSL::DssslApp::processGrove() () from
> > /usr/local/lib/libostyle.so.0.0
> > #12 0x006f800b85e8 in
> > OpenSP::GroveApp::generateEvents(OpenSP::ErrorCountEventHandler*) () from
> > /usr/local/lib/libospgrove.so.0.0
> > #13 0x006fb7a0fd24 in
> > OpenSP::ParserApp::processSysid(OpenSP::String const&) ()
> > from /usr/local/lib/libosp.so.0.0
> > #14 0x006f5aee1484 in
> > OpenJade_DSSSL::DssslApp::processSysid(OpenSP::String const&)
> > () from /usr/local/lib/libostyle.so.0.0
> > #15 0x006fb79e1ccc in OpenSP::EntityApp::processArguments(int, char**)
> > () from /usr/local/lib/libosp.so.0.0
> > #16 0x006fb79cf408 in OpenSP::CmdLineApp::run(int, char**) () from
> > /usr/local/lib/libosp.so.0.0
> > #17 0x006d40a028a8 in main ()
> >
> > I rebuilt it with DEBUG='-g3 -O0' and its debug- package enabled, but
> > that made docbook-utils build fine without segfault on sparc64...
>
> I decided to not waste more time on this (openjade has more probblems),
> but we can still "fix" it for sparc64 like this.
>
> Regen PLIST while here.
>
> Feedback? Objections? OK?
None so far. Unless anyone speaks up, I'll just commit this in a bit.
>
> Index: textproc/docbook-utils/Makefile
> ===
> RCS file: /home/cvs/ports/textproc/docbook-utils/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- textproc/docbook-utils/Makefile 4 Sep 2021 12:23:48 - 1.2
> +++ textproc/docbook-utils/Makefile 11 Feb 2022 08:38:05 -
> @@ -3,7 +3,7 @@
> COMMENT= generates various output formats from DocBook SGML
> documents
>
> DISTNAME=docbook-utils-0.6.14
> -REVISION=0
> +REVISION=1
>
> CATEGORIES= textproc
>
> @@ -20,7 +20,7 @@ BUILD_DEPENDS= ${RUN_DEPENDS}
>
> RUN_DEPENDS= textproc/docbook \
> textproc/docbook-dsssl \
> - textproc/openjade
> + textproc/openjade>=1.3.3pre1p9
>
> CONFIGURE_STYLE= gnu
>
> Index:
Re: sparc64 bulk build report (fix compiler detection in openmsx)
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/emulators/openmsx.log
> eg++: error: unrecognized command line option '-fconstexpr-steps=200';
> did you mean '-fconstexpr-depth='?
> gmake: *** [build/main.mk:500: derived/sparc-openbsd-opt/obj/Autofire.cc.o]
> Error 1
main.mk looks at CXX to decide whether it is clang or gcc, which does
not work since we (always?) pass CXX=c++ which is then the usual symlink
in ${WRKDIR}/bin/ to CHOSEN_COMPILER.
So to fix this, just pass our choice and use that to decide.
I've verified that on amd64 this takes the base-clang path which uses
`-fconstexpr-steps=200' while on sparc64 the ports-gcc path is used
with avoids that flag.
We set `COMPILER=base-clang ports-gcc' so other cases cannot happen,
thus drop the old hunk that merely set the standard to C++11.
amd64 builds fine, no PLIST change.
sparc64 now also builds fine, no PLIST change.
Zap default python version while here.
Feedback? Objections? OK?
Index: Makefile
===
RCS file: /home/cvs/ports/emulators/openmsx/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- Makefile6 Aug 2021 08:02:10 - 1.31
+++ Makefile12 Feb 2022 12:19:25 -
@@ -7,6 +7,7 @@ BROKEN-alpha = OOM when building src/cpu
COMMENT = MSX home computer emulator
V =17.0
+REVISION = 0
DISTNAME = openmsx-$V
CATEGORIES = emulators
@@ -41,7 +42,6 @@ NO_TEST = Yes
MODULES = lang/python \
lang/tcl
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
MODPY_RUNDEP = No
MAKE_FILE =GNUmakefile
@@ -51,6 +51,7 @@ MAKE_FLAGS = CC="${CC}" \
CXX="${CXX}" \
CFLAGS="${CFLAGS}" \
CXXFLAGS="${CXXFLAGS}" \
+ CHOSEN_COMPILER=${CHOSEN_COMPILER} \
OPENMSX_STRIP=false \
V=1
Index: patches/patch-build_main_mk
===
RCS file: /home/cvs/ports/emulators/openmsx/patches/patch-build_main_mk,v
retrieving revision 1.4
diff -u -p -r1.4 patch-build_main_mk
--- patches/patch-build_main_mk 6 Aug 2021 08:02:10 - 1.4
+++ patches/patch-build_main_mk 12 Feb 2022 12:14:04 -
@@ -1,4 +1,8 @@
$OpenBSD: patch-build_main_mk,v 1.4 2021/08/06 08:02:10 mestre Exp $
+
+Fix compiler detection by using CHOSEN_COMPILER not CXX
+(ports-gcc does not know `-fconstexpr-steps`)
+
Index: build/main.mk
--- build/main.mk.orig
+++ build/main.mk
@@ -7,16 +11,16 @@ Index: build/main.mk
WINDRES?=windres
DEPEND_FLAGS:=
-ifneq ($(filter %clang++,$(CXX))$(filter clang++%,$(CXX)),)
-+ifneq ($(filter %clang++,$(CXX))$(filter clang++%,$(CXX))$(filter
c++,$(CXX)),)
++ifeq ($(CHOSEN_COMPILER),base-clang)
# Enable C++17 (for the most part supported since clang-5)
COMPILE_FLAGS+=-std=c++17 -fconstexpr-steps=200
COMPILE_FLAGS+=-Wall -Wextra -Wundef -Wno-invalid-offsetof -Wunused-macros
-Wdouble-promotion -Wmissing-declarations -Wshadow -Wold-style-cast
-Wzero-as-null-pointer-constant
-@@ -361,6 +361,8 @@ else
- else
- $(warning Unsupported compiler: $(CXX), please update Makefile)
- endif
-+ # Enable C++11
-+ COMPILE_FLAGS+=-std=c++11
- endif
- endif
-
+@@ -344,7 +344,7 @@ ifneq ($(filter %clang++,$(CXX))$(filter clang++%,$(CX
+ CC:=$(subst clang++,clang,$(CXX))
+ DEPEND_FLAGS+=-MP
+ else
+-ifneq ($(filter %g++,$(CXX))$(filter g++%,$(CXX))$(findstring /g++-,$(CXX)),)
++ifeq ($(CHOSEN_COMPILER),ports-gcc)
+ # Generic compilation flags.
+ COMPILE_FLAGS+=-pipe
+ # Enable C++17 (almost fully supported since gcc-7)
Re: sparc64 bulk build report (use ports-gcc to fix nzbget)
On Sat, Feb 12, 2022 at 12:32:07PM +, Stuart Henderson wrote: > This breaks the familiar "make patch; edit $somefile; make > update-patches" workflow and you have to fiddle with pre-subst > files instead. Or more likely, try to edit $somefile, run > update-patches, notice that it didn't pick up the changes, > then recreate them in pre-subst. So I don't like that part. Ah yes, thanks for the reminder.
Re: sparc64 bulk build report (use ports-gcc to fix nzbget)
On 2022/02/12 11:21, Klemens Nanni wrote:
> On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-09/news/nzbget.log
>
> > /tmp/PostScript-e00a4a.s:3155: Error: operation combines symbols in
> > different segments
> > clang-13: error: assembler command failed with exit code 1 (use -v to see
> > invocation)
>
> ports-gcc fixes this. Bump to sure in case this changes the compiler on
> an arch where ports-clang worked.
ok
> While here, substitute the config just once in post-patch. pre-configure
> would needlessly be rerun on every `make clean=build && make build'.
This breaks the familiar "make patch; edit $somefile; make
update-patches" workflow and you have to fiddle with pre-subst
files instead. Or more likely, try to edit $somefile, run
update-patches, notice that it didn't pick up the changes,
then recreate them in pre-subst. So I don't like that part.
> OK?
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/news/nzbget/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- Makefile 4 Jun 2021 03:18:47 - 1.5
> +++ Makefile 12 Feb 2022 11:08:36 -
> @@ -3,6 +3,7 @@
> COMMENT =binary newsreader supporting NZB files
>
> VERSION =21.1
> +REVISION = 0
> DISTNAME = nzbget-${VERSION}
>
> CATEGORIES = news
> @@ -20,7 +21,7 @@ MASTER_SITES = https://github.com/nzbget
> EXTRACT_SUFX = -src.tar.gz
>
> # C++14
> -COMPILER = base-clang ports-clang ports-gcc
> +COMPILER = base-clang ports-gcc
>
> RUN_DEPENDS =archivers/p7zip \
> archivers/unrar
> @@ -38,7 +39,7 @@ CONFIGURE_ARGS =--with-libcurses-includ
>
> NO_TEST =Yes
>
> -pre-configure:
> +post-patch:
> ${SUBST_CMD} ${WRKSRC}/nzbget.conf
>
> .include
>
Re: sparc64 bulk build report (use ports-gcc to fix nzbget)
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/news/nzbget.log
> /tmp/PostScript-e00a4a.s:3155: Error: operation combines symbols in different
> segments
> clang-13: error: assembler command failed with exit code 1 (use -v to see
> invocation)
ports-gcc fixes this. Bump to sure in case this changes the compiler on
an arch where ports-clang worked.
While here, substitute the config just once in post-patch. pre-configure
would needlessly be rerun on every `make clean=build && make build'.
OK?
Index: Makefile
===
RCS file: /home/cvs/ports/news/nzbget/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile4 Jun 2021 03:18:47 - 1.5
+++ Makefile12 Feb 2022 11:08:36 -
@@ -3,6 +3,7 @@
COMMENT = binary newsreader supporting NZB files
VERSION = 21.1
+REVISION = 0
DISTNAME = nzbget-${VERSION}
CATEGORIES = news
@@ -20,7 +21,7 @@ MASTER_SITES =https://github.com/nzbget
EXTRACT_SUFX = -src.tar.gz
# C++14
-COMPILER = base-clang ports-clang ports-gcc
+COMPILER = base-clang ports-gcc
RUN_DEPENDS = archivers/p7zip \
archivers/unrar
@@ -38,7 +39,7 @@ CONFIGURE_ARGS = --with-libcurses-includ
NO_TEST = Yes
-pre-configure:
+post-patch:
${SUBST_CMD} ${WRKSRC}/nzbget.conf
.include
Re: sparc64 bulk build report (openjade -O0 build to fix docbook-utils)
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-09/textproc/docbook-utils.log
I'm reposting my earlier mail here with proper subject to keep track.
We already build some ports without optimiziations on sparc64, macppc
and powerpc64 to "fix" things.
OpenJade is old and just a leaf port, so not much interest from my side
in chasing this bug...
On Thu, Feb 10, 2022 at 09:40:30PM +, Klemens Nanni wrote:
> On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-06/textproc/docbook-utils.log
>
> > SGML_SEARCH_PATH=../..:../../doc:.. \
> > jade -t sgml -i html -d ../../docbook-utils.dsl\#html \
> > -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml
> > Segmentation fault (core dumped)
>
> This is textproc/openjade segfaulting:
>
> #0 0x006f5aedf698 in Collector::Block::Block(Collector::Block*, unsigned
> long, unsigned long, Collector::Object*) () from
> /usr/local/lib/libostyle.so.0.0
> #1 0x006f5aedfdb0 in Collector::makeSpace() () from
> /usr/local/lib/libostyle.so.0.0
> #2 0x006f5af36d54 in
> OpenJade_DSSSL::Interpreter::convertNumber(OpenSP::String
> const&, int) () from /usr/local/lib/libostyle.so.0.0
> #3 0x006f5af4a710 in
> OpenJade_DSSSL::SchemeParser::parseSelfEvaluating(unsigned int,
> OpenJade_DSSSL::ELObj*&, OpenJade_DSSSL::SchemeParser::Token&) () from
> /usr/local/lib/libostyle.so.0.0
> #4 0x006f5af4a988 in OpenJade_DSSSL::SchemeParser::parseDatum(unsigned
> int, OpenJade_DSSSL::ELObj*&, OpenSP::Location&,
> OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0
> #5 0x006f5af4fa50 in
> OpenJade_DSSSL::SchemeParser::parseCase(OpenSP::Owner&)
> () from /usr/local/lib/libostyle.so.0.0
> #6 0x006f5af4c034 in
> OpenJade_DSSSL::SchemeParser::parseExpression(unsigned int,
> OpenSP::Owner&,
> OpenJade_DSSSL::Identifier::SyntacticKey&,
> OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0
> #7 0x006f5af4f5a0 in
> OpenJade_DSSSL::SchemeParser::parseBegin(OpenSP::Owner&)
> () from /usr/local/lib/libostyle.so.0.0
> #8 0x006f5af5145c in OpenJade_DSSSL::SchemeParser::doDefine() () from
> /usr/local/lib/libostyle.so.0.0
> #9 0x006f5af529f0 in OpenJade_DSSSL::SchemeParser::parse() () from
> /usr/local/lib/libostyle.so.0.0
> #10 0x006f5af58ca4 in
> OpenJade_DSSSL::StyleEngine::parseSpec(OpenSP::SgmlParser&,
> OpenSP::CharsetInfo const&, OpenSP::String const&,
> OpenSP::Messenger&) () from /usr/local/lib/libostyle.so.0.0
> #11 0x006f5aee1064 in OpenJade_DSSSL::DssslApp::processGrove() () from
> /usr/local/lib/libostyle.so.0.0
> #12 0x006f800b85e8 in
> OpenSP::GroveApp::generateEvents(OpenSP::ErrorCountEventHandler*) () from
> /usr/local/lib/libospgrove.so.0.0
> #13 0x006fb7a0fd24 in
> OpenSP::ParserApp::processSysid(OpenSP::String const&) () from
> /usr/local/lib/libosp.so.0.0
> #14 0x006f5aee1484 in
> OpenJade_DSSSL::DssslApp::processSysid(OpenSP::String const&)
> () from /usr/local/lib/libostyle.so.0.0
> #15 0x006fb79e1ccc in OpenSP::EntityApp::processArguments(int, char**) ()
> from /usr/local/lib/libosp.so.0.0
> #16 0x006fb79cf408 in OpenSP::CmdLineApp::run(int, char**) () from
> /usr/local/lib/libosp.so.0.0
> #17 0x006d40a028a8 in main ()
>
> I rebuilt it with DEBUG='-g3 -O0' and its debug- package enabled, but
> that made docbook-utils build fine without segfault on sparc64...
I decided to not waste more time on this (openjade has more probblems),
but we can still "fix" it for sparc64 like this.
Regen PLIST while here.
Feedback? Objections? OK?
Index: textproc/docbook-utils/Makefile
===
RCS file: /home/cvs/ports/textproc/docbook-utils/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- textproc/docbook-utils/Makefile 4 Sep 2021 12:23:48 - 1.2
+++ textproc/docbook-utils/Makefile 11 Feb 2022 08:38:05 -
@@ -3,7 +3,7 @@
COMMENT= generates various output formats from DocBook SGML
documents
DISTNAME= docbook-utils-0.6.14
-REVISION= 0
+REVISION= 1
CATEGORIES=textproc
@@ -20,7 +20,7 @@ BUILD_DEPENDS=${RUN_DEPENDS}
RUN_DEPENDS= textproc/docbook \
textproc/docbook-dsssl \
- textproc/openjade
+ textproc/openjade>=1.3.3pre1p9
CONFIGURE_STYLE= gnu
Index: textproc/docbook-utils/pkg/PLIST
===
RCS file: /home/cvs/ports/textproc/docbook-utils/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- textproc/docbook-utils/pkg/PLIST2 Sep 2021 20:14:58 - 1.1.1.1
+++ textproc/docbook-utils/pkg/PLIST
Re: sparc64 bulk build report (editors/scite fixed)
On Fri, Feb 11, 2022 at 09:40:12PM -0700, Kurt Mosiejczuk wrote: > http://build-failures.rhaalovely.net/sparc64/2022-02-09/editors/scite.log already fixed with ports-clang -> ports-gcc switch, just like scintilla.
Re: sparc64 bulk build report
On Fri, Feb 11, 2022 at 10:11:16AM +, Klemens Nanni wrote: > On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-02-06/net/kdeconnect-kde.log > > AutoGen: Parsing "BIN:/plugins/remotecontrol/plugin_remotecontrol_debug.h" > > Abort trap (core dumped) > No idea what fails, but I cannot reproduce it on the latest snap, > packages and ports tree. I'm noticing some things just abort trap but if you build them again they work fine. :| --Kurt
Re: sparc64 bulk build report
On Fri, Feb 11, 2022 at 09:43:35AM +, Klemens Nanni wrote: > On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-02-06/devel/boost.log > So how did we build a 1.78.0 release without this fix? > My sparc64 build with the latest snapshot and ports tree is currently > running. There was a patch from a previous test build of boost still in the tree. It has been fixed for the current run. --Kurt
Re: sparc64 bulk build report
On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > http://build-failures.rhaalovely.net/sparc64/2022-02-06/net/kdeconnect-kde.log > AutoGen: Parsing "BIN:/plugins/remotecontrol/plugin_remotecontrol_debug.h" > Abort trap (core dumped) No idea what fails, but I cannot reproduce it on the latest snap, packages and ports tree.
Re: sparc64 bulk build report
On Fri, Feb 11, 2022 at 11:03:45AM +0100, Theo Buehler wrote: > On Fri, Feb 11, 2022 at 09:43:35AM +, Klemens Nanni wrote: > > On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > > > http://build-failures.rhaalovely.net/sparc64/2022-02-06/devel/boost.log > > > > >FULLPKGNAME = boost-1.78.0v0 > > > > > ./boost/predef/architecture/sparc.h:37:38: error: missing ')' in > > > expression > > > # if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv9) || > > > defined(__sparc_v9__) > > > ^ > > > ./boost/predef/architecture/sparc.h:40:38: error: missing ')' in > > > expression > > > # if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv8) || > > > defined(__sparc_v8__) > > > ^ > > > > I'm confused, since looking at this file extracted from our port which > > says > > > > $ make show=FULLPKGNAME-main > > boost-1.78.0v0 > > > > it does *have* the missing ')': > > The build machine isn't clean. Thanks for checking! > > |$OpenBSD$ > | > |Fix missing parentheses that break sparc build > | > |Index: boost/predef/architecture/sparc.h > |--- boost/predef/architecture/sparc.h.orig > |+++ boost/predef/architecture/sparc.h > -- > Patching file boost/predef/architecture/sparc.h using Plan A... > Reversed (or previously applied) patch detected! Assume -R? [y] > Hunk #1 succeeded at 34. > done > ===> Applying OpenBSD patch > patch-libs_context_src_asm_jump_i386_sysv_elf_gas_S > Hmm... Looks like a unified diff to me... > The text leading up to this was: >
Re: sparc64 bulk build report
On Fri, Feb 11, 2022 at 09:43:35AM +, Klemens Nanni wrote: > On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-02-06/devel/boost.log > > > FULLPKGNAME = boost-1.78.0v0 > > > ./boost/predef/architecture/sparc.h:37:38: error: missing ')' in expression > > # if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv9) || > > defined(__sparc_v9__) > > ^ > > ./boost/predef/architecture/sparc.h:40:38: error: missing ')' in expression > > # if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv8) || > > defined(__sparc_v8__) > > ^ > > I'm confused, since looking at this file extracted from our port which > says > > $ make show=FULLPKGNAME-main > boost-1.78.0v0 > > it does *have* the missing ')': The build machine isn't clean. |$OpenBSD$ | |Fix missing parentheses that break sparc build | |Index: boost/predef/architecture/sparc.h |--- boost/predef/architecture/sparc.h.orig |+++ boost/predef/architecture/sparc.h -- Patching file boost/predef/architecture/sparc.h using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 34. done ===> Applying OpenBSD patch patch-libs_context_src_asm_jump_i386_sysv_elf_gas_S Hmm... Looks like a unified diff to me... The text leading up to this was:
Re: sparc64 bulk build report
On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > http://build-failures.rhaalovely.net/sparc64/2022-02-06/devel/boost.log >FULLPKGNAME = boost-1.78.0v0 > ./boost/predef/architecture/sparc.h:37:38: error: missing ')' in expression > # if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv9) || > defined(__sparc_v9__) > ^ > ./boost/predef/architecture/sparc.h:40:38: error: missing ')' in expression > # if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv8) || > defined(__sparc_v8__) > ^ I'm confused, since looking at this file extracted from our port which says $ make show=FULLPKGNAME-main boost-1.78.0v0 it does *have* the missing ')': $ cd `make show=WRKSRC` $ grep -n sparc_v ./boost/predef/architecture/sparc.h 27:| `+__sparc_v9__+` | 9.0.0 29:| `+__sparc_v8__+` | 8.0.0 37:# if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv9) || defined(__sparc_v9__)) 40:# if !defined(BOOST_ARCH_SPARC) && (defined(__sparcv8) || defined(__sparc_v8__)) which matches the upstream fix contained in 1.78.0: https://github.com/boostorg/boost/issues/532 https://github.com/boostorg/predef/commit/1be0e4a2d8db15a405f64a6f65507b87c1be7e1a So how did we build a 1.78.0 release without this fix? My sparc64 build with the latest snapshot and ports tree is currently running.
Re: sparc64 bulk build report
On Thu, Feb 10, 2022 at 09:40:30PM +, Klemens Nanni wrote:
> On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-06/textproc/docbook-utils.log
>
> > SGML_SEARCH_PATH=../..:../../doc:.. \
> > jade -t sgml -i html -d ../../docbook-utils.dsl\#html \
> > -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml
> > Segmentation fault (core dumped)
>
> This is textproc/openjade segfaulting:
>
> #0 0x006f5aedf698 in Collector::Block::Block(Collector::Block*, unsigned
> long, unsigned long, Collector::Object*) () from
> /usr/local/lib/libostyle.so.0.0
> #1 0x006f5aedfdb0 in Collector::makeSpace() () from
> /usr/local/lib/libostyle.so.0.0
> #2 0x006f5af36d54 in
> OpenJade_DSSSL::Interpreter::convertNumber(OpenSP::String
> const&, int) () from /usr/local/lib/libostyle.so.0.0
> #3 0x006f5af4a710 in
> OpenJade_DSSSL::SchemeParser::parseSelfEvaluating(unsigned int,
> OpenJade_DSSSL::ELObj*&, OpenJade_DSSSL::SchemeParser::Token&) () from
> /usr/local/lib/libostyle.so.0.0
> #4 0x006f5af4a988 in OpenJade_DSSSL::SchemeParser::parseDatum(unsigned
> int, OpenJade_DSSSL::ELObj*&, OpenSP::Location&,
> OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0
> #5 0x006f5af4fa50 in
> OpenJade_DSSSL::SchemeParser::parseCase(OpenSP::Owner&)
> () from /usr/local/lib/libostyle.so.0.0
> #6 0x006f5af4c034 in
> OpenJade_DSSSL::SchemeParser::parseExpression(unsigned int,
> OpenSP::Owner&,
> OpenJade_DSSSL::Identifier::SyntacticKey&,
> OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0
> #7 0x006f5af4f5a0 in
> OpenJade_DSSSL::SchemeParser::parseBegin(OpenSP::Owner&)
> () from /usr/local/lib/libostyle.so.0.0
> #8 0x006f5af5145c in OpenJade_DSSSL::SchemeParser::doDefine() () from
> /usr/local/lib/libostyle.so.0.0
> #9 0x006f5af529f0 in OpenJade_DSSSL::SchemeParser::parse() () from
> /usr/local/lib/libostyle.so.0.0
> #10 0x006f5af58ca4 in
> OpenJade_DSSSL::StyleEngine::parseSpec(OpenSP::SgmlParser&,
> OpenSP::CharsetInfo const&, OpenSP::String const&,
> OpenSP::Messenger&) () from /usr/local/lib/libostyle.so.0.0
> #11 0x006f5aee1064 in OpenJade_DSSSL::DssslApp::processGrove() () from
> /usr/local/lib/libostyle.so.0.0
> #12 0x006f800b85e8 in
> OpenSP::GroveApp::generateEvents(OpenSP::ErrorCountEventHandler*) () from
> /usr/local/lib/libospgrove.so.0.0
> #13 0x006fb7a0fd24 in
> OpenSP::ParserApp::processSysid(OpenSP::String const&) () from
> /usr/local/lib/libosp.so.0.0
> #14 0x006f5aee1484 in
> OpenJade_DSSSL::DssslApp::processSysid(OpenSP::String const&)
> () from /usr/local/lib/libostyle.so.0.0
> #15 0x006fb79e1ccc in OpenSP::EntityApp::processArguments(int, char**) ()
> from /usr/local/lib/libosp.so.0.0
> #16 0x006fb79cf408 in OpenSP::CmdLineApp::run(int, char**) () from
> /usr/local/lib/libosp.so.0.0
> #17 0x006d40a028a8 in main ()
>
> I rebuilt it with DEBUG='-g3 -O0' and its debug- package enabled, but
> that made docbook-utils build fine without segfault on sparc64...
I decided to not waste more time on this (openjade has more probblems),
but we can still "fix" it for sparc64 like this.
Regen PLIST while here.
Feedback? Objections? OK?
Index: textproc/docbook-utils/Makefile
===
RCS file: /home/cvs/ports/textproc/docbook-utils/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- textproc/docbook-utils/Makefile 4 Sep 2021 12:23:48 - 1.2
+++ textproc/docbook-utils/Makefile 11 Feb 2022 08:38:05 -
@@ -3,7 +3,7 @@
COMMENT= generates various output formats from DocBook SGML
documents
DISTNAME= docbook-utils-0.6.14
-REVISION= 0
+REVISION= 1
CATEGORIES=textproc
@@ -20,7 +20,7 @@ BUILD_DEPENDS=${RUN_DEPENDS}
RUN_DEPENDS= textproc/docbook \
textproc/docbook-dsssl \
- textproc/openjade
+ textproc/openjade>=1.3.3pre1p9
CONFIGURE_STYLE= gnu
Index: textproc/docbook-utils/pkg/PLIST
===
RCS file: /home/cvs/ports/textproc/docbook-utils/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- textproc/docbook-utils/pkg/PLIST2 Sep 2021 20:14:58 - 1.1.1.1
+++ textproc/docbook-utils/pkg/PLIST11 Feb 2022 08:44:24 -
@@ -40,8 +40,6 @@ share/doc/html/docbook-utils-0.6.14/intr
share/doc/html/docbook-utils-0.6.14/introduction.html
share/doc/html/docbook-utils-0.6.14/jw.html
share/doc/html/docbook-utils-0.6.14/sgmldiff.html
-share/sgml/
-share/sgml/docbook/
share/sgml/docbook/utils-0.6.14/
share/sgml/docbook/utils-0.6.14/backends/
share/sgml/docbook/utils-0.6.14/backends/dvi
Index:
Re: sparc64 bulk build report
On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote: > http://build-failures.rhaalovely.net/sparc64/2022-02-06/textproc/docbook-utils.log > SGML_SEARCH_PATH=../..:../../doc:.. \ > jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ > -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml > Segmentation fault (core dumped) This is textproc/openjade segfaulting: #0 0x006f5aedf698 in Collector::Block::Block(Collector::Block*, unsigned long, unsigned long, Collector::Object*) () from /usr/local/lib/libostyle.so.0.0 #1 0x006f5aedfdb0 in Collector::makeSpace() () from /usr/local/lib/libostyle.so.0.0 #2 0x006f5af36d54 in OpenJade_DSSSL::Interpreter::convertNumber(OpenSP::String const&, int) () from /usr/local/lib/libostyle.so.0.0 #3 0x006f5af4a710 in OpenJade_DSSSL::SchemeParser::parseSelfEvaluating(unsigned int, OpenJade_DSSSL::ELObj*&, OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0 #4 0x006f5af4a988 in OpenJade_DSSSL::SchemeParser::parseDatum(unsigned int, OpenJade_DSSSL::ELObj*&, OpenSP::Location&, OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0 #5 0x006f5af4fa50 in OpenJade_DSSSL::SchemeParser::parseCase(OpenSP::Owner&) () from /usr/local/lib/libostyle.so.0.0 #6 0x006f5af4c034 in OpenJade_DSSSL::SchemeParser::parseExpression(unsigned int, OpenSP::Owner&, OpenJade_DSSSL::Identifier::SyntacticKey&, OpenJade_DSSSL::SchemeParser::Token&) () from /usr/local/lib/libostyle.so.0.0 #7 0x006f5af4f5a0 in OpenJade_DSSSL::SchemeParser::parseBegin(OpenSP::Owner&) () from /usr/local/lib/libostyle.so.0.0 #8 0x006f5af5145c in OpenJade_DSSSL::SchemeParser::doDefine() () from /usr/local/lib/libostyle.so.0.0 #9 0x006f5af529f0 in OpenJade_DSSSL::SchemeParser::parse() () from /usr/local/lib/libostyle.so.0.0 #10 0x006f5af58ca4 in OpenJade_DSSSL::StyleEngine::parseSpec(OpenSP::SgmlParser&, OpenSP::CharsetInfo const&, OpenSP::String const&, OpenSP::Messenger&) () from /usr/local/lib/libostyle.so.0.0 #11 0x006f5aee1064 in OpenJade_DSSSL::DssslApp::processGrove() () from /usr/local/lib/libostyle.so.0.0 #12 0x006f800b85e8 in OpenSP::GroveApp::generateEvents(OpenSP::ErrorCountEventHandler*) () from /usr/local/lib/libospgrove.so.0.0 #13 0x006fb7a0fd24 in OpenSP::ParserApp::processSysid(OpenSP::String const&) () from /usr/local/lib/libosp.so.0.0 #14 0x006f5aee1484 in OpenJade_DSSSL::DssslApp::processSysid(OpenSP::String const&) () from /usr/local/lib/libostyle.so.0.0 #15 0x006fb79e1ccc in OpenSP::EntityApp::processArguments(int, char**) () from /usr/local/lib/libosp.so.0.0 #16 0x006fb79cf408 in OpenSP::CmdLineApp::run(int, char**) () from /usr/local/lib/libosp.so.0.0 #17 0x006d40a028a8 in main () I rebuilt it with DEBUG='-g3 -O0' and its debug- package enabled, but that made docbook-utils build fine without segfault on sparc64...
Re: sparc64 bulk build report
On Thu, Feb 10, 2022 at 08:06:14PM +, Klemens Nanni wrote:
> On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-02-06/editors/scintilla.log
> /tmp/Editor-6a96be.s: Assembler messages:
> /tmp/Editor-6a96be.s:45266: Error: operation combines symbols in
> different segments
> [same error multiple times]
> clang-13: error: assembler command failed with exit code 1 (use -v to
> see invocation)
> sparc64 is happy when building with ports-gcc, though.
ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/editors/scintilla/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile 14 Jul 2019 00:39:35 - 1.29
> +++ Makefile 10 Feb 2022 19:54:55 -
> @@ -3,6 +3,7 @@
> COMMENT= source code editing component for GTK+
>
> VERSION= 4.0.3
> +REVISION=0
> DISTNAME=scintilla${VERSION:S/.//g}
> PKGNAME= scintilla-${VERSION}
> CATEGORIES= editors x11
> @@ -30,7 +31,7 @@ MAKE_ENV= CXX='${CXX}' CXXFLAGS='${CXXFL
> WANTLIB= m ${COMPILER_LIBCXX}
>
> # -std=gnu++17
> -COMPILER=base-clang ports-clang ports-gcc
> +COMPILER=base-clang ports-gcc
>
> # Not LIB_DEPENDS as it's only shared libraries that don't link directly
> # to gtk+3
> Index: pkg/PLIST
> ===
> RCS file: /home/cvs/ports/editors/scintilla/pkg/PLIST,v
> retrieving revision 1.5
> diff -u -p -r1.5 PLIST
> --- pkg/PLIST 1 Nov 2017 17:01:23 - 1.5
> +++ pkg/PLIST 10 Feb 2022 20:03:25 -
> @@ -7,7 +7,7 @@ include/scintilla/SciLexer.h
> include/scintilla/Sci_Position.h
> include/scintilla/Scintilla.h
> include/scintilla/ScintillaWidget.h
> -lib/libscintilla.a
> +@static-lib lib/libscintilla.a
> @lib lib/libscintilla.so.${LIBscintilla_VERSION}
> -lib/libscintilla_lexers.a
> +@static-lib lib/libscintilla_lexers.a
> @lib lib/libscintilla_lexers.so.${LIBscintilla_lexers_VERSION}
>
Re: sparc64 bulk build report
On Tue, Feb 08, 2022 at 09:21:16PM -0700, Kurt Mosiejczuk wrote:
> http://build-failures.rhaalovely.net/sparc64/2022-02-06/editors/scintilla.log
/tmp/Editor-6a96be.s: Assembler messages:
/tmp/Editor-6a96be.s:45266: Error: operation combines symbols in
different segments
[same error multiple times]
clang-13: error: assembler command failed with exit code 1 (use -v to
see invocation)
sparc64 is happy when building with ports-gcc, though.
Index: Makefile
===
RCS file: /home/cvs/ports/editors/scintilla/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile14 Jul 2019 00:39:35 - 1.29
+++ Makefile10 Feb 2022 19:54:55 -
@@ -3,6 +3,7 @@
COMMENT= source code editing component for GTK+
VERSION= 4.0.3
+REVISION= 0
DISTNAME= scintilla${VERSION:S/.//g}
PKGNAME= scintilla-${VERSION}
CATEGORIES=editors x11
@@ -30,7 +31,7 @@ MAKE_ENV= CXX='${CXX}' CXXFLAGS='${CXXFL
WANTLIB= m ${COMPILER_LIBCXX}
# -std=gnu++17
-COMPILER= base-clang ports-clang ports-gcc
+COMPILER= base-clang ports-gcc
# Not LIB_DEPENDS as it's only shared libraries that don't link directly
# to gtk+3
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/editors/scintilla/pkg/PLIST,v
retrieving revision 1.5
diff -u -p -r1.5 PLIST
--- pkg/PLIST 1 Nov 2017 17:01:23 - 1.5
+++ pkg/PLIST 10 Feb 2022 20:03:25 -
@@ -7,7 +7,7 @@ include/scintilla/SciLexer.h
include/scintilla/Sci_Position.h
include/scintilla/Scintilla.h
include/scintilla/ScintillaWidget.h
-lib/libscintilla.a
+@static-lib lib/libscintilla.a
@lib lib/libscintilla.so.${LIBscintilla_VERSION}
-lib/libscintilla_lexers.a
+@static-lib lib/libscintilla_lexers.a
@lib lib/libscintilla_lexers.so.${LIBscintilla_lexers_VERSION}
Re: sparc64 bulk build report
On Tue, Jan 18, 2022 at 10:39 AM wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Sat Jan 15 15:24:01 MST 2022 > Finished: Tue Jan 18 11:36:52 MST 2022 > Duration: 2 Days 20 hours 13 minutes > > Built using OpenBSD 7.0-current (GENERIC.MP) #1147: Fri Jan 14 14:00:29 > MST 2022 > > Built 9414 packages > > Number of packages built each day: > Jan 15: 6094 > Jan 16: 1843 > Jan 17: 1321 > Jan 18: 156 > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2022-01-15/summary.log > > Build failures: 42 > http://build-failures.rhaalovely.net/sparc64/2022-01-15/lang/ruby/3.1.log This is due to __builtin_swap32 and __builtin_swap64 not being defined on sparc64, but Ruby thinking they should be defined due to the GCC version in use. I'm testing a patch to work around that and will commit it shortly. Thanks, Jeremy
Re: devel/avr/gcc sparc64 build fix (was: Re: sparc64 bulk build report)
On Tue, Jan 11, 2022 at 12:07:35AM +0100, Jeremie Courreges-Anglas wrote: > On Mon, Jan 10 2022, Tracey Emery wrote: > > On Mon, Jan 10, 2022 at 11:52:57AM -0700, k...@openbsd.org wrote: > >> Bulk build on sparc64-0a.ports.openbsd.org > >> > >> Started : Fri Jan 7 22:10:48 MST 2022 > >> http://build-failures.rhaalovely.net/sparc64/2022-01-07/devel/avr/gcc.log > > > > Pingish. This fixed avr for me the last time I tested and emailed. This > > is the same COMPILER config I need to use for the two xtensa ports I > > typically work on to build and work on sparc64. > > I found your last proposal, but some things have changed since. > Was your last try with devel/llvm>=13? > > Better make sure since I think there's a problem with ports-clang on > sparc64, and given this problem I'd rather not increase the use of > ports-clang in the tree, at least until we know better. Yeah, we'll have to hold off on this for now. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > -- Tracey Emery
Re: textprod/mupdf and COMPILER (was: Re: sparc64 bulk build report)
On 2022/01/10 22:51, Jeremie Courreges-Anglas wrote: > Since this now requires a C++ compiler (and a modern one) zap > COMPILER_LANGS and MODGCC4_ARCHS (the latter is outdated). > > Build-tested on sparc64. ok? OK. If the alignment problem on armv7 still exists then it may need this COMPILER = ports-gcc base-clang MODGCC4_ARCHS = armv7 (MODGCC4_ARCHS is not really outdated, it is the way we can restrict ports-gcc so that it's only used on specific archs. It's not needed very often though).
Re: net/neon missing libcrypto (was: Re: sparc64 bulk build report)
On Mon, Jan 10, 2022 at 11:20:17PM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Jan 05 2022, Stuart Henderson wrote:
> > Quite a few of the new sparc64 failures are related to neon:
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz.log
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz5.log
> >
> > /usr/local/lib/libneon.so.31.3: undefined reference to `EVP_sha512_256'
> >
> > This can be replicated on amd64 with USE_LLD=No
>
> Yep. For completeness, here are the related cc warnings:
> --8<--
> ne_openssl.c: In function 'hash_to_md':
> ne_openssl.c:1124:37: warning: implicit declaration of function
> 'EVP_sha512_256'; did you mean 'EVP_sha512'? [-Wimplicit-function-declaration]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~
> EVP_sha512
> ne_openssl.c:1124:37: warning: returning 'int' from a function with return
> type 'const EVP_MD *' {aka 'const struct env_md_st *'} makes pointer from
> integer without a cast [-Wint-conversion]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~~~
> ne_openssl.c: In function 'hash_to_md':
> ne_openssl.c:1124:37: warning: implicit declaration of function
> 'EVP_sha512_256'; did you mean 'EVP_sha512'? [-Wimplicit-function-declaration]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~
> EVP_sha512
> ne_openssl.c:1124:37: warning: returning 'int' from a function with return
> type 'const EVP_MD *' {aka 'const struct env_md_st *'} makes pointer from
> integer without a cast [-Wint-conversion]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~~~
> -->8--
>
>
> > Presumably this in src/ne_openssl.c:
> >
> > ...
> > | static const EVP_MD *hash_to_md(unsigned int flags)
> > | {
> > | switch (flags & NE_HASH_ALGMASK) {
> > | case NE_HASH_MD5: return EVP_md5();
> > | case NE_HASH_SHA256: return EVP_sha256();
> > | #ifdef HAVE_OPENSSL11
> > | case NE_HASH_SHA512: return EVP_sha512();
> > | case NE_HASH_SHA512_256: return EVP_sha512_256();
> > | #endif
> > ...
> >
> >
> > The others aren't explicit but I guess quite likely to have the same cause:
> >
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/net/cadaver.log
> >
> > configure: incompatible neon library version 0.32.1: wanted 0.27 28 29 30
> > 31 32
> >
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/16.log
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/18.log
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/19.log
> >
> > not clear from the build log but the module which isn't built depends on
> > neon;
> > config.log and/or menuselect-generated files probably tell more
> >
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/sysutils/nut.log
> >
> > "checking whether to build neon based XML driver... no"
> > config.log probably tells more
>
> All those probably have the same root cause indeed.
>
> Here's a diff that should get this port back on track.
> cc'ing tb@ for feedback for I suspect that adding those APIs is not
> a priority for now.
>
> ok?
OK.
Thanks!
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/neon/Makefile,v
> retrieving revision 1.48
> diff -u -p -r1.48 Makefile
> --- Makefile 30 Dec 2021 16:29:56 - 1.48
> +++ Makefile 10 Jan 2022 22:17:47 -
> @@ -3,6 +3,7 @@
> COMMENT= HTTP and WebDAV client library, with C interface
>
> DISTNAME=neon-0.32.1
> +REVISION=0
>
> SHARED_LIBS += neon 31.3 # 32.1
>
> Index: patches/patch-src_ne_openssl_c
> ===
> RCS file: patches/patch-src_ne_openssl_c
> diff -N patches/patch-src_ne_openssl_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_ne_openssl_c10 Jan 2022 22:18:37 -
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +LibreSSL does not provide EVP_sha512_256()
> +
> +Index: src/ne_openssl.c
> +--- src/ne_openssl.c.orig
> src/ne_openssl.c
> +@@ -1121,7 +1121,6 @@ static const EVP_MD *hash_to_md(unsigned int flags)
> + case NE_HASH_SHA256: return EVP_sha256();
> + #ifdef HAVE_OPENSSL11
> + case NE_HASH_SHA512: return EVP_sha512();
> +-case NE_HASH_SHA512_256: return EVP_sha512_256();
> + #endif
> + default: break;
> + }
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
--
Antoine
Fix libsigrokedecode libpython linking on sparc64 (was: Re: sparc64 bulk build report)
On Mon, Jan 10 2022, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
[...]
> http://build-failures.rhaalovely.net/sparc64/2022-01-07/comms/sigrok/pulseview.log
> http://build-failures.rhaalovely.net/sparc64/2022-01-07/comms/sigrok/sigrok-cli.log
Uses symbols from libsigrokedecode.so but doesn't link against it due to
a failure to detect python-3.9-embed. This is more visible on ld.bfd
archs but not specific to them, regress tests also fail to link on
ld.lld archs.
The diff below fixes the detection of libpython3.9 and also enables said
regress tests. ok?
Index: Makefile
===
RCS file: /home/cvs/ports/comms/sigrok/libsigrokdecode/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile2 Nov 2021 00:00:15 - 1.8
+++ Makefile11 Jan 2022 00:34:59 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.8 2021/11/02 00:00:15 sthen Exp $
COMMENT = sigrok protocol decoding library
-REVISION = 2
+REVISION = 3
SIGROK_PROJECT = libsigrokdecode
SIGROK_VERSION = 0.5.3
@@ -11,8 +11,12 @@ SHARED_LIBS += sigrokdecode
WANTLIB += glib-2.0 iconv intl m pcre pthread util ${MODPY_WANTLIB}
MODULES = lang/python
+BUILD_DEPENDS =devel/check
LIB_DEPENDS = devel/glib2
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+
+CONFIGURE_STYLE = autoconf
+AUTOCONF_VERSION = 2.69
.include
Index: patches/patch-configure_ac
===
RCS file: patches/patch-configure_ac
diff -N patches/patch-configure_ac
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-configure_ac 11 Jan 2022 00:35:13 -
@@ -0,0 +1,24 @@
+$OpenBSD$
+
+Add support for python-3.9
+
+Index: configure.ac
+--- configure.ac.orig
configure.ac
+@@ -93,14 +93,14 @@ SR_PKG_CHECK_SUMMARY([srd_pkglibs_summary])
+ # first, since usually only that variant will add "-lpython3.8".
+ #
https://docs.python.org/3/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
+ SR_PKG_CHECK([python3], [SRD_PKGLIBS],
+- [python-3.8-embed], [python-3.8 >= 3.8], [python-3.7 >= 3.7],
[python-3.6 >= 3.6], [python-3.5 >= 3.5], [python-3.4 >= 3.4], [python-3.3 >=
3.3], [python-3.2 >= 3.2], [python3 >= 3.2])
++ [python-3.9-embed], [python-3.9 >= 3.9], [python-3.8-embed],
[python-3.8 >= 3.8], [python-3.7 >= 3.7], [python-3.6 >= 3.6], [python-3.5 >=
3.5], [python-3.4 >= 3.4], [python-3.3 >= 3.3], [python-3.2 >= 3.2], [python3
>= 3.2])
+ AS_IF([test "x$sr_have_python3" = xno],
+ [AC_MSG_ERROR([Cannot find Python 3 development headers.])])
+
+ # We also need to find the name of the python3 executable (for 'make
install').
+ # Some OSes call this python3, some call it python3.2, etc. etc.
+ AC_ARG_VAR([PYTHON3], [Python 3 interpreter])
+-AC_CHECK_PROGS([PYTHON3], [python3.8 python3.7 python3.6 python3.5 python3.4
python3.3 python3.2 python3])
++AC_CHECK_PROGS([PYTHON3], [python3.9 python3.8 python3.7 python3.6 python3.5
python3.4 python3.3 python3.2 python3])
+ AS_IF([test "x$PYTHON3" = x],
+ [AC_MSG_ERROR([Cannot find Python 3 interpreter.])])
+
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: textprod/mupdf and COMPILER (was: Re: sparc64 bulk build report)
On Mon, Jan 10, 2022 at 10:51:12PM +0100, Jeremie Courreges-Anglas wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-01-07/textproc/mupdf.log > This one has happened since some time since Nov 13: > http://build-failures.rhaalovely.net/sparc64/2021-11-13/textproc/mupdf,js.log > > cc1plus: error: unrecognized command line option "-std=c++17" > Since this now requires a C++ compiler (and a modern one) zap > COMPILER_LANGS and MODGCC4_ARCHS (the latter is outdated). > Build-tested on sparc64. ok? ok kmos --Kurt > Index: Makefile > === > RCS file: /cvs/ports/textproc/mupdf/Makefile,v > retrieving revision 1.102 > diff -u -p -r1.102 Makefile > --- Makefile 13 Nov 2021 17:40:01 - 1.102 > +++ Makefile 10 Jan 2022 20:58:44 - > @@ -28,10 +28,7 @@ FLAVOR ?= > # http://git.ghostscript.com/?p=mupdf.git;a=summary > MASTER_SITES = https://mupdf.com/downloads/archive/ > > -# armv7: alignment issue > https://marc.info/?l=openbsd-ports=156448467232400=2 > -COMPILER =base-clang ports-gcc base-gcc > -COMPILER_LANGS = c > -MODGCC4_ARCHS = armv7 > +COMPILER =base-clang ports-gcc > > RUN_DEPENDS =devel/desktop-file-utils \ > devel/xdg-utils > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
Re: devel/avr/gcc sparc64 build fix (was: Re: sparc64 bulk build report)
On Tue, Jan 11, 2022 at 12:07:35AM +0100, Jeremie Courreges-Anglas wrote: > On Mon, Jan 10 2022, Tracey Emery wrote: > > On Mon, Jan 10, 2022 at 11:52:57AM -0700, k...@openbsd.org wrote: > >> Bulk build on sparc64-0a.ports.openbsd.org > >> > >> Started : Fri Jan 7 22:10:48 MST 2022 > >> http://build-failures.rhaalovely.net/sparc64/2022-01-07/devel/avr/gcc.log > > > > Pingish. This fixed avr for me the last time I tested and emailed. This > > is the same COMPILER config I need to use for the two xtensa ports I > > typically work on to build and work on sparc64. > > I found your last proposal, but some things have changed since. > Was your last try with devel/llvm>=13? > > Better make sure since I think there's a problem with ports-clang on > sparc64, and given this problem I'd rather not increase the use of > ports-clang in the tree, at least until we know better. > I thought it was, but I'll test again tomorrow. > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE -- Tracey Emery
devel/avr/gcc sparc64 build fix (was: Re: sparc64 bulk build report)
On Mon, Jan 10 2022, Tracey Emery wrote: > On Mon, Jan 10, 2022 at 11:52:57AM -0700, k...@openbsd.org wrote: >> Bulk build on sparc64-0a.ports.openbsd.org >> >> Started : Fri Jan 7 22:10:48 MST 2022 >> http://build-failures.rhaalovely.net/sparc64/2022-01-07/devel/avr/gcc.log > > Pingish. This fixed avr for me the last time I tested and emailed. This > is the same COMPILER config I need to use for the two xtensa ports I > typically work on to build and work on sparc64. I found your last proposal, but some things have changed since. Was your last try with devel/llvm>=13? Better make sure since I think there's a problem with ports-clang on sparc64, and given this problem I'd rather not increase the use of ports-clang in the tree, at least until we know better. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sparc64 bulk build report
On Mon, Jan 10, 2022 at 11:52:57AM -0700, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Fri Jan 7 22:10:48 MST 2022
> http://build-failures.rhaalovely.net/sparc64/2022-01-07/devel/avr/gcc.log
Pingish. This fixed avr for me the last time I tested and emailed. This
is the same COMPILER config I need to use for the two xtensa ports I
typically work on to build and work on sparc64.
--
Tracey Emery
Index: gcc/Makefile
===
RCS file: /cvs/ports/devel/avr/gcc/Makefile,v
retrieving revision 1.38
diff -u -r1.38 Makefile
--- gcc/Makefile20 Nov 2021 15:04:38 - 1.38
+++ gcc/Makefile22 Nov 2021 22:43:43 -
@@ -5,14 +5,15 @@
V= 8.5.0
DISTNAME = gcc-$V
PKGNAME= avr-gcc-${V}
-REVISION= 0
+REVISION= 1
# GPLv3
PERMIT_PACKAGE=Yes
WANTLIB= c gmp mpfr ${COMPILER_LIBCXX} m mpc
-COMPILER = base-clang ports-gcc base-gcc
+# fix build on sparc64
+COMPILER = base-clang ports-clang
MASTER_SITES= ${MASTER_SITE_GCC:=releases/gcc-$(V)/}
EXTRACT_SUFX= .tar.xz
Re: net/neon missing libcrypto (was: Re: sparc64 bulk build report)
On Mon, Jan 10, 2022 at 11:20:17PM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Jan 05 2022, Stuart Henderson wrote:
> > Quite a few of the new sparc64 failures are related to neon:
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz.log
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz5.log
> >
> > /usr/local/lib/libneon.so.31.3: undefined reference to `EVP_sha512_256'
> >
> > This can be replicated on amd64 with USE_LLD=No
>
> Yep. For completeness, here are the related cc warnings:
> --8<--
> ne_openssl.c: In function 'hash_to_md':
> ne_openssl.c:1124:37: warning: implicit declaration of function
> 'EVP_sha512_256'; did you mean 'EVP_sha512'? [-Wimplicit-function-declaration]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~
> EVP_sha512
> ne_openssl.c:1124:37: warning: returning 'int' from a function with return
> type 'const EVP_MD *' {aka 'const struct env_md_st *'} makes pointer from
> integer without a cast [-Wint-conversion]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~~~
> ne_openssl.c: In function 'hash_to_md':
> ne_openssl.c:1124:37: warning: implicit declaration of function
> 'EVP_sha512_256'; did you mean 'EVP_sha512'? [-Wimplicit-function-declaration]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~
> EVP_sha512
> ne_openssl.c:1124:37: warning: returning 'int' from a function with return
> type 'const EVP_MD *' {aka 'const struct env_md_st *'} makes pointer from
> integer without a cast [-Wint-conversion]
> case NE_HASH_SHA512_256: return EVP_sha512_256();
> ^~~~
> -->8--
>
>
> > Presumably this in src/ne_openssl.c:
> >
> > ...
> > | static const EVP_MD *hash_to_md(unsigned int flags)
> > | {
> > | switch (flags & NE_HASH_ALGMASK) {
> > | case NE_HASH_MD5: return EVP_md5();
> > | case NE_HASH_SHA256: return EVP_sha256();
> > | #ifdef HAVE_OPENSSL11
> > | case NE_HASH_SHA512: return EVP_sha512();
> > | case NE_HASH_SHA512_256: return EVP_sha512_256();
> > | #endif
> > ...
> >
> >
> > The others aren't explicit but I guess quite likely to have the same cause:
> >
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/net/cadaver.log
> >
> > configure: incompatible neon library version 0.32.1: wanted 0.27 28 29 30
> > 31 32
> >
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/16.log
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/18.log
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/19.log
> >
> > not clear from the build log but the module which isn't built depends on
> > neon;
> > config.log and/or menuselect-generated files probably tell more
> >
> >> http://build-failures.rhaalovely.net/sparc64/2022-01-03/sysutils/nut.log
> >
> > "checking whether to build neon based XML driver... no"
> > config.log probably tells more
>
> All those probably have the same root cause indeed.
>
> Here's a diff that should get this port back on track.
> cc'ing tb@ for feedback for I suspect that adding those APIs is not
> a priority for now.
It's not indeed. Noted.
>
> ok?
Yes, ok
>
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/neon/Makefile,v
> retrieving revision 1.48
> diff -u -p -r1.48 Makefile
> --- Makefile 30 Dec 2021 16:29:56 - 1.48
> +++ Makefile 10 Jan 2022 22:17:47 -
> @@ -3,6 +3,7 @@
> COMMENT= HTTP and WebDAV client library, with C interface
>
> DISTNAME=neon-0.32.1
> +REVISION=0
>
> SHARED_LIBS += neon 31.3 # 32.1
>
> Index: patches/patch-src_ne_openssl_c
> ===
> RCS file: patches/patch-src_ne_openssl_c
> diff -N patches/patch-src_ne_openssl_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_ne_openssl_c10 Jan 2022 22:18:37 -
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +LibreSSL does not provide EVP_sha512_256()
> +
> +Index: src/ne_openssl.c
> +--- src/ne_openssl.c.orig
> src/ne_openssl.c
> +@@ -1121,7 +1121,6 @@ static const EVP_MD *hash_to_md(unsigned int flags)
> + case NE_HASH_SHA256: return EVP_sha256();
> + #ifdef HAVE_OPENSSL11
> + case NE_HASH_SHA512: return EVP_sha512();
> +-case NE_HASH_SHA512_256: return EVP_sha512_256();
> + #endif
> + default: break;
> + }
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
net/neon missing libcrypto (was: Re: sparc64 bulk build report)
On Wed, Jan 05 2022, Stuart Henderson wrote:
> Quite a few of the new sparc64 failures are related to neon:
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz.log
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz5.log
>
> /usr/local/lib/libneon.so.31.3: undefined reference to `EVP_sha512_256'
>
> This can be replicated on amd64 with USE_LLD=No
Yep. For completeness, here are the related cc warnings:
--8<--
ne_openssl.c: In function 'hash_to_md':
ne_openssl.c:1124:37: warning: implicit declaration of function
'EVP_sha512_256'; did you mean 'EVP_sha512'? [-Wimplicit-function-declaration]
case NE_HASH_SHA512_256: return EVP_sha512_256();
^~
EVP_sha512
ne_openssl.c:1124:37: warning: returning 'int' from a function with return type
'const EVP_MD *' {aka 'const struct env_md_st *'} makes pointer from integer
without a cast [-Wint-conversion]
case NE_HASH_SHA512_256: return EVP_sha512_256();
^~~~
ne_openssl.c: In function 'hash_to_md':
ne_openssl.c:1124:37: warning: implicit declaration of function
'EVP_sha512_256'; did you mean 'EVP_sha512'? [-Wimplicit-function-declaration]
case NE_HASH_SHA512_256: return EVP_sha512_256();
^~
EVP_sha512
ne_openssl.c:1124:37: warning: returning 'int' from a function with return type
'const EVP_MD *' {aka 'const struct env_md_st *'} makes pointer from integer
without a cast [-Wint-conversion]
case NE_HASH_SHA512_256: return EVP_sha512_256();
^~~~
-->8--
> Presumably this in src/ne_openssl.c:
>
> ...
> | static const EVP_MD *hash_to_md(unsigned int flags)
> | {
> | switch (flags & NE_HASH_ALGMASK) {
> | case NE_HASH_MD5: return EVP_md5();
> | case NE_HASH_SHA256: return EVP_sha256();
> | #ifdef HAVE_OPENSSL11
> | case NE_HASH_SHA512: return EVP_sha512();
> | case NE_HASH_SHA512_256: return EVP_sha512_256();
> | #endif
> ...
>
>
> The others aren't explicit but I guess quite likely to have the same cause:
>
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/net/cadaver.log
>
> configure: incompatible neon library version 0.32.1: wanted 0.27 28 29 30 31
> 32
>
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/16.log
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/18.log
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/19.log
>
> not clear from the build log but the module which isn't built depends on neon;
> config.log and/or menuselect-generated files probably tell more
>
>> http://build-failures.rhaalovely.net/sparc64/2022-01-03/sysutils/nut.log
>
> "checking whether to build neon based XML driver... no"
> config.log probably tells more
All those probably have the same root cause indeed.
Here's a diff that should get this port back on track.
cc'ing tb@ for feedback for I suspect that adding those APIs is not
a priority for now.
ok?
Index: Makefile
===
RCS file: /home/cvs/ports/net/neon/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile30 Dec 2021 16:29:56 - 1.48
+++ Makefile10 Jan 2022 22:17:47 -
@@ -3,6 +3,7 @@
COMMENT= HTTP and WebDAV client library, with C interface
DISTNAME= neon-0.32.1
+REVISION= 0
SHARED_LIBS += neon 31.3 # 32.1
Index: patches/patch-src_ne_openssl_c
===
RCS file: patches/patch-src_ne_openssl_c
diff -N patches/patch-src_ne_openssl_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_ne_openssl_c 10 Jan 2022 22:18:37 -
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+LibreSSL does not provide EVP_sha512_256()
+
+Index: src/ne_openssl.c
+--- src/ne_openssl.c.orig
src/ne_openssl.c
+@@ -1121,7 +1121,6 @@ static const EVP_MD *hash_to_md(unsigned int flags)
+ case NE_HASH_SHA256: return EVP_sha256();
+ #ifdef HAVE_OPENSSL11
+ case NE_HASH_SHA512: return EVP_sha512();
+-case NE_HASH_SHA512_256: return EVP_sha512_256();
+ #endif
+ default: break;
+ }
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
textprod/mupdf and COMPILER (was: Re: sparc64 bulk build report)
On Mon, Jan 10 2022, k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Fri Jan 7 22:10:48 MST 2022 > Finished: Mon Jan 10 11:52:16 MST 2022 > Duration: 2 Days 13 hours 41 minutes > > Built using OpenBSD 7.0-current (GENERIC.MP) #1136: Fri Jan 7 16:48:03 MST > 2022 > > Built 9067 packages > > Number of packages built each day: > Jan 7: 3761 > Jan 8: 4010 > Jan 9: 1070 > Jan 10: 226 [...] > http://build-failures.rhaalovely.net/sparc64/2022-01-07/textproc/mupdf.log This one has happened since some time since Nov 13: http://build-failures.rhaalovely.net/sparc64/2021-11-13/textproc/mupdf,js.log > cc1plus: error: unrecognized command line option "-std=c++17" Since this now requires a C++ compiler (and a modern one) zap COMPILER_LANGS and MODGCC4_ARCHS (the latter is outdated). Build-tested on sparc64. ok? Index: Makefile === RCS file: /cvs/ports/textproc/mupdf/Makefile,v retrieving revision 1.102 diff -u -p -r1.102 Makefile --- Makefile13 Nov 2021 17:40:01 - 1.102 +++ Makefile10 Jan 2022 20:58:44 - @@ -28,10 +28,7 @@ FLAVOR ?= # http://git.ghostscript.com/?p=mupdf.git;a=summary MASTER_SITES = https://mupdf.com/downloads/archive/ -# armv7: alignment issue https://marc.info/?l=openbsd-ports=156448467232400=2 -COMPILER = base-clang ports-gcc base-gcc -COMPILER_LANGS = c -MODGCC4_ARCHS = armv7 +COMPILER = base-clang ports-gcc RUN_DEPENDS = devel/desktop-file-utils \ devel/xdg-utils -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sparc64 bulk build report
On Wed, Jan 05, 2022 at 02:18:35PM -0700, Kurt Mosiejczuk wrote: > http://build-failures.rhaalovely.net/sparc64/2022-01-03/graphics/qr-code-generator.log Fixed. This was a bug in our hand-rolled cc/c++ lines that caused it to always build with base cc/c++; C++11 and base c++ 4.2.1 from 2007 don't go well together.
Re: sparc64 bulk build report
Quite a few of the new sparc64 failures are related to neon:
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz.log
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/audio/libmusicbrainz5.log
/usr/local/lib/libneon.so.31.3: undefined reference to `EVP_sha512_256'
This can be replicated on amd64 with USE_LLD=No
Presumably this in src/ne_openssl.c:
...
| static const EVP_MD *hash_to_md(unsigned int flags)
| {
| switch (flags & NE_HASH_ALGMASK) {
| case NE_HASH_MD5: return EVP_md5();
| case NE_HASH_SHA256: return EVP_sha256();
| #ifdef HAVE_OPENSSL11
| case NE_HASH_SHA512: return EVP_sha512();
| case NE_HASH_SHA512_256: return EVP_sha512_256();
| #endif
...
The others aren't explicit but I guess quite likely to have the same cause:
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/net/cadaver.log
configure: incompatible neon library version 0.32.1: wanted 0.27 28 29 30 31 32
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/16.log
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/18.log
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/telephony/asterisk/19.log
not clear from the build log but the module which isn't built depends on neon;
config.log and/or menuselect-generated files probably tell more
> http://build-failures.rhaalovely.net/sparc64/2022-01-03/sysutils/nut.log
"checking whether to build neon based XML driver... no"
config.log probably tells more
Re: sparc64 bulk build report
> http://build-failures.rhaalovely.net/sparc64/2021-12-18/math/cglm.log > /usr/obj/ports/cglm-0.8.4/cglm-0.8.4/test/src/test_cam_lh_zo.c: In function > 'test_perspective_lh_zo': > /usr/obj/ports/cglm-0.8.4/cglm-0.8.4/test/src/test_cam_lh_zo.c:28: warning: > missing braces around initializer > /usr/obj/ports/cglm-0.8.4/cglm-0.8.4/test/src/test_cam_lh_zo.c:28: warning: > (near initialization for 'cmp[0]') it fails also on aarch64 for a similar reason (unused but set variable.) This missing braces around initializer could be patched easily (althought I can't reproduce here), but the aarch64 failure doesn't seem obvious so I'd prefer to disable -Werror and let the package build. I'll commit the following in a few days if nobody objects Index: Makefile === RCS file: /home/cvs/ports/math/cglm/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile10 Dec 2021 13:27:02 - 1.1.1.1 +++ Makefile21 Dec 2021 22:51:39 - @@ -2,6 +2,7 @@ COMMENT = highly optimized graphics math library +REVISION = 0 GH_ACCOUNT = recp GH_PROJECT = cglm GH_TAGNAME = v0.8.4 Index: patches/patch-CMakeLists_txt === RCS file: /home/cvs/ports/math/cglm/patches/patch-CMakeLists_txt,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 patch-CMakeLists_txt --- patches/patch-CMakeLists_txt10 Dec 2021 13:27:02 - 1.1.1.1 +++ patches/patch-CMakeLists_txt21 Dec 2021 22:51:26 - @@ -1,6 +1,6 @@ $OpenBSD: patch-CMakeLists_txt,v 1.1.1.1 2021/12/10 13:27:02 op Exp $ - - don't hardcode optimization flags + - don't hardcode optimization flags and drop -Werror - set PACKAGE_VERSION for cglm.pc.in Index: CMakeLists.txt @@ -11,7 +11,7 @@ Index: CMakeLists.txt endforeach(flag_var) else() - add_compile_options(-Wall -Werror -O3) -+ add_compile_options(-Wall -Werror) ++ add_compile_options(-Wall) endif() if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
Re: sparc64 bulk build report
On Tue, Dec 07, 2021 at 05:28:37AM -0700, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Sat Dec 4 15:08:37 MST 2021
> Finished: Tue Dec 7 05:28:00 MST 2021
> Duration: 2 Days 14 hours 19 minutes
>
> Built using OpenBSD 7.0-current (GENERIC.MP) #1083: Thu Dec 2 13:20:47 MST
> 2021
[...]
> http://build-failures.rhaalovely.net/sparc64/2021-12-04/games/vkquake.log
cc -DNDEBUG -c -O2 -pipe -std=c99 -Wall -Wno-trigraphs -Werror -std=gnu99
-fweb -frename-registers -DDO_USERDIRS=1 -DUSE_CODEC_WAVE -DUSE_CODEC_VORBIS
-DUSE_CODEC_MP3 -DLINUX -I/usr/local/include -I/usr/local/include/SDL2
-I/usr/X11R6/include -D_REENTRANT -I/usr/X11R6/include -o gl_draw.o gl_draw.c
cc1: warnings being treated as errors
gl_draw.c: In function 'Draw_PicFromWad2':
gl_draw.c:285: warning: array size (4) smaller than bound length (24)
I don't think this port needs -Werror. Diff below should let this build
on sparc64 again.
Planning to commit this if no concerns, or if I get an ok.
Index: Makefile
===
RCS file: /cvs/ports/games/vkquake/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile29 Nov 2021 06:40:43 - 1.8
+++ Makefile10 Dec 2021 23:15:58 -
@@ -7,6 +7,7 @@ PKGNAME = vkquake-${V}
GH_ACCOUNT = Novum
GH_PROJECT = vkQuake
GH_TAGNAME = ${V}
+REVISION = 0
CATEGORIES = games x11
MAINTAINER = Thomas Frohwein
Index: patches/patch-Quake_Makefile
===
RCS file: /cvs/ports/games/vkquake/patches/patch-Quake_Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 patch-Quake_Makefile
--- patches/patch-Quake_Makefile29 Nov 2021 06:40:43 - 1.3
+++ patches/patch-Quake_Makefile10 Dec 2021 23:15:58 -
@@ -1,10 +1,20 @@
$OpenBSD: patch-Quake_Makefile,v 1.3 2021/11/29 06:40:43 thfr Exp $
remove hardcoded optimization flag
+remove -Werror (warnings on sparc64 build)
Index: Quake/Makefile
--- Quake/Makefile.orig
+++ Quake/Makefile
+@@ -48,7 +48,7 @@ STRIP ?= strip
+ CPUFLAGS=
+ DFLAGS ?=
+ CFLAGS ?=
+-CFLAGS += -Wall -Wno-trigraphs -Werror -std=gnu99
++CFLAGS += -Wall -Wno-trigraphs -std=gnu99
+ CFLAGS += $(CPUFLAGS)
+ ifneq ($(DEBUG),0)
+ DFLAGS += -D_DEBUG
@@ -56,7 +56,6 @@ CFLAGS += -g
do_strip=
else
Re: sparc64 bulk build report
On Thu, Dec 02, 2021 at 12:38:10PM +0300, Kirill Bychkov wrote:
> On Mon, November 29, 2021 11:04, k...@openbsd.org wrote:
> > Bulk build on sparc64-0a.ports.openbsd.org
> >
> > Started : Fri Nov 26 16:32:18 MST 2021
> > Finished: Mon Nov 29 01:04:37 MST 2021
> > Duration: 2 Days 8 hours 32 minutes
> >
> > Built using OpenBSD 7.0-current (GENERIC.MP) #1070: Thu Nov 25 01:09:21 MST
> > 2021
> > http://build-failures.rhaalovely.net/sparc64/2021-11-26/devel/vte3.log
> Hi!
> According to meson.build it requires newer GCC for gnu c++20 extensions:
> c_req_std = 'gnu11'
> cxx_req_std = 'gnu++20'
> gxx_req_version = '10.0'
> clangxx_req_version = '11.0'
> Switching default compiler to ports-clang fixes build.
> Some consumers build tested. It takes too much time on my Netra :(
> OK?
ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/vte3/Makefile,v
> retrieving revision 1.111
> diff -u -p -u -r1.111 Makefile
> --- Makefile26 Oct 2021 10:36:48 - 1.111
> +++ Makefile2 Dec 2021 09:29:51 -
> @@ -26,7 +26,7 @@ WANTLIB += ${COMPILER_LIBCXX}
> MODULES= devel/meson \
> x11/gnome
>
> -COMPILER = base-clang ports-gcc
> +COMPILER = base-clang ports-clang
>
> DEBUG_PACKAGES = ${BUILD_PACKAGES}
>
>
>
Re: sparc64 bulk build report
On 2021/12/02 12:38, Kirill Bychkov wrote:
> On Mon, November 29, 2021 11:04, k...@openbsd.org wrote:
> > Bulk build on sparc64-0a.ports.openbsd.org
> >
> > Started : Fri Nov 26 16:32:18 MST 2021
> > Finished: Mon Nov 29 01:04:37 MST 2021
> > Duration: 2 Days 8 hours 32 minutes
> >
> > Built using OpenBSD 7.0-current (GENERIC.MP) #1070: Thu Nov 25 01:09:21 MST
> > 2021
>
> > http://build-failures.rhaalovely.net/sparc64/2021-11-26/devel/vte3.log
>
> Hi!
> According to meson.build it requires newer GCC for gnu c++20 extensions:
> c_req_std = 'gnu11'
> cxx_req_std = 'gnu++20'
> gxx_req_version = '10.0'
> clangxx_req_version = '11.0'
>
> Switching default compiler to ports-clang fixes build.
> Some consumers build tested. It takes too much time on my Netra :(
> OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/vte3/Makefile,v
> retrieving revision 1.111
> diff -u -p -u -r1.111 Makefile
> --- Makefile26 Oct 2021 10:36:48 - 1.111
> +++ Makefile2 Dec 2021 09:29:51 -
> @@ -26,7 +26,7 @@ WANTLIB += ${COMPILER_LIBCXX}
> MODULES= devel/meson \
> x11/gnome
>
Please add a "# C++20" comment here
> -COMPILER = base-clang ports-gcc
> +COMPILER = base-clang ports-clang
>
> DEBUG_PACKAGES = ${BUILD_PACKAGES}
>
>
>
ok
Re: sparc64 bulk build report
k...@openbsd.org writes: > http://build-failures.rhaalovely.net/sparc64/2021-11-26/databases/pspg.log > cc -c src/args.c -o args.o -I/usr/local/include/ereadline [...] > src/args.c: In function 'print_versions': > src/args.c:262: error: '__SIZEOF_WCHAR_T__' undeclared (first use in this > function) > src/args.c:262: error: (Each undeclared identifier is reported only once > src/args.c:262: error: for each function it appears in.) something like this is enough to build it (it's the only occurrence of __SIZEOF_WCHAR_T__) or do we need to change COMPILER to `base-clang ports-gcc'? Index: Makefile === RCS file: /home/cvs/ports/databases/pspg/Makefile,v retrieving revision 1.3 diff -u -p -r1.3 Makefile --- Makefile8 Nov 2021 15:00:15 - 1.3 +++ Makefile2 Dec 2021 10:25:15 - @@ -5,6 +5,7 @@ COMMENT = UNIX pager optimized for tabul GH_ACCOUNT = okbob GH_PROJECT = pspg GH_TAGNAME = 5.5.1 +REVISION = 0 CATEGORIES = databases Index: patches/patch-src_args_c === RCS file: patches/patch-src_args_c diff -N patches/patch-src_args_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_args_c2 Dec 2021 10:11:57 - @@ -0,0 +1,14 @@ +$OpenBSD$ + +Index: src/args.c +--- src/args.c.orig src/args.c +@@ -259,7 +259,7 @@ print_versions(void) + + #endif + +- fprintf(stdout, "wchar_t width: %d, max: %d\n", __SIZEOF_WCHAR_T__, __WCHAR_MAX__); ++ fprintf(stdout, "wchar_t width: %d, max: %d\n", sizeof(wchar_t), __WCHAR_MAX__); + + #ifdef HAVE_POSTGRESQL +
Re: sparc64 bulk build report
On Mon, November 29, 2021 11:04, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Fri Nov 26 16:32:18 MST 2021
> Finished: Mon Nov 29 01:04:37 MST 2021
> Duration: 2 Days 8 hours 32 minutes
>
> Built using OpenBSD 7.0-current (GENERIC.MP) #1070: Thu Nov 25 01:09:21 MST
> 2021
> http://build-failures.rhaalovely.net/sparc64/2021-11-26/devel/vte3.log
Hi!
According to meson.build it requires newer GCC for gnu c++20 extensions:
c_req_std = 'gnu11'
cxx_req_std = 'gnu++20'
gxx_req_version = '10.0'
clangxx_req_version = '11.0'
Switching default compiler to ports-clang fixes build.
Some consumers build tested. It takes too much time on my Netra :(
OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/vte3/Makefile,v
retrieving revision 1.111
diff -u -p -u -r1.111 Makefile
--- Makefile26 Oct 2021 10:36:48 - 1.111
+++ Makefile2 Dec 2021 09:29:51 -
@@ -26,7 +26,7 @@ WANTLIB += ${COMPILER_LIBCXX}
MODULES= devel/meson \
x11/gnome
-COMPILER = base-clang ports-gcc
+COMPILER = base-clang ports-clang
DEBUG_PACKAGES = ${BUILD_PACKAGES}
Re: sparc64 bulk build report
On Thu, Nov 25, 2021 at 04:27:02PM +0300, Kirill Bychkov wrote: > On Sun, November 21, 2021 07:39, k...@openbsd.org wrote: > > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Thu Nov 18 11:32:04 MST 2021 > > Finished: Sat Nov 20 21:39:18 MST 2021 > > Duration: 2 Days 10 hours 7 minutes > > > > Built using OpenBSD 7.0-current (GENERIC.MP) #1057: Wed Nov 17 16:51:35 MST > > 2021 > [...] > Hi! > The patch below fixes build on sparc64. > OK? ok kmos --Kurt > > http://build-failures.rhaalovely.net/sparc64/2021-11-18/graphics/enblend-enfuse.log > > Index: patches/patch-src_minimizer_h > === > RCS file: patches/patch-src_minimizer_h > diff -N patches/patch-src_minimizer_h > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-src_minimizer_h 25 Nov 2021 08:51:18 - > @@ -0,0 +1,13 @@ > +$OpenBSD$ > + > +Index: src/minimizer.h > +--- src/minimizer.h.orig > src/minimizer.h > +@@ -29,6 +29,7 @@ > + #include > + #include > + #include > ++#include > + > + #include > + > >
Re: sparc64 bulk build report
On Sun, November 21, 2021 07:39, k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Thu Nov 18 11:32:04 MST 2021 > Finished: Sat Nov 20 21:39:18 MST 2021 > Duration: 2 Days 10 hours 7 minutes > > Built using OpenBSD 7.0-current (GENERIC.MP) #1057: Wed Nov 17 16:51:35 MST > 2021 [...] Hi! The patch below fixes build on sparc64. OK? > http://build-failures.rhaalovely.net/sparc64/2021-11-18/graphics/enblend-enfuse.log Index: patches/patch-src_minimizer_h === RCS file: patches/patch-src_minimizer_h diff -N patches/patch-src_minimizer_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_minimizer_h 25 Nov 2021 08:51:18 - @@ -0,0 +1,13 @@ +$OpenBSD$ + +Index: src/minimizer.h +--- src/minimizer.h.orig src/minimizer.h +@@ -29,6 +29,7 @@ + #include + #include + #include ++#include + + #include +
Re: sparc64 bulk build report
On Sat, 2021-11-20 at 21:39 -0700, k...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/sparc64/2021-11-18/x11/gnome/gjs.log
cc1plus: warning: libgjs-jsapi.a.p/gjs_pch.hh.gch: had text segment at
different address
cc1plus: error: one or more PCH files were found, but they were invalid
Disabling precompiled headers reveals another gcc 8.4.0 issue with
the cxx11 abi_tag not being applied consistently and causing link
errors. No amount of fiddling with trying to get gcc to apply the
tag where it was missing worked for me, but switching to ports
clang works. okay?
Index: Makefile
===
RCS file: /cvs/ports/x11/gnome/gjs/Makefile,v
retrieving revision 1.99
diff -u -p -u -r1.99 Makefile
--- Makefile25 Oct 2021 14:48:37 - 1.99
+++ Makefile23 Nov 2021 21:58:48 -
@@ -25,7 +25,7 @@ MODULES= devel/meson \
DEBUG_PACKAGES = ${BUILD_PACKAGES}
-COMPILER= base-clang ports-gcc
+COMPILER= base-clang ports-clang
MODPY_RUNDEP= No
MODPY_BUILDDEP= No
