sparc64 bulk build report

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

sparc64 bulk build report

Landry Breuil-5
bulk build on sparc64-1.ports.openbsd.org
started on  Sun Sep 30 03:17:42 MDT 2018
finished at Sun Oct 7 16:04:57 MDT 2018
lasted 08D05h47m
done with kern.version=OpenBSD 6.4-beta (GENERIC) #656: Sat Sep 29 05:26:25 MDT 2018

built packages:7554
Sep 30:396
Oct 1:69
Oct 2:167
Oct 3:145
Oct 4:270
Oct 5:527
Oct 6:1260
Oct 7:4719



build failures: 33
http://build-failures.rhaalovely.net//sparc64/2018-09-30/cad/yosys.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/arm-none-eabi/gcc-linaro.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/avr/gcc.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/libvmime.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/physfs.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/reposurgeon.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/riscv-elf/gcc.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/spidermonkey52.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/devel/xtensa-elf/gcc.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/emulators/ppsspp.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/emulators/stella.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/games/godot.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/games/lugaru.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/games/prboom-plus.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/graphics/dcmtk.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/lang/apl.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/lang/ponyc.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/lang/racket-minimal.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/mail/kopano/webapp.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/math/gbc.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/math/z3.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/multimedia/swfmill.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/net/megatools.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/net/p5-Net-SSH-Perl.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/net/toxcore.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/net/zeromq.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/print/texlive/base.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/security/encfs.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/security/hashdeep.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/security/sslscan,openssl.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/sysutils/facter.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/textproc/mupdf.log
http://build-failures.rhaalovely.net//sparc64/2018-09-30/www/libsass.log
Base libs:
c.92.5 crypto.44.1

X libs:

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Stuart Henderson
On 2018/10/07 16:05, [hidden email] wrote:
> http://build-failures.rhaalovely.net//sparc64/2018-09-30/print/texlive/base.log

