Created attachment 179952 [details] patch The attached patch fixes the issue, obtained from mmel@
Unfortunately, this PR is missing details on what exactly is failing on armv6 as well as why and how the proposed changes are solving these problems. Without such information, the modification to XK_ARCH of using `uname -p` instead of `uname -m` seems like a very gross hack. Please test whether the approach taken in r404710 for cdrtools (see CDRTLSTARGET and CDRTLSXARCH and adjust/introduce SCSILIBTARGET/ SCSILIBXARCH in cdrdao accordingly) also fixes that problem and if not, why not. The proposed change to mconfig.h looks good to me. I don't get why the change to format.c would be necessary and what it is supposed to solve for armv6, though. Apparently, even in cdrtools 3.02a07 that part of format() is essentially unchanged and causes no problems for armv6 there AFAICT (confirmed by you in PR 197794 for cdrtools 3.01).
(In reply to Marius Strobl from comment #1) >Unfortunately, this PR is missing details on what exactly is failing >on armv6 as well as why and how the proposed changes are solving these >problems. Without such information, the modification to XK_ARCH of >using `uname -p` instead of `uname -m` seems like a very gross hack. >Please test whether the approach taken in r404710 for cdrtools (see >CDRTLSTARGET and CDRTLSXARCH and adjust/introduce SCSILIBTARGET/ >SCSILIBXARCH in cdrdao accordingly) also fixes that problem and if >not, why not. It generates this: -------------- gmake[3]: Entering directory '/usr/ports/sysutils/cdrdao/work/cdrdao-1.2.3' Making all in scsilib gmake[4]: Entering directory '/usr/ports/sysutils/cdrdao/work/cdrdao-1.2.3/scsilib' Makefile:18: warning: overriding recipe for target 'install' RULES/rules1.dir:27: warning: ignoring old recipe for target 'install' p incs/armv6-freebsd-cc gmake[4]: p: Command not found RULES/rules.cnf:57: incs/armv6-freebsd-cc/rules.cnf: No such file or directory gmake[4]: [RULES/rules.cnf:27: incs/armv6-freebsd-cc/Inull] Error 127 (ignored) /bin/sh: cannot create incs/armv6-freebsd-cc/Inull: No such file or directory gmake[4]: *** [RULES/rules.cnf:28: incs/armv6-freebsd-cc/Inull] Error 2 -------------- We have mips.mips and mips.mips64, arm.arm and arm.armv6, ... - each one needs own configuration file in scsilib/RULES. By this, 'uname -p' is right source for XK_ARCH. > I don't get why > the change to format.c would be necessary and what it is supposed to > solve for armv6, though. Apparently, even in cdrtools 3.02a07 that > part of format() is essentially unchanged and causes no problems for > armv6 there AFAICT (confirmed by you in PR 197794 for cdrtools 3.01) But clang has changed and libschily uses unportable (and invalid) code in format.c. The old trick with __va_arg_list() doesn't work anymore (for arm), -------------- format.c:449:37: error: passing 'void *' to parameter of incompatible type 'va_list' (aka '__builtin_va_list') count += format(fun, farg, rfmt, __va_arg_list(args)); -------------- and 'va_list foo; va_copy(foo, args);' is direct and portable replacement... Michal
(In reply to Michal Meloun from comment #2) Of course platform specific .rul files/symlinks have to exist, but without knowing what exactly gets created/used on armv6 currently and what not, I must assume that my previous analysis still holds and that it's not relevant to use the output of `uname -p` for the name for the rul files/symlinks. They just need to match what the Schily build system expects. That's why I've asked the approach taken in the cdrtools ports to be tested with the cdrdao port, i. e. (change variable name and paths as appropriate for cdrdao): CDRTLSXARCH!= ${UNAME} -m .if ${CDRTLSXARCH} != "i386" @${LN} -sf ${WRKSRC}/RULES/i386-freebsd-cc.rul \ ${WRKSRC}/RULES/${CDRTLSXARCH}-${OPSYS:tl}-cc.rul .endif Unnecessary patches are to be avoided, especially for software written by Joerg Schilling.
Created attachment 180793 [details] patch The attached patch works for armv6 and mips, mips64 is still broken. I can't test on arm64 (poudriere is broken for me and I don't have an arm64 board right now)
Created attachment 180794 [details] patch
(In reply to Marius Strobl from comment #3) I'm sorry, but I cannot agree. See this flow: [scsilib/RULES/rules.top line 39] include $(SRCROOT)/$(RULESDIR)/$(XARCH).rul [scsilib/RULES/rules1.top line 253] XARCH= $(K_ARCH)$(-O_ARCH)-$(C_ARCH) [scsilib/RULES/mk-gmake.id line 48] K_ARCH= $(XK_ARCH) [scsilib/RULES/mk-gmake.id line 44] (in original unpatched code) XK_ARCH:= $(shell uname -m | tr ... and compare this with names of .rul files in RULES direstory: armv4l-linux-cc.rul (can be expanded to armv[4][6][7]l-linux-cc.rul) i[3][4][5][6]86-linux-gcc.rul ppc[][64]-linux-gcc.rul sparc[][64]-linux-cc.rul mips[][el]-linux-cc.rul So it's clear that build system expect 'architecture type' in XK_ARCH and that's exactly what returns 'uname -m' on Linux. But FreeBSD uses different logic for uname and best fit for 'architecture type' is output from 'uname -p', imo. Please see https://en.wikipedia.org/wiki/Uname for more complete list of uname results from various OS and platforms. But anyway, the new patch works for me, so I'm fine with any solution.
A commit references this bug: Author: marius Date: Sun Apr 23 18:22:02 UTC 2017 New revision: 439255 URL: https://svnweb.freebsd.org/changeset/ports/439255 Log: - Fix build on armv6 and mips and most likely also on aarc64 and mips64. [1] - Let's see whether specifying USE_CXXSTD=c++11 stops the flood of pkg-fallout SPAM regarding gcdmaster caused by the update of devel/libsigc++20 to 2.10.0 in r437480. PR: 217074 [1] Submitted by: mmel (partially) [1] Changes: head/sysutils/cdrdao/Makefile head/sysutils/cdrdao/files/patch-dao_CdrDriver.cc head/sysutils/cdrdao/files/patch-dao_CdrDriver.h head/sysutils/cdrdao/files/patch-scsilib_include_mconfig.h head/sysutils/cdrdao/files/patch-scsilib_libschily_format.c