Not new (same failure was present in 2018-07-31, but not in the previous
2018-05-13 build), but that is annoying :(

libxetex.a(libxetex_a-XeTeX_ext.o): In function `initversionstring':
XeTeX_ext.c:(.text+0x50c): undefined reference to `png_get_header_ver'
XeTeX_ext.c:(.text+0x5c0): undefined reference to `png_get_header_ver'
libxetex.a(libxetex_a-pngimage.o): In function `check_for_png':
pngimage.c:(.text+0xa0): undefined reference to `png_sig_cmp'
libxetex.a(libxetex_a-pngimage.o): In function `png_scan_file':
pngimage.c:(.text+0x130): undefined reference to `png_create_read_struct'
pngimage.c:(.text+0x140): undefined reference to `png_create_info_struct'
pngimage.c:(.text+0x154): undefined reference to `png_init_io'
pngimage.c:(.text+0x160): undefined reference to `png_read_info'
pngimage.c:(.text+0x16c): undefined reference to `png_get_image_width'
pngimage.c:(.text+0x17c): undefined reference to `png_get_image_height'
pngimage.c:(.text+0x18c): undefined reference to `png_get_bit_depth'
pngimage.c:(.text+0x19c): undefined reference to `png_get_x_pixels_per_meter'
pngimage.c:(.text+0x1cc): undefined reference to `png_get_y_pixels_per_meter'
pngimage.c:(.text+0x270): undefined reference to `png_destroy_info_struct'
pngimage.c:(.text+0x28c): undefined reference to `png_destroy_read_struct'
pngimage.c:(.text+0x2fc): undefined reference to `png_destroy_read_struct'
collect2: error: ld returned 1 exit status

Does anyone have time to investigate?

Guessing the libpng-1.6.35 update is the most likely cause.

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Stuart Henderson
On 2018/10/08 09:37, Stuart Henderson wrote:

> On 2018/10/07 16:05, [hidden email] wrote:
> > http://build-failures.rhaalovely.net//sparc64/2018-09-30/print/texlive/base.log
>
> Not new (same failure was present in 2018-07-31, but not in the previous
> 2018-05-13 build), but that is annoying :(
>
> libxetex.a(libxetex_a-XeTeX_ext.o): In function `initversionstring':
> XeTeX_ext.c:(.text+0x50c): undefined reference to `png_get_header_ver'
> XeTeX_ext.c:(.text+0x5c0): undefined reference to `png_get_header_ver'
> libxetex.a(libxetex_a-pngimage.o): In function `check_for_png':
> pngimage.c:(.text+0xa0): undefined reference to `png_sig_cmp'
> libxetex.a(libxetex_a-pngimage.o): In function `png_scan_file':
> pngimage.c:(.text+0x130): undefined reference to `png_create_read_struct'
> pngimage.c:(.text+0x140): undefined reference to `png_create_info_struct'
> pngimage.c:(.text+0x154): undefined reference to `png_init_io'
> pngimage.c:(.text+0x160): undefined reference to `png_read_info'
> pngimage.c:(.text+0x16c): undefined reference to `png_get_image_width'
> pngimage.c:(.text+0x17c): undefined reference to `png_get_image_height'
> pngimage.c:(.text+0x18c): undefined reference to `png_get_bit_depth'
> pngimage.c:(.text+0x19c): undefined reference to `png_get_x_pixels_per_meter'
> pngimage.c:(.text+0x1cc): undefined reference to `png_get_y_pixels_per_meter'
> pngimage.c:(.text+0x270): undefined reference to `png_destroy_info_struct'
> pngimage.c:(.text+0x28c): undefined reference to `png_destroy_read_struct'
> pngimage.c:(.text+0x2fc): undefined reference to `png_destroy_read_struct'
> collect2: error: ld returned 1 exit status
>
> Does anyone have time to investigate?
>
> Guessing the libpng-1.6.35 update is the most likely cause.
>

Main difference in libpng-1.6.35 are png_size_t -> size_t change and build
system regenerated with new autoconf/autobreak, and a lot of typo fixes,
doesn't seem hugely likely to trigger this..

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Rafael Sadowski
In reply to this post by Landry Breuil-5
On Sun Oct 07, 2018 at 04:05:30PM -0600, [hidden email] wrote:
> http://build-failures.rhaalovely.net//sparc64/2018-09-30/net/megatools.log

Unbreak megatools. The build needs a C99 or C11 compiler.

Index: Makefile
===================================================================
RCS file: /cvs/ports/net/megatools/Makefile,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 Makefile
--- Makefile 8 Sep 2018 21:50:08 -0000 1.15
+++ Makefile 8 Oct 2018 21:07:18 -0000
@@ -5,6 +5,7 @@ PORTROACH = limit:[0-9]\.tar\.gz
 COMMENT = command line client application for Mega
 
 DISTNAME = megatools-1.10.2
+REVISION = 0
 
 CATEGORIES = net
 
@@ -20,6 +21,9 @@ WANTLIB += ssl
 
 MASTER_SITES = https://megatools.megous.com/builds/
 
+# C99
+COMPILER = base-clang ports-clang ports-gcc
+
 BUILD_DEPENDS = devel/gobject-introspection \
  textproc/asciidoc
 LIB_DEPENDS = devel/glib2 \
@@ -30,6 +34,8 @@ CONFIGURE_STYLE = gnu
 MAKE_FLAGS = VERBOSE=1
 
 CONFIGURE_ARGS = --disable-introspection
+
+CFLAGS += -std=c99
 
 SEPARATE_BUILD = Yes
 

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Rafael Sadowski
In reply to this post by Landry Breuil-5
On Sun Oct 07, 2018 at 04:05:30PM -0600, [hidden email] wrote:
> http://build-failures.rhaalovely.net//sparc64/2018-09-30/www/libsass.log

I run in the same compiler error with `CC=gcc CXX=g++ make`. Base gcc is
missing C++0x suport. Simple fix:


Index: Makefile
===================================================================
RCS file: /cvs/ports/www/libsass/Makefile,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 Makefile
--- Makefile 26 Apr 2018 08:31:29 -0000 1.3
+++ Makefile 8 Oct 2018 21:17:57 -0000
@@ -5,6 +5,7 @@ COMMENT = C/C++ implementation of a Sas
 GH_ACCOUNT = sass
 GH_PROJECT = libsass
 GH_TAGNAME = 3.5.4
+REVISION = 0
 
 SHARED_LIBS +=  sass                      0.0 # 0.0
 
@@ -18,6 +19,9 @@ CATEGORIES = www
 PERMIT_PACKAGE_CDROM = Yes
 
 WANTLIB = ${COMPILER_LIBCXX} m
+
+# c++0x
+COMPILER = base-clang ports-clang ports-gcc
 
 BUILD_DEPENDS = ${MODGNU_AUTOCONF_DEPENDS} \
  ${MODGNU_AUTOMAKE_DEPENDS} \

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Rafael Sadowski
In reply to this post by Landry Breuil-5
On Sun Oct 07, 2018 at 04:05:30PM -0600, [hidden email] wrote:
> http://build-failures.rhaalovely.net//sparc64/2018-09-30/security/hashdeep.log

I can reproduce the compiler error.  hashdeep needs a C++11 compiler.
Tested with ports-gcc and base-clang on amd64 but should build on
sparc64 too.


Index: Makefile
===================================================================
RCS file: /cvs/ports/security/hashdeep/Makefile,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 Makefile
--- Makefile 6 Jul 2018 19:01:21 -0000 1.2
+++ Makefile 8 Oct 2018 21:48:29 -0000
@@ -5,6 +5,7 @@ COMMENT = tools to compute hashes recur
 GH_ACCOUNT = jessek
 GH_PROJECT = hashdeep
 GH_TAGNAME = v4.4
+REVISION = 0
 
 CATEGORIES = security
 
@@ -15,6 +16,9 @@ PERMIT_PACKAGE_CDROM = Yes
 
 WANTLIB += ${COMPILER_LIBCXX} c m
 
+# C++11 nullptr
+COMPILER = base-clang ports-clang ports-gcc
+
 BUILD_DEPENDS = ${MODGNU_AUTOCONF_DEPENDS} \
  ${MODGNU_AUTOMAKE_DEPENDS}
 
@@ -25,6 +29,8 @@ AUTOCONF_VERSION = 2.69
 AUTOMAKE_VERSION = 1.15
 
 NO_TEST = Yes
+
+CXXFLAGS = -std=c++11
 
 pre-configure:
  cd ${WRKSRC} && \

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Anthony J. Bentley-4
In reply to this post by Rafael Sadowski
Rafael Sadowski writes:
> On Sun Oct 07, 2018 at 04:05:30PM -0600, [hidden email] wrote:
> > http://build-failures.rhaalovely.net//sparc64/2018-09-30/net/megatools.log
>
> Unbreak megatools. The build needs a C99 or C11 compiler.

> +# C99
> +COMPILER = base-clang ports-clang ports-gcc
...
> +CFLAGS += -std=c99

Surely only one or the other is necessary? GCC 4.2 supports -std=c99,
it just doesn't default to it.

Reply | Threaded
Open this post in threaded view
|

Re: sparc64 bulk build report

Ingo Feinerer-2
In reply to this post by Rafael Sadowski
On Mon, Oct 08, 2018 at 11:51:35PM +0200, Rafael Sadowski wrote:
> On Sun Oct 07, 2018 at 04:05:30PM -0600, [hidden email] wrote:
> > http://build-failures.rhaalovely.net//sparc64/2018-09-30/security/hashdeep.log
>
> I can reproduce the compiler error.  hashdeep needs a C++11 compiler.
> Tested with ports-gcc and base-clang on amd64 but should build on
> sparc64 too.

Confirmed (and tested on amd64). OK feinerer@

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/security/hashdeep/Makefile,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 Makefile
> --- Makefile 6 Jul 2018 19:01:21 -0000 1.2
> +++ Makefile 8 Oct 2018 21:48:29 -0000
> @@ -5,6 +5,7 @@ COMMENT = tools to compute hashes recur
>  GH_ACCOUNT = jessek
>  GH_PROJECT = hashdeep
>  GH_TAGNAME = v4.4
> +REVISION = 0
>  
>  CATEGORIES = security
>  
> @@ -15,6 +16,9 @@ PERMIT_PACKAGE_CDROM = Yes
>  
>  WANTLIB += ${COMPILER_LIBCXX} c m
>  
> +# C++11 nullptr
> +COMPILER = base-clang ports-clang ports-gcc
> +
>  BUILD_DEPENDS = ${MODGNU_AUTOCONF_DEPENDS} \
>   ${MODGNU_AUTOMAKE_DEPENDS}
>  
> @@ -25,6 +29,8 @@ AUTOCONF_VERSION = 2.69
>  AUTOMAKE_VERSION = 1.15
>  
>  NO_TEST = Yes
> +
> +CXXFLAGS = -std=c++11
>  
>  pre-configure:
>   cd ${WRKSRC} && \

Reply | Threaded
Open this post in threaded view
|

sparc64 texlive [Re: sparc64 bulk build report]

Stuart Henderson
In reply to this post by Stuart Henderson
On 2018/10/08 12:12, Stuart Henderson wrote:

> On 2018/10/08 09:37, Stuart Henderson wrote:
> > On 2018/10/07 16:05, [hidden email] wrote:
> > > http://build-failures.rhaalovely.net//sparc64/2018-09-30/print/texlive/base.log
> >
> > Not new (same failure was present in 2018-07-31, but not in the previous
> > 2018-05-13 build), but that is annoying :(
> >
> > libxetex.a(libxetex_a-XeTeX_ext.o): In function `initversionstring':
> > XeTeX_ext.c:(.text+0x50c): undefined reference to `png_get_header_ver'
> > XeTeX_ext.c:(.text+0x5c0): undefined reference to `png_get_header_ver'
> > libxetex.a(libxetex_a-pngimage.o): In function `check_for_png':
> > pngimage.c:(.text+0xa0): undefined reference to `png_sig_cmp'
> > libxetex.a(libxetex_a-pngimage.o): In function `png_scan_file':
> > pngimage.c:(.text+0x130): undefined reference to `png_create_read_struct'
> > pngimage.c:(.text+0x140): undefined reference to `png_create_info_struct'
> > pngimage.c:(.text+0x154): undefined reference to `png_init_io'
> > pngimage.c:(.text+0x160): undefined reference to `png_read_info'
> > pngimage.c:(.text+0x16c): undefined reference to `png_get_image_width'
> > pngimage.c:(.text+0x17c): undefined reference to `png_get_image_height'
> > pngimage.c:(.text+0x18c): undefined reference to `png_get_bit_depth'
> > pngimage.c:(.text+0x19c): undefined reference to `png_get_x_pixels_per_meter'
> > pngimage.c:(.text+0x1cc): undefined reference to `png_get_y_pixels_per_meter'
> > pngimage.c:(.text+0x270): undefined reference to `png_destroy_info_struct'
> > pngimage.c:(.text+0x28c): undefined reference to `png_destroy_read_struct'
> > pngimage.c:(.text+0x2fc): undefined reference to `png_destroy_read_struct'
> > collect2: error: ld returned 1 exit status
> >
> > Does anyone have time to investigate?
> >
> > Guessing the libpng-1.6.35 update is the most likely cause.
> >
>
> Main difference in libpng-1.6.35 are png_size_t -> size_t change and build
> system regenerated with new autoconf/autobreak, and a lot of typo fixes,
> doesn't seem hugely likely to trigger this..
>

Well that's fun. I brought my semi-ancient spaceheater out of semi-retirement
(winter is coming anyway, so this makes sense) and tried a few things.

The following libtool command generates different output on various arches.

/usr/bin/libtool  --tag=CXX   --mode=link c++  -O2 -pipe  -L/usr/local/lib -L/usr/X11R6/lib -o xetex xetexdir/xetex-xetexextra.o synctexdir/xetex-synctex.o xetex-xetexini.o xetex-xetex0.o xetex-xetex-pool.o libxetex.a -L/usr/local/lib -lharfbuzz-icu -lharfbuzz -L/usr/local/lib -lgraphite2 -L/usr/local/lib -licui18n -licuuc -licudata -lpthread -lm     /usr/obj/ports/texlive_base-2017/texlive-20170524-source/Work/libs/teckit/libTECkit.a /usr/obj/ports/texlive_base-2017/texlive-20170524-source/Work/libs/poppler/libpoppler.a -L/usr/local/lib -lpng -lz -L/usr/X11R6/lib -lfreetype -lz -lz libmd5.a -L/usr/X11R6/lib -lfontconfig -lfreetype -lz lib/lib.a /usr/obj/ports/texlive_base-2017/texlive-20170524-source/Work/texk/kpathsea/libkpathsea.la  -lm

Some of this is expected (differing c++ standard library), some not.
Both start with

libtool: link: c++ -o .libs/xetex -pthread -O2 -pipe xetexdir/xetex-xetexextra.o synctexdir/xetex-synctex.o xetex-xetexini.o xetex-xetex0.o xetex-xetex-pool.o libxetex.a /usr/obj/ports/texlive_base-2017/texlive-20170524-source/Work/libs/teckit/libTECkit.a /usr/obj/ports/texlive_base-2017/texlive-20170524-source/Work/libs/poppler/libpoppler.a libmd5.a lib/lib.a -L.libs -lharfbuzz-icu -lm -licuuc -licudata -lharfbuzz -lglib-2.0 -liconv -lpcre -lintl -lfreetype -lz

Then the next bit is different

SPARC64: ... -lgraphite2 -licui18n -lpthread -lstdc++ -lestdc++ -lfontconfig ...
AMD64:   ... -lgraphite2 -lc++ -lc++abi -lpthread -licui18n -lpng -lfontconfig ...

And then finishing up with

-lexpat -lkpathsea -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib

I don't know what's going on but repeating the above libtool command line
using GNU libtool instead of the perl one in base, it manages to link xetex
successfully. I am now trying a texlive build with the diff below.

naddy, am I OK to commit this if my build succeeds?



Index: Makefile
===================================================================
RCS file: /cvs/ports/print/texlive/base/Makefile,v
retrieving revision 1.102
diff -u -p -r1.102 Makefile
--- Makefile 4 Sep 2018 12:46:20 -0000 1.102
+++ Makefile 9 Oct 2018 20:49:34 -0000
@@ -7,12 +7,11 @@ DISTNAME = texlive-${DIST_V}-source
 PKGNAME = texlive_base-${V}
 WRKDIST = ${WRKDIR}/texlive-${DIST_V}-source
 
-REVISION-main = 2
+REVISION = 3
 
 MULTI_PACKAGES = -main -mktexlsr
 PKGNAME-mktexlsr = texlive_mktexlsr-${V}
 PKGNAME-main = ${PKGNAME}
-REVISION-mktexlsr = 0
 
 DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
  texlive-${DIST_V}-extra${EXTRACT_SUFX}
@@ -85,6 +84,8 @@ USE_GMAKE = Yes
 
 .if ${MACHINE_ARCH} == "sparc64"
 CFLAGS += -fPIC
+# somehow base libtool misses -lpng while linking xetex
+USE_LIBTOOL = gnu
 .endif
 
 # clisp limits which arches we can use xindy on