poudriere-devel cross update-builds of ports build-depends failures: "pkg-static: wrong architecture: FreeBSD:12:armv7 instead of FreeBSD:12:amd64" (similarly for FreeBSD:12:aarch64 )

[Mark Millard via freebsd-ports]

It has been some time since I did a buildworld (-r327485). The
same for builing updated ports. For the following I've not
done any0 rebuilds or installs of world, just ports.

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 460228
Last Changed Rev: 460228


While the native amd64 rebuilds and installs of ports went
fine, the later cross builds for armv7 and aarch64 did not,
first just showing general information, then an example
error:

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDFSSDjail  12.0-CURRENT amd64 null   2017-11-22 10:15:15 
/usr/obj/DESTDIRs/clang-amd64-installworld-poud
FBSDFSSDjailCortexA53 12.0-CURRENT arm64.aarch64 null   2017-12-30 13:14:33 
/usr/obj/DESTDIRs/clang-cortexA53-installworld-poud
FBSDFSSDjailArmV7 12.0-CURRENT arm.armv7 null   2017-12-30 13:05:37 
/usr/obj/DESTDIRs/clang-armv7-installworld-poud

# poudriere bulk -jFBSDFSSDjailArmV7 -w -f /root/armv7-origins.txt
[00:00:00] Cross-building ports for arm.armv7 on amd64 requires QEMU
. . .
# poudriere bulk -jFBSDFSSDjailCortexA53 -w -f /root/cortexA53-origins.txt
[00:00:00] Cross-building ports for arm64.aarch64 on amd64 requires QEMU
. . .

Looking in the logs for the significant number of build-depends
failures I see things like:

===
===>   binutils-2.29.1,1 depends on file: /usr/local/lib/libgmp.so - not found
===>   Installing existing package /packages/All/gmp-6.1.2.txz
[FBSDFSSDjailVariant] Installing gmp-6.1.2...
pkg-static: wrong architecture: FreeBSD:12:armv7 instead of FreeBSD:12:amd64

Failed to install the following 1 package(s): /packages/All/gmp-6.1.2.txz
*** Error code 70

Stop.
make: stopped in /usr/ports/devel/binutils
=>> Cleaning up wrkdir
===>  Cleaning for binutils-2.29.1,1
build of devel/binutils | binutils-2.29.1,1 ended at Sun Jan 28 15:54:16 PST 
2018
build time: 00:00:48
!!! build failure encountered !!!

(The build was attempting 151 out of 416 ports
for the update in the armv7 case.)

The only things to build successfully were:

[00:08:23] Built ports: ports-mgmt/pkg ports-mgmt/portmaster 
sysutils/DTraceToolkit devel/pkgconf devel/boost-jam

The failures were (I split the long line):

[00:08:23] Failed ports:
security/p5-Net-SSLeay:build-depends
net/p5-URI:build-depends
devel/nspr:build-depends
devel/py-setuptools@py36:build-depends
security/ca_root_nss:build-depends
x11-fonts/encodings:build-depends
ftp/wget:build-depends
devel/py-setuptools:build-depends
security/sudo:build-depends
devel/nasm:build-depends
textproc/docbook-xsl:build-depends
archivers/liblz4:build-depends
multimedia/libdvdread:build-depends
devel/boehm-gc:build-depends
devel/libuv:build-depends
security/trousers:build-depends
devel/pcre2:build-depends
security/libtasn1:build-depends
devel/gdb:build-depends
devel/glib20:build-depends
devel/binutils:build-depends
devel/boost-libs:lib-depends
devel/qt5-qmake:run-depends

The rest was skipped.

The following side stepped the issue by forcing
everything to rebuild:

# poudriere bulk -c -jFBSDFSSDjailArmV7 -w -f /root/armv7-origins.txt

That is still in process but things are building and
reporting Success:

# poudriere bulk -c -jFBSDFSSDjailArmV7 -w -f /root/armv7-origins.txt
[00:00:00] Cross-building ports for arm.armv7 on amd64 requires QEMU
. . .
[00:02:38] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.10.4
[00:04:17] [01] [00:01:39] Finished ports-mgmt/pkg | pkg-1.10.4: Success
. . .
[00:04:25] [20] [00:00:07] Finished sysutils/gnome_subr | gnome_subr-1.0: 
Success
[00:04:26] [01] [00:00:08] Finished print/indexinfo | indexinfo-0.3.1: Success
[00:04:26] [20] [00:00:00] Building devel/boost-jam | boost-jam-1.66.0
[00:04:26] [04] [00:00:08] Finished devel/autoconf-wrapper | 
autoconf-wrapper-20131203: Success
[00:04:26] [05] [00:00:08] Finished devel/automake-wrapper | 
automake-wrapper-20131203: Success
[00:04:26] [27] [00:00:08] Finished devel/tradcpp | tradcpp-0.5.2: Success
[00:04:26] [01] [00:00:00] Building devel/gettext-runtime | 
gettext-runtime-0.19.8.1_1
[00:04:27] [25] [00:00:09] Finished multimedia/v4l_compat | v4l_compat-1.6.3: 
Success
. . .
[00:04:28] [12] [00:00:10] Finished misc/pciids | pciids-20171206: Success
[00:04:28] [22] [00:00:10] Finished graphics/jbigkit | jbigkit-2.1_1: Success
[00:04:28] [12] [00:00:00] Building print/gsfonts | gsfonts-8.11_8
[00:04:28] [22] [00:00:00] Building devel/atf | atf-0.21
[00:04:30] [18] [00:00:12] Finished misc/hicolor-icon-theme | 
hicolor-icon-theme-0.15: Success
[00:04:31] [07] [00:00:13] Finished devel/libpthread-stubs | 
libpthread-stubs-0.4: Success
[00:04:31] [18] [00:00:00] Building misc/freebsd-release-manifests | 
freebsd-release-manifests-20171003
[00:04:31] [26] [00:00:13] Finished archivers/zip | zip-3.0_1: Success
[00:04:31] [07] [00:00:00] Building 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

On 2018-Jul-28, at 1:33 AM, Mark Millard  wrote:

> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
> 
>> On 7/26/18 12:02 AM, Mark Millard wrote:
>>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
>>> (from
>>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc --and
>>> other things). . .
>>> 
>>> ===>  Building package for powerpc64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>>  such file or directory
>>> . . .
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>>  such file or directory
>>> *** Error code 1
>>> 
>>> 
>>> ===>  Building package for amd64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>>  such file or directo
>>> ry
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:

> On 7/26/18 12:02 AM, Mark Millard wrote:
>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 (from
>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc --and
>> other things). . .
>> 
>> ===>  Building package for powerpc64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>  such file or directory
>> . . .
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>  such file or directory
>> *** Error code 1
>> 
>> 
>> ===>  Building package for amd64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directo
>> ry
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>  such file or directory

Re: Removing objdump breaks GCC configure

[Mark Millard via freebsd-ports]

[I also ran into the issue for sysutils/u-boot-pine64 builds in
my context (WITHOUT_BINUTILS).]

On 2018-Aug-1, at 3:08 PM, Mark Millard  wrote:

> On 2018-Aug-1, at 1:29 PM, John Baldwin  wrote:
> 
>> On 7/29/18 9:02 PM, Mark Millard wrote:
 It looks like configure uses objdump (without a path-prefix) for
 export_sym_check :
 
  case "${host}" in
*-*-darwin*)
  if test x$build = x$host; then
export_sym_check="nm${exeext} -g"
  elif test x$host = x$target; then
export_sym_check="$gcc_cv_nm -g"
  else
export_sym_check=
  fi
;;
*)
  if test x$build = x$host; then
export_sym_check="objdump${exeext} -T"
  elif test x$host = x$target; then
export_sym_check="$gcc_cv_objdump -T"
  else
export_sym_check=
  fi
;;
  esac
 
 Note that this would not be the objdump from devel/powerpc64-binutils
 but one for amd64 (in my example) such as from devel/binutils or
 devel/amd64-binutils for my context.
 
 Note the lack of any alternative to objdump use (for build matching host).
>>> 
>>> # svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile
>>> Index: /usr/ports/devel/powerpc64-gcc/Makefile
>>> ===
>>> --- /usr/ports/devel/powerpc64-gcc/Makefile (revision 475470)
>>> +++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy)
>>> @@ -16,7 +16,8 @@
>>> LIB_DEPENDS=libgmp.so:math/gmp \
>>> libmpfr.so:math/mpfr \
>>> libmpc.so:math/mpc
>>> -BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
>>> +BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils \
>>> +   objdump:devel/binutils
>>> RUN_DEPENDS=${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
>>> 
>>> USES=   gmake iconv libtool tar:xz makeinfo compiler
>> 
>> Context trimmed a bit, subject changed, and I've added Ed to the cc as he's
>> the one who removed objdump.  It seems that GCC at least has a hidden
>> dependency on objdump.  Ed, were the lang/gcc* ports updated when objdump
>> was removed to list it as dependency for the plugin functionality?  If not,
>> they might also need a similar fix.
> 
> devel/-gcc cross compiler builds:
> Cross builds required the builder's objdump and possibly the target's
> too (as well as other target binutils). But for the target that is the same
>  in devel/-binutils and devel/-gcc and likely was already
> covered.
> 
> (I may have missed other builder-binutil tool references but know
> objdump for sure.)
> 
> When the builder architecture is also the target as part of the
> port definition (all lang/gcc* ?), devel/binutils is likely already
> required and then covers all objdump use as far as I can tell.
> 
> (I'm not sure if the normal package builders are omitting system
> binutils yet or if they might always have devel/binutils installed.)
> 
>>> Note: Various other autoconfig .ac files for various ports
>>> might also make assumptions about some binutils for the
>>> building archteiture, assumptions that various FreeBSD
>>> architectures need not automatically provide for: ones for
>>> which WITHOUT_BINUTILS= can be used.
>> 
>> I believe Ed did an exp-run before disabling objdump by default (or maybe
>> that change is still pending?).  I'm not sure if that exp-run would catch
>> more subtle changes like this.
> 
> My guess is that only ports with cross-build abilities might have the
> "some builder binutils tool(s) needed" issue.

I'm now using:

# svnlite diff /usr/ports/sysutils/u-boot-master/Makefile
Index: /usr/ports/sysutils/u-boot-master/Makefile
===
--- /usr/ports/sysutils/u-boot-master/Makefile  (revision 476026)
+++ /usr/ports/sysutils/u-boot-master/Makefile  (working copy)
@@ -21,6 +21,7 @@
dtc>=1.4.1:sysutils/dtc \
mkimage:sysutils/u-boot-tools
 BUILD_DEPENDS+=${COMPILER}:devel/${COMPILER}
+BUILD_DEPENDS+=objdump:devel/binutils
 
 USES=  bison gmake python:2.7,build shebangfix tar:bz2
 BINARY_ALIAS=  bison=${LOCALBASE}/bin/bison dtc=${LOCALBASE}/bin/dtc sed=gsed 
swig=swig3.0

in order for sysutils/u-boot-pine64 to build in my context that
is based on WITHOUT_BINUTILS .

Interestingly: before this change the following built fine:

sysutils/u-boot-rpi3 | u-boot-rpi3-2018.07_1
sysutils/u-boot-rpi2 | u-boot-rpi2-2018.07_1
sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2018.07_1

but sysutils/u-boot-pine64 did not.

The use of some builder environment tool(s) is specific
to u-boot-pine64 (of the 4 u-boot-* 's).

I've not isolated the sysutils/u-boot-pine64 code that
puts some builder environment tool(s) to use. So I've
not formally shown root cause for this case.

I submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230288
for this issue 

Re: setting port options for multiple ports

[Mark Millard via freebsd-ports]

blubee blubeeme gurenchan at gmail.com write on
Mon Jul 30 11:03:07 UTC 2018 :

> I am working on a port that requires many other ports to be built with
> specific options selected.
> 
> Is there any way to have a port enables options in it's dependencies?

If the port is to be built on the FreeBSD package builders there are
likely large implications to forcing specific options of other ports.

Is this a "personal/local" port or otherwise not to be built by the
package builders ( or anyone doing poudriere bulk -a )?

There are ports that have local copies and internal builds of other
things needed in order to avoid such ties. As I remember pkg itself
is an example. (This has an environment-bootstrap sequence issue
involved in why as well.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[portmaster -DK devel/powerpc64-gcc built and installed
powerpc64-gcc just fine.]

On 2018-Jul-28, at 6:51 PM, Mark Millard  wrote:

> [Top note of a correction: I used portmaster -C and am
> trying without -C. The -K references below are wrong.
> No further updated material follows in this note.]
> 
> On 2018-Jul-28, at 6:47 PM, Mark Millard  wrote:
> 
>> [Completing building aarch64-gcc via portmaster -K (after pkg
>> install of  poudriere-devel builds of things required) worked
>> fine. But powerpc64-gcc via -K failed like under poudriere.]
>> 
>> On 2018-Jul-28, at 12:15 PM, Mark Millard  wrote:
>> 
>>> On 2018-Jul-28, at 10:36 AM, Mark Millard  wrote:
>>> 
 [So much for reverting -r475361 : it still is producing *-gcc-6.4.0_2.tbz 
 files.
 and the version relationship was wrong for when I first saw the issue.]
 
 On 2018-Jul-28, at 9:39 AM, Mark Millard  wrote:
 
> [Older directions of investigation omitted.]
> 
> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
> 
>> On 7/26/18 12:02 AM, Mark Millard wrote:
>>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
>>> (from
>>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
>>> --and
>>> other things). . .
 
 During experiments with this issue I have progressed past
 -r475344 and the problem has repeated.
 
 But I should have noticed 475344 < 475361 .
 
>>> ===>  Building package for powerpc64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>>  such file or directory
>>> . . .
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>>  such file or directory
>>> *** Error code 1
>>> 
>>> 
>>> ===>  Building package for amd64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[Top note of a correction: I used portmaster -C and am
trying without -C. The -K references below are wrong.
No further updated material follows in this note.]

On 2018-Jul-28, at 6:47 PM, Mark Millard  wrote:

> [Completing building aarch64-gcc via portmaster -K (after pkg
> install of  poudriere-devel builds of things required) worked
> fine. But powerpc64-gcc via -K failed like under poudriere.]
> 
> On 2018-Jul-28, at 12:15 PM, Mark Millard  wrote:
> 
>> On 2018-Jul-28, at 10:36 AM, Mark Millard  wrote:
>> 
>>> [So much for reverting -r475361 : it still is producing *-gcc-6.4.0_2.tbz 
>>> files.
>>> and the version relationship was wrong for when I first saw the issue.]
>>> 
>>> On 2018-Jul-28, at 9:39 AM, Mark Millard  wrote:
>>> 
 [Older directions of investigation omitted.]
 
 On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
 
> On 7/26/18 12:02 AM, Mark Millard wrote:
>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
>> (from
>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
>> --and
>> other things). . .
>>> 
>>> During experiments with this issue I have progressed past
>>> -r475344 and the problem has repeated.
>>> 
>>> But I should have noticed 475344 < 475361 .
>>> 
>> ===>  Building package for powerpc64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>  such file or directory
>> . . .
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>  such file or directory
>> *** Error code 1
>> 
>> 
>> ===>  Building package for amd64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directo
>> ry
>> pkg-static: Unable to access file 
>> 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[Completing building aarch64-gcc via portmaster -K (after pkg
install of  poudriere-devel builds of things required) worked
fine. But powerpc64-gcc via -K failed like under poudriere.]

On 2018-Jul-28, at 12:15 PM, Mark Millard  wrote:

> On 2018-Jul-28, at 10:36 AM, Mark Millard  wrote:
> 
>> [So much for reverting -r475361 : it still is producing *-gcc-6.4.0_2.tbz 
>> files.
>> and the version relationship was wrong for when I first saw the issue.]
>> 
>> On 2018-Jul-28, at 9:39 AM, Mark Millard  wrote:
>> 
>>> [Older directions of investigation omitted.]
>>> 
>>> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
>>> 
 On 7/26/18 12:02 AM, Mark Millard wrote:
> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
> (from
> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
> --and
> other things). . .
>> 
>> During experiments with this issue I have progressed past
>> -r475344 and the problem has repeated.
>> 
>> But I should have noticed 475344 < 475361 .
>> 
> ===>  Building package for powerpc64-gcc-6.4.0_2
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>  such file or directory
> . . .
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>  such file or directory
> *** Error code 1
> 
> 
> ===>  Building package for amd64-gcc-6.4.0_2
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>  such file or directo
> ry
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>  such file or directory
> pkg-static: Unable 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

On 2018-Jul-28, at 10:36 AM, Mark Millard  wrote:

> [So much for reverting -r475361 : it still is producing *-gcc-6.4.0_2.tbz 
> files.
> and the version relationship was wrong for when I first saw the issue.]
> 
> On 2018-Jul-28, at 9:39 AM, Mark Millard  wrote:
> 
>> [Older directions of investigation omitted.]
>> 
>> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
>> 
>>> On 7/26/18 12:02 AM, Mark Millard wrote:
 Based on attempting to update (via poudriere-devel and pkg) to -r475344 
 (from
 a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
 --and
 other things). . .
> 
> During experiments with this issue I have progressed past
> -r475344 and the problem has repeated.
> 
> But I should have noticed 475344 < 475361 .
> 
 ===>  Building package for powerpc64-gcc-6.4.0_2
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
  such file or directory
 . . .
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
  such file or directory
 *** Error code 1
 
 
 ===>  Building package for amd64-gcc-6.4.0_2
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
  such file or directo
 ry
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
  such file or directory
 pkg-static: Unable to access file 
 

/usr/ports/devel/powerpc64-gcc/Makefile : armv7 too vs. only armv6 and aarch64 for CXXFLAGS=-fbracket-depth=512 ?

[Mark Millard via freebsd-ports]

Is armv7 really distinct from armv6 and aarch64 for the below?

.if ${TARGETARCH} == "armv6" || ${TARGETARCH} == "aarch64"
. if ${COMPILER_TYPE} == clang
MAKE_ARGS+=CXXFLAGS=-fbracket-depth=512
. endif
.endif

(Not that I expect that this is tied to what I've been trying
to figure out about lack of installing into staging.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[So much for reverting -r475361 : it still is producing *-gcc-6.4.0_2.tbz files.
and the version relationship was wrong for when I first saw the issue.]

On 2018-Jul-28, at 9:39 AM, Mark Millard  wrote:

> [Older directions of investigation omitted.]
> 
> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
> 
>> On 7/26/18 12:02 AM, Mark Millard wrote:
>>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
>>> (from
>>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc --and
>>> other things). . .

During experiments with this issue I have progressed past
-r475344 and the problem has repeated.

But I should have noticed 475344 < 475361 .

>>> ===>  Building package for powerpc64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>>  such file or directory
>>> . . .
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>>  such file or directory
>>> *** Error code 1
>>> 
>>> 
>>> ===>  Building package for amd64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>>  such file or directo
>>> ry
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[Older directions of investigation omitted.]

On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:

> On 7/26/18 12:02 AM, Mark Millard wrote:
>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 (from
>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc --and
>> other things). . .
>> 
>> ===>  Building package for powerpc64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>  such file or directory
>> . . .
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>  such file or directory
>> *** Error code 1
>> 
>> 
>> ===>  Building package for amd64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directo
>> ry
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> 

A typo(?) in devel/powerpc64-gcc/Makefile : /${GCC_TARGET$}/ has an extra "$"?

[Mark Millard via freebsd-ports]

https://svnweb.freebsd.org/ports/head/devel/powerpc64-gcc/Makefile?revision=475446=markup=rev=down

shows (starting line 109):

.if ${TARGETARCH} == "amd64" || ${TARGETARCH} == "i386"
# Conflicts with sys/x86/include/float.h
${RM} 
${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET$}/${PORTVERSION}/include/float.h
.endif

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

On 2018-Jul-29, at 8:42 AM, John Baldwin  wrote:

> On 7/28/18 9:39 AM, Mark Millard wrote:
>> [Older directions of investigation omitted.]
>> 
>> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
>> 
>>> On 7/26/18 12:02 AM, Mark Millard wrote:
 Based on attempting to update (via poudriere-devel and pkg) to -r475344 
 (from
 a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
 --and
 other things). . .
 
 ===>  Building package for powerpc64-gcc-6.4.0_2
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
  such file or directory
 . . .
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
  such file or directory
 *** Error code 1
 
 
 ===>  Building package for amd64-gcc-6.4.0_2
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
  such file or directo
 ry
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
  such file or directory
 pkg-static: Unable to access file 
 /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
  such file or directory
 pkg-static: Unable to access file 
 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[In my poudriere-devel enviroment configure is deciding: enable_plugin='no' .]

On 2018-Jul-29, at 10:51 AM, Mark Millard  wrote:

> On 2018-Jul-29, at 8:42 AM, John Baldwin  wrote:
> 
>> On 7/28/18 9:39 AM, Mark Millard wrote:
>>> [Older directions of investigation omitted.]
>>> 
>>> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
>>> 
 On 7/26/18 12:02 AM, Mark Millard wrote:
> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
> (from
> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
> --and
> other things). . .
> 
> ===>  Building package for powerpc64-gcc-6.4.0_2
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>  such file or directory
> . . .
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>  such file or directory
> *** Error code 1
> 
> 
> ===>  Building package for amd64-gcc-6.4.0_2
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>  such file or directo
> ry
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>  such file or directory
> pkg-static: Unable to access file 
> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>  such file or directory
> pkg-static: Unable to access file 
> 

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[Looks like this might be objdump being available vs. not
for the architecture doing the build of devel/powerpc64-gcc
(or which ever *-gcc), such as via poudriere-devel: configure.ac
and its configure produced depend on objdump for -rdynamic
testing but devel/powerpc64-gcc and the like do not list
appropriate build dependencies for the architecture doing the
build. If buildworld did not include objdump that leaves only
a port to supply it and a path would need to be set up to
find it. More evidence listed bottom-posted.]

On 2018-Jul-29, at 5:22 PM, Mark Millard  wrote:

> [In my poudriere-devel enviroment configure is deciding: enable_plugin='no' .]
> 
> On 2018-Jul-29, at 10:51 AM, Mark Millard  wrote:
> 
>> On 2018-Jul-29, at 8:42 AM, John Baldwin  wrote:
>> 
>>> On 7/28/18 9:39 AM, Mark Millard wrote:
 [Older directions of investigation omitted.]
 
 On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
 
> On 7/26/18 12:02 AM, Mark Millard wrote:
>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
>> (from
>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
>> --and
>> other things). . .
>> 
>> ===>  Building package for powerpc64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>  such file or directory
>> . . .
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>  such file or directory
>> *** Error code 1
>> 
>> 
>> ===>  Building package for amd64-gcc-6.4.0_2
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>  such file or directory
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>  such file or directo
>> ry
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>  such file or directory
>> 

Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

Based on attempting to update (via poudriere-devel and pkg) to -r475344 (from
a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc --and
other things). . .

===>  Building package for powerpc64-gcc-6.4.0_2
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
 such file or directory
. . .
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
 such file or directory
*** Error code 1


===>  Building package for amd64-gcc-6.4.0_2
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
 such file or directo
ry
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
 such file or directory
pkg-static: Unable to access file 

Re: Removing objdump breaks GCC configure

[Mark Millard via freebsd-ports]

On 2018-Aug-1, at 1:29 PM, John Baldwin  wrote:

> On 7/29/18 9:02 PM, Mark Millard wrote:
>>> It looks like configure uses objdump (without a path-prefix) for
>>> export_sym_check :
>>> 
>>>  case "${host}" in
>>>*-*-darwin*)
>>>  if test x$build = x$host; then
>>>export_sym_check="nm${exeext} -g"
>>>  elif test x$host = x$target; then
>>>export_sym_check="$gcc_cv_nm -g"
>>>  else
>>>export_sym_check=
>>>  fi
>>>;;
>>>*)
>>>  if test x$build = x$host; then
>>>export_sym_check="objdump${exeext} -T"
>>>  elif test x$host = x$target; then
>>>export_sym_check="$gcc_cv_objdump -T"
>>>  else
>>>export_sym_check=
>>>  fi
>>>;;
>>>  esac
>>> 
>>> Note that this would not be the objdump from devel/powerpc64-binutils
>>> but one for amd64 (in my example) such as from devel/binutils or
>>> devel/amd64-binutils for my context.
>>> 
>>> Note the lack of any alternative to objdump use (for build matching host).
>> 
>> # svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile
>> Index: /usr/ports/devel/powerpc64-gcc/Makefile
>> ===
>> --- /usr/ports/devel/powerpc64-gcc/Makefile  (revision 475470)
>> +++ /usr/ports/devel/powerpc64-gcc/Makefile  (working copy)
>> @@ -16,7 +16,8 @@
>> LIB_DEPENDS= libgmp.so:math/gmp \
>>  libmpfr.so:math/mpfr \
>>  libmpc.so:math/mpc
>> -BUILD_DEPENDS=  ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
>> +BUILD_DEPENDS=  ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils \
>> +objdump:devel/binutils
>> RUN_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
>> 
>> USES=gmake iconv libtool tar:xz makeinfo compiler
> 
> Context trimmed a bit, subject changed, and I've added Ed to the cc as he's
> the one who removed objdump.  It seems that GCC at least has a hidden
> dependency on objdump.  Ed, were the lang/gcc* ports updated when objdump
> was removed to list it as dependency for the plugin functionality?  If not,
> they might also need a similar fix.

devel/-gcc cross compiler builds:
Cross builds required the builder's objdump and possibly the target's
too (as well as other target binutils). But for the target that is the same
 in devel/-binutils and devel/-gcc and likely was already
covered.

(I may have missed other builder-binutil tool references but know
objdump for sure.)

When the builder architecture is also the target as part of the
port definition (all lang/gcc* ?), devel/binutils is likely already
required and then covers all objdump use as far as I can tell.

(I'm not sure if the normal package builders are omitting system
binutils yet or if they might always have devel/binutils installed.)

>> Note: Various other autoconfig .ac files for various ports
>> might also make assumptions about some binutils for the
>> building archteiture, assumptions that various FreeBSD
>> architectures need not automatically provide for: ones for
>> which WITHOUT_BINUTILS= can be used.
> 
> I believe Ed did an exp-run before disabling objdump by default (or maybe
> that change is still pending?).  I'm not sure if that exp-run would catch
> more subtle changes like this.

My guess is that only ports with cross-build abilities might have the
"some builder binutils tool(s) needed" issue.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net  went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...

[Mark Millard via freebsd-ports]

[Updating devel/powerpc64-gcc's BUILD_DEPENDS seems to have
fixed the issue. Also: Stupid of me to have typed _BOOTSTRAP
at the end of WITH_BINUTILS and WITH_ELFTOOLCHAIN
references. I've noted the references to avoid future
confusions.]

On 2018-Jul-29, at 6:55 PM, Mark Millard  wrote:

> [Looks like this might be objdump being available vs. not
> for the architecture doing the build of devel/powerpc64-gcc
> (or which ever *-gcc), such as via poudriere-devel: configure.ac
> and its configure produced depend on objdump for -rdynamic
> testing but devel/powerpc64-gcc and the like do not list
> appropriate build dependencies for the architecture doing the
> build. If buildworld did not include objdump that leaves only
> a port to supply it and a path would need to be set up to
> find it. More evidence listed bottom-posted.]
> 
> On 2018-Jul-29, at 5:22 PM, Mark Millard  wrote:
> 
>> [In my poudriere-devel enviroment configure is deciding: enable_plugin='no' 
>> .]
>> 
>> On 2018-Jul-29, at 10:51 AM, Mark Millard  wrote:
>> 
>>> On 2018-Jul-29, at 8:42 AM, John Baldwin  wrote:
>>> 
 On 7/28/18 9:39 AM, Mark Millard wrote:
> [Older directions of investigation omitted.]
> 
> On 2018-Jul-26, at 10:24 AM, John Baldwin  wrote:
> 
>> On 7/26/18 12:02 AM, Mark Millard wrote:
>>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 
>>> (from
>>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc 
>>> --and
>>> other things). . .
>>> 
>>> ===>  Building package for powerpc64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No
>>>  such file or directory
>>> . . .
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No
>>>  such file or directory
>>> *** Error code 1
>>> 
>>> 
>>> ===>  Building package for amd64-gcc-6.4.0_2
>>> pkg-static: Unable to access file 
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No
>>>  such file or directory
>>> pkg-static: Unable to access file 
>>> 

Re: getting PKGNAME from CONFLICTS

[Mark Millard via freebsd-ports]

Dan Langille dan at langille.org wrote on
Tue Aug 14 17:54:01 UTC 2018 :

> . . .
> At https://dev.freshports.org/www/p5-CGI/ you can see:
> 
> CONFLICTS: p5-CGI.pm-[1-3]*
> . . .
> To extract the PKGNAME values from the CONFLICTS I will need to remove 
> everything after the trailing dash.
> . . .

p5-
vs.
p5-CGI.pm-
vs.
p5-CGI.pm-[1-

It looks to me like "trailing dash" probably has a
complicated definition where some "-"(s) may exist
that are to be ignored after the one of interest.
In the example I'm guessing that the middle
"-" is intended (so "p5-CGI.pm-").


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: I've had a poudriere-devel bulk run on a Pine64+ 2GB get a: "Warning: Failed to acquire update_stats lock"

[Mark Millard via freebsd-ports]

[Some more notes after looking around.]

On 2018-Aug-16, at 10:04 AM, Mark Millard  wrote:

> I've no clue if this is significant or not, so I figured I'd
> report it in case it is. I've never seen one of these before.
> See the "[10:59:31]" line below if you care about the warning.
> 
> . . .
> [04:59:38] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_2
> load: 4.53  cmd: sh 57158 [nanslp] 19949.18r 28.74u 71.38s 0% 1040k
> [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Queued: 
> 117 Built: 67  Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 50   Time: 
> 05:32:29
>   [01]: devel/llvm60  | llvm60-6.0.1_2build   
> (00:23:53 / 00:34:35)
> [05:34:13] Logs: 
> /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_17h46m18s
> load: 5.72  cmd: sh 46862 [runnable] 0.07r 0.00u 0.00s 0% 0k
> [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Queued: 
> 117 Built: 67  Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 50   Time: 
> 10:57:17
>   [01]: devel/llvm60  | llvm60-6.0.1_2build   
> (05:48:41 / 05:59:23)
> [10:59:01] Logs: 
> /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_17h46m18s
> [10:59:31] Warning: Failed to acquire update_stats lock
> load: 4.06  cmd: sh 65361 [piperd] 56707.61r 0.39u 0.65s 0% 408k
> [FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Queued: 
> 117 Built: 67  Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 50   Time: 
> 15:48:05
>   [01]: devel/llvm60  | llvm60-6.0.1_2build   
> (10:39:29 / 10:50:11)
> [15:49:49] Logs: 
> /usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_17h46m18s
> 
> If it is significant, I do not know if it points at a
> poudriere-devel problem or an aarch64 problem or what.
> 
> Note: This poudreire-devel bulk run is still running
> and may well be for, say, another 8 hours or some such
> if it completes normally.
> 
> Some context details:
> 
> # uname -apKU
> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT  r337400M  arm64 aarch64 
> 1200076 1200076
> 
> # svnlite info /usr/ports/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 476715
> Last Changed Rev: 476715
> 
> I did the ports-mgmt/poudriere-devel rebuild and
> pkg update and upgrade sequence based on -r476715
> before again using poudreire-devel for the more
> general bulk build to update based on -r476715 .
> So the poudriere-devel is based on -r476715 instead
> of what I'm updating from.

Some 2016-April material around indicated that csh vfork
SAVESIGVEC code was leaking signal masks after spawn.

FYI: my root account is set up with a default of /bin/sh .
I do not normally use csh or tcsh:

# more /etc/master.passwd | grep root
root:. . .:/root:/bin/sh

(some material replaced with ". . .").

There are poudriere-devel related reports from back
then, such as:

https://lists.freebsd.org/pipermail/freebsd-pkg/2016-April/001575.html

and its continuation at:

https://lists.freebsd.org/pipermail/freebsd-pkg/2016-April/001578.html

which, in turn, points to the bugzilla report:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208132

with the csh detail.

Note: The bugzilla was started from other evidence of a
problem in 2016-March for a context not involving
poudreire-devel.

As stands, I've no other evidence of problems.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

I've had a poudriere-devel bulk run on a Pine64+ 2GB get a: "Warning: Failed to acquire update_stats lock"

[Mark Millard via freebsd-ports]

I've no clue if this is significant or not, so I figured I'd
report it in case it is. I've never seen one of these before.
See the "[10:59:31]" line below if you care about the warning.

. . .
[04:59:38] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_2
load: 4.53  cmd: sh 57158 [nanslp] 19949.18r 28.74u 71.38s 0% 1040k
[FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Queued: 
117 Built: 67  Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 50   Time: 
05:32:29
[01]: devel/llvm60  | llvm60-6.0.1_2build   
(00:23:53 / 00:34:35)
[05:34:13] Logs: 
/usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_17h46m18s
load: 5.72  cmd: sh 46862 [runnable] 0.07r 0.00u 0.00s 0% 0k
[FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Queued: 
117 Built: 67  Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 50   Time: 
10:57:17
[01]: devel/llvm60  | llvm60-6.0.1_2build   
(05:48:41 / 05:59:23)
[10:59:01] Logs: 
/usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_17h46m18s
[10:59:31] Warning: Failed to acquire update_stats lock
load: 4.06  cmd: sh 65361 [piperd] 56707.61r 0.39u 0.65s 0% 408k
[FBSDcortexA53jail-default] [2018-08-15_17h46m18s] [parallel_build:] Queued: 
117 Built: 67  Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 50   Time: 
15:48:05
[01]: devel/llvm60  | llvm60-6.0.1_2build   
(10:39:29 / 10:50:11)
[15:49:49] Logs: 
/usr/local/poudriere/data/logs/bulk/FBSDcortexA53jail-default/2018-08-15_17h46m18s

If it is significant, I do not know if it points at a
poudriere-devel problem or an aarch64 problem or what.

Note: This poudreire-devel bulk run is still running
and may well be for, say, another 8 hours or some such
if it completes normally.

Some context details:

# uname -apKU
FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT  r337400M  arm64 aarch64 
1200076 1200076

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 476715
Last Changed Rev: 476715

I did the ports-mgmt/poudriere-devel rebuild and
pkg update and upgrade sequence based on -r476715
before again using poudreire-devel for the more
general bulk build to update based on -r476715 .
So the poudriere-devel is based on -r476715 instead
of what I'm updating from.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

emulators/virtualbox-ose-additions-nox11 fails to build in poudriere-devel for amd64 context: fails CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE)

[Mark Millard via freebsd-ports]

The failure:

kBuild: Compiling VBoxGuestR0Lib - 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibPhysHeap.cpp
In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/GuestHost/HGSMI/HGSMIMemAlloc.cpp:55:
In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIMemAlloc.h:31:
In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIDefs.h:35:
In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/VBoxVideoIPRT.h:32:
In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45:
In file included from /usr/src/sys/sys/libkern.h:41:
In file included from /usr/src/sys/sys/systm.h:112:
/usr/src/sys/sys/pcpu.h:207:1: error: static_assert failed "compile-time 
assertion failed"
CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE);
^~~~
/usr/src/sys/sys/systm.h:107:21: note: expanded from macro 'CTASSERT'
#define CTASSERT(x) _Static_assert(x, "compile-time assertion failed")
^  ~

(There are other example places that fail the same assert condition.)

There is also a warning for PAGE_SIZE being redefined:

In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibInit.cpp:33:
In file included from 
/wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45:
In file included from /usr/src/sys/sys/libkern.h:41:
In file included from /usr/src/sys/sys/systm.h:111:
In file included from /usr/src/sys/sys/param.h:141:
/usr/include/machine/param.h:101:9: warning: 'PAGE_SIZE' macro redefined 
[-Wmacro-redefined]
#define PAGE_SIZE   (1

Re: emulators/virtualbox-ose-additions-nox11 fails to build in poudriere-devel for amd64 context: fails CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE)

[Mark Millard via freebsd-ports]

[The build got to emulators/virtualbox-ose-additions and it also
failed this way. The PAGE_SIZE warning did not occur. More notes
added after the quoted history.]

On 2018-Jul-15, at 7:49 AM, Mark Millard  wrote:

> The failure:
> 
> kBuild: Compiling VBoxGuestR0Lib - 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibPhysHeap.cpp
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/GuestHost/HGSMI/HGSMIMemAlloc.cpp:55:
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIMemAlloc.h:31:
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIDefs.h:35:
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/VBoxVideoIPRT.h:32:
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45:
> In file included from /usr/src/sys/sys/libkern.h:41:
> In file included from /usr/src/sys/sys/systm.h:112:
> /usr/src/sys/sys/pcpu.h:207:1: error: static_assert failed "compile-time 
> assertion failed"
> CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE);
> ^~~~
> /usr/src/sys/sys/systm.h:107:21: note: expanded from macro 'CTASSERT'
> #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed")
>^  ~
> 
> (There are other example places that fail the same assert condition.)
> 
> There is also a warning for PAGE_SIZE being redefined:
> 
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibInit.cpp:33:
> In file included from 
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45:
> In file included from /usr/src/sys/sys/libkern.h:41:
> In file included from /usr/src/sys/sys/systm.h:111:
> In file included from /usr/src/sys/sys/param.h:141:
> /usr/include/machine/param.h:101:9: warning: 'PAGE_SIZE' macro redefined 
> [-Wmacro-redefined]
> #define PAGE_SIZE   (1<^
> /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/param.h:52:10:
>  note: previous definition is here
> # define PAGE_SIZE  4096
> ^
> 
> 
> Context:
> 
> 
> # uname -apKU
> FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT  r336301M  amd64 amd64 
> 1200072 1200072
> 
> 
> 
> # svnlite info /usr/ports | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 474654
> Last Changed Rev: 474654
> 
> 
> 
> The "M" in r336301M is mostly for use with powerpc* family experiments based
> on modern C/C++ compilers:
> 
> # svnlite status /usr/src/ | sort
> ?   /usr/src/sys/amd64/conf/GENERIC-DBG
> ?   /usr/src/sys/amd64/conf/GENERIC-NODBG
> ?   /usr/src/sys/arm/conf/GENERIC-DBG
> ?   /usr/src/sys/arm/conf/GENERIC-NODBG
> ?   /usr/src/sys/arm64/conf/GENERIC-DBG
> ?   /usr/src/sys/arm64/conf/GENERIC-NODBG
> ?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
> ?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
> ?   /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
> ?   /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
> M   /usr/src/Makefile.libcompat
> M   /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
> M   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
> M   /usr/src/crypto/openssl/crypto/armcap.c
> M   /usr/src/lib/libkvm/kvm_powerpc.c
> M   /usr/src/lib/libkvm/kvm_private.c
> M   /usr/src/release/Makefile.vm
> M   /usr/src/release/scripts/mk-vmimage.sh
> M   /usr/src/release/tools/vmimage.subr
> M   /usr/src/secure/lib/libcrypto/Makefile
> M   /usr/src/stand/defs.mk
> M   /usr/src/stand/powerpc/boot1.chrp/Makefile
> M   /usr/src/stand/powerpc/kboot/Makefile
> M   /usr/src/sys/arm64/arm64/identcpu.c
> M   /usr/src/sys/conf/kmod.mk
> M   /usr/src/sys/conf/ldscript.powerpc
> M   /usr/src/sys/powerpc/aim/mmu_oea64.c
> M   /usr/src/sys/powerpc/ofw/ofw_machdep.c

emulators/virtualbox-ose-additions also got the error. But it did
not get the PAGE_SIZE warning.


There was also in both variants the likes of (3 times for each):

/wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.14/src/VBox/Runtime/common/asm/ASMSerializeInstruction-iret.asm:46:
 warning: `ss' segment register ignored in 64-bit mode


And there were lots of notices for:

warning: flexible array members are a C99 feature [-Wc99-extensions]
warning: 'register' storage class specifier is 

Re: aarch64-none-elf-gcc and related programs will not install

[Mark Millard via freebsd-ports]

Things seem to be in a confused state/status. Here is my limited understanding,
including what has me confused . . .

https://svnweb.freebsd.org/ports/head/devel/aarch64-none-elf-gcc/Makefile?revision=472670=markup
shows that this is a slave port of powerpc64-gcc :

17  MASTERDIR=  ${.CURDIR}/../powerpc64-gcc

(This looks to be true from when aarch64-none-elf-gcc/Makefile
was first checked in as well.)

As of -r465416 powerpc64-gcc recursively removes:

${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed

in post-install . (Other things are also removed.)

("include-fixed" tends to not track FreeBSD in a timely manor, for example.
I'll not get into all the issues that I'm aware of.)

But 
https://svnweb.freebsd.org/ports/head/devel/aarch64-none-elf-gcc/pkg-plist?revision=467716=markup
shows:

23  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/limits.h
24  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_fil.h
25  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_lookup.h
26  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_nat.h
27  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_proxy.h
28  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_scan.h
29  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_state.h
30  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/README
31  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stddef.h
32  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdio.h
33  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdlib.h
34  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/sys/types.h
35  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/syslimits.h
36  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/unistd.h
37  lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/wchar.h

and so has references to files that do not exist as far as I can tell
so far.

Most/all other slave ports of powerpc64-gcc have had such
references removed as I understand.

For example, -r437977 removed:

 lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/README 
 lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/limits.h   
 lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/syslimits.h

in devel/aarch64-gcc/pkg-plist .

But -r466699 (that included aarch64-none-elf-gcc changes) says:

Author: jhb
Date:   Sat Apr 7 00:26:46 2018 UTC (3 months ago)
Changed paths:  3
Log Message:
Fix two more issues with r465416

. . .
- Don't remove the include-fixed headers for the aarch64-none-elf-gcc
  and arm-none-eabi-gcc packages.
. . .

Reported by:kevans (2)
Reviewed by:bdrewery, kevans
Differential Revision:  
https://reviews.freebsd.org/D14925


( -r466699 is after -r465416 added the removal of include-fixed/.
Thus my confusion.)

There is also -r467716 which says:

Wed Apr 18 17:07:23 2018 UTC (2 months, 2 weeks ago) by kevans 
File size: 29483 byte(s)
Fix arm-none-eabi-gcc/aarch64-none-elf-gcc plist after r466699

jhb fixed these ports in r466699, but include-fixed headers has changed
since the last update, perhaps due to --sysroot and these ports being built
differently since then.

Add the extra headers to the plist and bump PORTREVISION due to package
differences. This fixes some sanity checking in the plist, since these files
are installed to the stage dir.

Reported by:Phillip R. Jaenke 
Approved by:ler (ports)
MFH:2018Q2



(This also confuses me, given when powerpc64-gcc [the master
port] started removing include-fixed well before this.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: aarch64-none-elf-gcc and related programs will not install

[Mark Millard via freebsd-ports]

On 2018-Jul-9, at 9:13 AM, John Baldwin  wrote:

> On 7/7/18 5:56 PM, Mark Millard wrote:
>> Things seem to be in a confused state/status. Here is my limited 
>> understanding,
>> including what has me confused . . .
>> 
>> https://svnweb.freebsd.org/ports/head/devel/aarch64-none-elf-gcc/Makefile?revision=472670=markup
>> shows that this is a slave port of powerpc64-gcc :
>> 
>> 17   MASTERDIR=  ${.CURDIR}/../powerpc64-gcc
>> 
>> (This looks to be true from when aarch64-none-elf-gcc/Makefile
>> was first checked in as well.)
>> 
>> As of -r465416 powerpc64-gcc recursively removes:
>> 
>> ${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed
>> 
>> in post-install . (Other things are also removed.)
>> 
>> ("include-fixed" tends to not track FreeBSD in a timely manor, for example.
>> I'll not get into all the issues that I'm aware of.)
>> 
>> But 
>> https://svnweb.freebsd.org/ports/head/devel/aarch64-none-elf-gcc/pkg-plist?revision=467716=markup
>> shows:
>> 
>> 23   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/limits.h
>> 24   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_fil.h
>> 25   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_lookup.h
>> 26   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_nat.h
>> 27   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_proxy.h
>> 28   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_scan.h
>> 29   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/netinet/ip_state.h
>> 30   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/README
>> 31   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stddef.h
>> 32   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdio.h
>> 33   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/stdlib.h
>> 34   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/sys/types.h
>> 35   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/syslimits.h
>> 36   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/unistd.h
>> 37   lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/wchar.h
>> 
>> and so has references to files that do not exist as far as I can tell
>> so far.
>> 
>> Most/all other slave ports of powerpc64-gcc have had such
>> references removed as I understand.
>> 
>> For example, -r437977 removed:
>> 
>> lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/README   
>> lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/limits.h 
>> lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/include-fixed/syslimits.h
>> 
>> in devel/aarch64-gcc/pkg-plist .
>> 
>> But -r466699 (that included aarch64-none-elf-gcc changes) says:
>> 
>> Author:  jhb
>> Date:Sat Apr 7 00:26:46 2018 UTC (3 months ago)
>> Changed paths:   3
>> Log Message: 
>> Fix two more issues with r465416
>> 
>> . . .
>> - Don't remove the include-fixed headers for the aarch64-none-elf-gcc
>>  and arm-none-eabi-gcc packages.
>> . . .
>> 
>> Reported by: kevans (2)
>> Reviewed by: bdrewery, kevans
>> Differential Revision:   
>> https://reviews.freebsd.org/D14925
> 
> This made the RM conditional if you look at the diff:
> 
> .if empty(PKGNAMEPREFIX:M*-*-)
>@${RM} -r 
> ${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include-fixed
> .endif
> 
> The conditional should only apply to xtoolchain gcc ports (e.g. amd64-gcc)
> not to aarch64-none-elf-gcc.
> 
> I don't have the context from the start of this thread to know what is broken
> though.

Somehow I missed the conditional code. Sorry.

https://svnweb.freebsd.org/ports/branches/2018Q2/devel/ goes
back to -r466125 before the conditional was added.

It looks like https://svnweb.freebsd.org/ports/branches/2018Q3/devel/
was only established about 7 days ago as/at -r473710 .

So if the quarterly 2018Q2 was in use at the time, that would explain
the types messages.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: svn commit: r466933 - head/devel/amd64-binutils

[Mark Millard via freebsd-ports]

On 2018-Apr-13, at 8:09 PM, Mark Millard  wrote:

>> Author: kan
>> Date: Tue Apr 10 01:00:30 2018
>> New Revision: 466933
>> URL: 
>> https://svnweb.freebsd.org/changeset/ports/466933
>> 
>> 
>> Log:
>>  Catch up with changed binutils prefix
>> 
>> . . .
>> -BUTARGET=   x86_64-${OPSYS:tl}
>> +BUTARGET=   x86_64-unknown-${OPSYS:tl}${OSREL}
> 
> Should something have been done to force the port
> to rebuild after a svnlite update picks up this
> change? The change has significant file name
> differences in what would be installed but poudriere
> bulk did not classify my reference to
> devel/amd64-xtoolchain-gcc as needing to update
> devel/amd64-binutils .

Forcing devel/amd64-binutils to build worked.

But afterwards devel/amd64-gcc fails to build because:

. . .
===
===>   amd64-gcc-6.3.0_3 depends on executable: x86_64-freebsd-as - not found
===>   Installing existing package /packages/All/amd64-binutils-2.30_2,1.txz
[FBSDFSSDjailVariant] Installing amd64-binutils-2.30_2,1...
[FBSDFSSDjailVariant] Extracting amd64-binutils-2.30_2,1: .. done
===>   amd64-gcc-6.3.0_3 depends on executable: x86_64-freebsd-as - not found
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/amd64-gcc
=>> Cleaning up wrkdir
===>  Cleaning for amd64-gcc-6.3.0_3
build of devel/amd64-gcc | amd64-gcc-6.3.0_3 ended at Fri Apr 13 20:58:39 PDT 
2018
build time: 00:01:16
!!! build failure encountered !!!


This looks to be because of BU_PREFIX in
devel/amd64-gcc/Makefile :

GCC_TARGET= x86_64-unknown-${OPSYS:tl}${OSREL}
BU_PREFIX=  x86_64-${OPSYS:tl}

devel/powerpc64-gcc (the master) shows the normal
structure is:

.if empty(GCC_TARGET)
# We are building for a FreeBSD target
GCC_TARGET?=${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
BU_PREFIX?= ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
EXTRA_PATCHES+= ${FILESDIR}/freebsd-format-extensions
. . .

amd64 does need the x86_64- part of what it has but the
suffix after that needs the unknown-${OPSYS:tl}${OSREL}
part as well.

Again, forcing an update after a svn update picks up
such a change is likely appropriate.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: svn commit: r466933 - head/devel/amd64-binutils

[Mark Millard via freebsd-ports]

> Author: kan
> Date: Tue Apr 10 01:00:30 2018
> New Revision: 466933
> URL: 
> https://svnweb.freebsd.org/changeset/ports/466933
> 
> 
> Log:
>   Catch up with changed binutils prefix
> 
> . . .
> -BUTARGET=x86_64-${OPSYS:tl}
> +BUTARGET=x86_64-unknown-${OPSYS:tl}${OSREL}

Should something have been done to force the port
to rebuild after a svnlite update picks up this
change? The change has significant file name
differences in what would be installed but poudriere
bulk did not classify my reference to
devel/amd64-xtoolchain-gcc as needing to update
devel/amd64-binutils .


===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

head amd64->aarch64 buildkernel: clang using aarch64-binutils gets /tmp/cloudabi_vdso_armv6_on_64bit-2f26ed.o: error adding symbols: File in wrong format

[Mark Millard via freebsd-ports]

(Context: buildworld completed before builkernel started.)

My attempt to do buildworld buildkernel via clang but using
aarch64-binutils got the following failure during buildkernel.

(Note the use of: -B/usr/local/aarch64-unknown-freebsd12.0/bin/
for clang.)

--- cloudabi32_vdso.o ---
/tmp/cloudabi_vdso_armv6_on_64bit-2f26ed.o: error adding symbols: File in wrong 
format
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [cloudabi32_vdso.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/cloudabi32
.ERROR_TARGET='cloudabi32_vdso.o'
.ERROR_META_FILE='/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/modules/usr/src/sys/modules/cloudabi32/cloudabi32_vdso.o.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='cc -B/usr/local/aarch64-unknown-freebsd12.0/bin/ -mcpu=cortex-a53 
-target aarch64-unknown-freebsd12.0 
--sysroot=/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/tmp
 -B/usr/local/aarch64-unknown-freebsd12.0/bin/ -x assembler-with-cpp -m32 
-shared -nostdinc -nostdlib  
-Wl,-T/usr/src/sys/compat/cloudabi/cloudabi_vdso.lds  
/usr/src/sys/contrib/cloudabi/cloudabi_vdso_armv6_on_64bit.S -o 
cloudabi32_vdso.o;'
.CURDIR='/usr/src/sys/modules/cloudabi32'
.MAKE='make'
.OBJDIR='/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/modules/usr/src/sys/modules/cloudabi32'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='arm64'
MACHINE_ARCH='aarch64'
MAKEOBJDIRPREFIX='/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/modules'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20180222'
PATH='/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG/modules/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk 
/root/src.configs/src.conf.cortexA53-clang-xbinutils-bootstrap.amd64-host 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk 
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk 
/root/src.configs/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/cloudabi32/Makefile 
/usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/sys/modules/cloudabi32/../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk 
/usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/s
 hare/mk/bsd.subdir.mk /usr/src/sys/conf/kern.mk'
.PATH='. /usr/src/sys/modules/cloudabi32 /usr/src/sys/compat/cloudabi32 
/usr/src/sys/arm64/cloudabi32 
/usr/obj/cortexA53_clang_xbinutils/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG'
1 error


For reference:

# uname -apKU
FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT  r332181M  amd64 amd64 
1200061 1200061

# pkg info "*binutils"
aarch64-binutils-2.30_2,1
amd64-binutils-2.30_2,1
binutils-2.30_2,1
powerpc64-binutils-2.30_2,1

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 466704
Last Changed Rev: 466704

buildworld buildkernel with clang using its default
utilities completed.

===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Attempting a xtoolchain-gcc head amd64->aarch64 cross buildworld failed for liblto_plugin.so loading error

[Mark Millard via freebsd-ports]

My attempted, xtoolchain-gcc based, amd64->aarch64 cross-buildworld-buildkernel 
failed with:

--- libc.so.7.full ---
/usr/local/bin/aarch64-unknown-freebsd12.0-ld: 
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so: 
error loading plugin: Service unavailable
collect2: error: ld returned 1 exit status
*** [libc.so.7.full] Error code 1

(I've not attempted such a build in a long time, so I do not
know how new this is. Historically I've done lots of such
builds. cortex-a53 was specifically targeted here.)

For reference:

# uname -apKU
FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT  r332181M  amd64 amd64 
1200061 1200061

# pkg info "*binutils"
aarch64-binutils-2.30_2,1
amd64-binutils-2.30_2,1
binutils-2.30_2,1
powerpc64-binutils-2.30_2,1

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 466704
Last Changed Rev: 466704

# file /usr/local/libexec/gcc/*/*/liblto*
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:  
   symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0:
   symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0.0.0:
   ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically 
linked, with debug_info, not stripped
/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:
   symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0:  
   symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0.0.0:
 ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, 
with debug_info, not stripped
/usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:   
   symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0: 
   symbolic link to liblto_plugin.so.0.0.0
/usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0.0.0: 
   ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically 
linked, with debug_info, not stripped



make[4]: stopped in /usr/src/lib/libc
.ERROR_TARGET='libc.so.7.full'
.ERROR_META_FILE='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/lib/libc/libc.so.7.full.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='@echo building shared library libc.so.7; @rm -f libc.so.7 libc.so; 
/usr/local/bin/aarch64-unknown-freebsd12.0-gcc -mcpu=cortex-a53 -isystem 
/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/include
 
-L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/lib
 
-B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/lib
 
--sysroot=/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp
 -B/usr/local/aarch64-unknown-freebsd12.0/bin/  -nodefaultlibs 
-Wl,--version-script=Version.map  -shared -Wl,-x -Wl,--fatal-warnings 
-Wl,--warn-shared-textrel  -o libc.so.7.full -Wl,-soname,libc.so.7  
`NM='/usr/local/aarch64-unknown-freebsd12.0/bin/nm' NMFLAGS='' lorder 
machdep_ldisQ.pico
. . .
wcspbrk.pico wcsrchr.pico wcsspn.pico wcsstr.pico wcstok.pico wcswidth.pico 
wcsxfrm.pico wmemchr.pico wmemcmp.pico wmemcpy.pico wmemmove.pico wmemset.pico 
|  tsort -q`  -lcompiler_rt  -lssp_nonshared;'
.CURDIR='/usr/src/lib/libc'
.MAKE='make'
.OBJDIR='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/lib/libc'
.TARGETS='all'
DESTDIR='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp'
LD_LIBRARY_PATH=''
MACHINE='arm64'
MACHINE_ARCH='aarch64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20180222'
PATH='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk 
/root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk 
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk 
/root/src.configs/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /dev/null 

Re: Attempting a xtoolchain-gcc head amd64->aarch64 cross buildworld failed for liblto_plugin.so loading error

[Mark Millard via freebsd-ports]

On 2018-Apr-7, at 3:35 PM, Alexander Kabaev  wrote:

> On Sat, 7 Apr 2018 15:23:50 -0700
> Mark Millard via freebsd-arm  wrote:
> 
>> My attempted, xtoolchain-gcc based, amd64->aarch64
>> cross-buildworld-buildkernel failed with:
>> 
>> --- libc.so.7.full ---
>> /usr/local/bin/aarch64-unknown-freebsd12.0-ld: 
>> /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:
>> error loading plugin: Service unavailable collect2: error: ld
>> returned 1 exit status *** [libc.so.7.full] Error code 1
>> 
>> (I've not attempted such a build in a long time, so I do not
>> know how new this is. Historically I've done lots of such
>> builds. cortex-a53 was specifically targeted here.)
>> . . .
> 
> IIRC, I had to disable LTO plugin in binutils and this need to
> disable it was there for a while. 

Hmm . . .

# pkg info aarch64-binutils
aarch64-binutils-2.30_2,1
Name   : aarch64-binutils
Version: 2.30_2,1
Installed on   : Tue Feb  6 17:37:31 2018 PST
Origin : devel/aarch64-binutils
Architecture   : FreeBSD:12:amd64
Prefix : /usr/local
Categories : devel
Licenses   : GPLv3, LGPL3
Maintainer : bapt at FreeBSD.org
WWW: http://sources.redhat.com/binutils/
Comment: GNU binutils for AArch64 cross-development
Options:
RELRO  : off
STATIC : on
. . . (no more options listed) . . .

# poudriere options -jFBSDFSSDjail -s devel/aarch64-binutils
[00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
===> The following configuration options are available for 
aarch64-binutils-2.30_2,1:
 RELRO=off: enable -z relro in ELF linker by default
 STATIC=on: Build static executables and/or libraries
===> Use 'make config' to modify these settings
. . .


Controlling LTO's presence via my port build does
not seem to be the way to disable LTO.

This would suggest that I need to override part
of what buildworld does in order to force avoiding
lto. Such would be the first time that I've run
into that.

Looks like I've some research to do for how.

Thanks for letting me know.


===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Attempting a xtoolchain-gcc head amd64->aarch64 cross buildworld failed for liblto_plugin.so loading error

[Mark Millard via freebsd-ports]

[The static build of binutils is what gets the lto involved.]

On 2018-Apr-7, at 5:29 PM, Mark Millard  wrote:

> On 2018-Apr-7, at 3:35 PM, Alexander Kabaev  wrote:
> 
>> On Sat, 7 Apr 2018 15:23:50 -0700
>> Mark Millard via freebsd-arm  wrote:
>> 
>>> My attempted, xtoolchain-gcc based, amd64->aarch64
>>> cross-buildworld-buildkernel failed with:
>>> 
>>> --- libc.so.7.full ---
>>> /usr/local/bin/aarch64-unknown-freebsd12.0-ld: 
>>> /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:
>>> error loading plugin: Service unavailable collect2: error: ld
>>> returned 1 exit status *** [libc.so.7.full] Error code 1
>>> 
>>> (I've not attempted such a build in a long time, so I do not
>>> know how new this is. Historically I've done lots of such
>>> builds. cortex-a53 was specifically targeted here.)
>>> . . .
>> 
>> IIRC, I had to disable LTO plugin in binutils and this need to
>> disable it was there for a while. 
> 
> Hmm . . .
> 
> # pkg info aarch64-binutils
> aarch64-binutils-2.30_2,1
> Name   : aarch64-binutils
> Version: 2.30_2,1
> Installed on   : Tue Feb  6 17:37:31 2018 PST
> Origin : devel/aarch64-binutils
> Architecture   : FreeBSD:12:amd64
> Prefix : /usr/local
> Categories : devel
> Licenses   : GPLv3, LGPL3
> Maintainer : bapt at FreeBSD.org
> WWW: http://sources.redhat.com/binutils/
> Comment: GNU binutils for AArch64 cross-development
> Options:
>RELRO  : off
>STATIC : on
> . . . (no more options listed) . . .
> 
> # poudriere options -jFBSDFSSDjail -s devel/aarch64-binutils
> [00:00:00] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
> ===> The following configuration options are available for 
> aarch64-binutils-2.30_2,1:
> RELRO=off: enable -z relro in ELF linker by default
> STATIC=on: Build static executables and/or libraries
> ===> Use 'make config' to modify these settings
> . . .
> 
> 
> Controlling LTO's presence via my port build does
> not seem to be the way to disable LTO.
> 
> This would suggest that I need to override part
> of what buildworld does in order to force avoiding
> lto. Such would be the first time that I've run
> into that.
> 
> Looks like I've some research to do for how.
> 
> Thanks for letting me know.

I had forgotten but I'd analyzed this once before:

https://lists.freebsd.org/pipermail/freebsd-ports/2017-August/109769.html

and it traced back to:

 STATIC=on: Build static executables and/or libraries

for aarch64-binutils. (Static was at the time required for
a poudriere/qemu mix that used aarch64-binutils.)

(I do-not/did-not see such problems for powerpc64 targeted cross
builds using xtoolchain material, such as powerpc64-binutils
and powerpc64-gcc. This is specific to aarch64 for some
reason.)

So I'll see about turning STATIC off to enable buildworld.

===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

aarch64-none-elf-gcc V6.3.0_2 from -r465491 fails to package because of 3 referenced-but-missing include-fixed files (amd64 context)

[Mark Millard via freebsd-ports]

# svnlite info /usr/ports/ | grep "^Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 465491

via a poudrirere-devel bulk -a run:

===>  Building package for aarch64-none-elf-gcc-6.3.0_2
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.3.0/include-fixed/README:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.3.0/include-fixed/limits.h:No
 such file or directory
pkg-static: Unable to access file 
/wrkdirs/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.3.0/include-fixed/syslimits.h:No
 such file or directory
*** Error code 1


Context:

# uname -apKU
FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT  r331499M  amd64 amd64 
1200060 1200060

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Two example patches: enable powerpc64 builds of devel/powerpc64-gcc and lang/gcc8 via system-clang ( avoiding clang's reserving vec_step )

[Mark Millard via freebsd-ports]

[I experiment with using modern compilers on
powerpc64, here buildworld buildkernel was
via devel/powerpc64-xtoolchain-gcc but included
building clang and having clang as cc. clang's
problems are tied to aspects of buildworld
buildkernel but is otherwise usable.]

When clang is built with support for altivec
for powerpc* (powerpc64 here) and such it
reserves a name not from the C/C++ language
standards: vec_step .

system-clang has enough enabled for powerpc64
to have reserved vec_step.

If devel/llvm* ever enable enough powerpc64
support they would reserve vec_step too. (I've
not checked if this is already happening.)

Unfortunately, various devel/*gcc and lang/gcc*
use that name in gcc/tree-vect-loop.c and so on
powerpc64 those various *gcc* fail to build.

The below just avoids the extra reserved word
by renaming each non-comment vec_step in
gcc/tree-vect-loop.c to vec_step_renamed . This
has allowed me to build the example *gcc* 's in
poudriere-devel on powerpc64 (head -r339076
based).

One could imagine sed'ing or otherwise processing
gcc/tree-vect-loop.c instead of having patch files.
In the examples the original gcc/tree-vect-loop.c
files are not the same: one patch for all *gcc*
would not work.

# svnlite status /usr/ports/devel/powerpc64-gcc/files/ | more
?   /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c

# svnlite status /usr/ports/lang/gcc8/files/ | more
?   /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c

# more /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c
--- gcc/tree-vect-loop.c.orig   2017-03-28 15:35:56 UTC
+++ gcc/tree-vect-loop.c
@@ -3832,7 +3832,7 @@ get_initial_def_for_induction (gimple *iv_phi)
   edge pe = loop_preheader_edge (loop);
   struct loop *iv_loop;
   basic_block new_bb;
-  tree new_vec, vec_init, vec_step, t;
+  tree new_vec, vec_init, vec_step_renamed, t;
   tree new_name;
   gimple *new_stmt;
   gphi *induction_phi;
@@ -3986,7 +3986,7 @@ get_initial_def_for_induction (gimple *iv_phi)
   stepvectype = get_vectype_for_scalar_type (TREE_TYPE (new_name));
   gcc_assert (stepvectype);
   new_vec = build_vector_from_val (stepvectype, t);
-  vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
+  vec_step_renamed = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
 
 
   /* Create the following def-use cycle:
@@ -4008,7 +4008,7 @@ get_initial_def_for_induction (gimple *iv_phi)
   induc_def = PHI_RESULT (induction_phi);
 
   /* Create the iv update inside the loop  */
-  new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, vec_step);
+  new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, 
vec_step_renamed);
   vec_def = make_ssa_name (vec_dest, new_stmt);
   gimple_assign_set_lhs (new_stmt, vec_def);
   gsi_insert_before (, new_stmt, GSI_SAME_STMT);
@@ -4049,7 +4049,7 @@ get_initial_def_for_induction (gimple *iv_phi)
   gcc_assert (CONSTANT_CLASS_P (new_name)
  || TREE_CODE (new_name) == SSA_NAME);
   new_vec = build_vector_from_val (stepvectype, t);
-  vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
+  vec_step_renamed = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
 
   vec_def = induc_def;
   prev_stmt_vinfo = vinfo_for_stmt (induction_phi);
@@ -4057,7 +4057,7 @@ get_initial_def_for_induction (gimple *iv_phi)
{
  /* vec_i = vec_prev + vec_step  */
  new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR,
- vec_def, vec_step);
+ vec_def, vec_step_renamed);
  vec_def = make_ssa_name (vec_dest, new_stmt);
  gimple_assign_set_lhs (new_stmt, vec_def);
  
@@ -6324,13 +6324,13 @@ vectorizable_reduction (gimple *stmt, gimple_stmt_iter
 
  /* Create a vector of the step value.  */
  tree step = build_int_cst (cr_index_scalar_type, nunits_out);
- tree vec_step = build_vector_from_val (cr_index_vector_type, step);
+ tree vec_step_renamed = build_vector_from_val (cr_index_vector_type, 
step);
 
  /* Create an induction variable.  */
  gimple_stmt_iterator incr_gsi;
  bool insert_after;
  standard_iv_increment_position (loop, _gsi, _after);
- create_iv (series_vect, vec_step, NULL_TREE, loop, _gsi,
+ create_iv (series_vect, vec_step_renamed, NULL_TREE, loop, _gsi,
 insert_after, _before_incr, _after_incr);
 
  /* Next create a new phi node vector (NEW_PHI_TREE) which starts


# more /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c
--- gcc/tree-vect-loop.c.orig   2018-10-10 22:41:40.295753000 -0700
+++ gcc/tree-vect-loop.c2018-10-10 22:57:44.698855000 -0700
@@ -4970,13 +4970,13 @@
 
   /* Create a vector of the step value.  */
   tree step = build_int_cst (cr_index_scalar_type, nunits_out);
-  tree vec_step = build_vector_from_val (cr_index_vector_type, step);
+  tree vec_step_renamed 

multimedia/gstreamer1-libav building via system-clang on powerpc64 broken: cc: error: unknown argument: '-mminimal-toc'

[Mark Millard via freebsd-ports]

[I experiment with using modern compilers on
powerpc64, here buildworld buildkernel was
via devel/powerpc64-xtoolchain-gcc but included
building clang and having clang as cc. clang's
problems are tied to aspects of buildworld
buildkernel but is otherwise usable.]

/usr/ports is at -r480180 for the below.

The poudriere-devel error log reported:

checking whether the C compiler works... no
configure: error: in 
`/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.12.3':
configure: error: C compiler cannot create executables
See `config.log' for more details
===>  Script "configure" failed unexpectedly.
Please report the problem to multime...@freebsd.org [maintainer] and attach
the
"/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.12.3/config.log"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/multimedia/gstreamer1-libav
=>> Cleaning up wrkdir
===>  Cleaning for gstreamer1-libav-1.12.3_2
build of multimedia/gstreamer1-libav | gstreamer1-libav-1.12.3_2 ended at Fri 
Oct 12 03:49:50 PDT 2018
build time: 00:02:10
!!! build failure encountered !!!



And config.log reported something very simple: use
of a command line option that does not exist for
clang.

configure:4016: checking whether the C compiler works
configure:4038: cc -O2 -pipe  -g -isystem /usr/local/include 
-fno-strict-aliasing -mminimal-toc -isystem /usr/local/include   conftest.c 
-L/usr/local/lib >&5
cc: error: unknown argument: '-mminimal-toc'
configure:4042: $? = 1
configure:4080: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GStreamer libav"
| #define PACKAGE_TARNAME "gst-libav"
| #define PACKAGE_VERSION "1.12.3"
| #define PACKAGE_STRING "GStreamer libav 1.12.3"
| #define PACKAGE_BUGREPORT 
"http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer;
| #define PACKAGE_URL ""
| #define PACKAGE "gst-libav"
| #define VERSION "1.12.3"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:4085: error: in 
`/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.12.3':
configure:4088: error: C compiler cannot create executables
See `config.log' for more details



For reference:

[19:06:38] [01] [00:02:24] Saved multimedia/gstreamer1-libav | 
gstreamer1-libav-1.12.3_2 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDpowerpc64-default/default/gstreamer1-libav-1.12.3_2.tbz
[19:06:38] [01] [00:02:24] Finished multimedia/gstreamer1-libav | 
gstreamer1-libav-1.12.3_2: Failed: configure
[19:06:39] [01] [00:02:25] Skipping multimedia/gstreamer1-plugins-core | 
gstreamer1-plugins-core-1.12: Dependent port multimedia/gstreamer1-libav | 
gstreamer1-libav-1.12.3_2 failed



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

[I have a work around for the specific activity to avoid
the hang.]

On 2018-Oct-27, at 6:00 PM, Mark Millard  wrote:

> [The bigger test still hung up.]
> 
> On 2018-Oct-27, at 5:30 PM, Mark Millard  wrote:
> 
>> [Just the __packed removal patch was sufficient to no longer
>> have the hang problem that I originally reported for the
>> print/texinfo build in poudriere.]
>> 
>> On 2018-Oct-27, at 4:33 PM, Mark Millard  wrote:
>> 
>>> [Some of this discussion occurred off list. The point here
>>> is not specific to the hang that I originally reported.]
>>> 
>>> On 2018-Oct-27, at 3:03 PM, Mark Millard  wrote:
 
>> 
>> Mikaël Urankar is being quoted below:
>> 
> . . .
> 
>> There are bugs in qemu that can cause such deadlock, you can try these
>> 2 patches:
>> https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6baa45fdbe0dbb56a7371
>> https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b
>> 
>> Back to me:
>> 
> I'll try those later. Thanks. (I need to get back to sleep.)
> 
> It was interesting that attach/detach to the ld process
> caused it to progress. The rest of the build completed
> just fine. But that one spot consistently hung up before
> trying gdb to look at the back trace.
> 
 
 Looking at the qemu code related to the 2nd patch: the
 structure of the field copies (via __get_user) seems
 very sensitive to the ABI rules for the target and
 how things align and such, given that the structure
 description and code are host code. __packed vs. not
 is possibly not sufficient control to always make things
 match right across all the potential combinations of
 host and target from what I can see.
 
 Lack of __packed may prove sufficient for my specific
 context (amd64 host and armv7 target) but it seems
 non-obvious what to do in general.
 
 There would also seem to be big endian vs. little endian
 issues on the individual __get_user styles of copies
 when the host and target do not match for a multi-byte
 numeric encoding.
>>> 
>>> Well, I get the following for:
>>> 
>>> #include "/usr/include/sys/event.h" // kevent
>>> #include  // offsetof
>>> #include   // printf
>>> 
>>> int
>>> main()
>>> {
>>>  printf("%lu\n", (unsigned long) sizeof(struct kevent));
>>>  printf("ident %lu\n", (unsigned long) offsetof(struct kevent, ident));
>>>  printf("filter %lu\n", (unsigned long) offsetof(struct kevent, 
>>> filter));
>>>  printf("flags %lu\n", (unsigned long) offsetof(struct kevent, flags));
>>>  printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, 
>>> fflags));
>>>  printf("data %lu\n", (unsigned long) offsetof(struct kevent, data));
>>>  printf("udata %lu\n", (unsigned long) offsetof(struct kevent, udata));
>>>  printf("ext %lu\n", (unsigned long) offsetof(struct kevent, ext));
>>>  return 0;
>>> }
>>> 
>>> (This code avoided warnings for type mismatches with the
>>> printf strings and such.)
>>> 
>>> amd64 native [host of qemu use] (comments hand added):
>>> 
>>> # ./a.out
>>> 64
>>> ident 0
>>> filter 8  // NOTE!
>>> flags 10  // NOTE!
>>> fflags 12 // NOTE!
>>> data 16
>>> udata 24
>>> ext 32
>>> 
>>> (The above is not particularly important but I
>>> include it for completeness.)
>>> 
>>> armv7 native [target in qemu use] (comments hand added):
>>> 
>>> # ./a.out
>>> 64   // NOTE vs. below!
>>> ident 0
>>> filter 4 // NOTE vs. above!
>>> flags 6  // NOTE vs. above!
>>> fflags 8 // NOTE vs. above!
>>> data 16  // NOTE vs. below!
>>> udata 24 // NOTE vs. below!
>>> ext 32   // NOTE vs. below!
>>> 
>>> /usr/include/sys/event.h lacks __packed in both cases.
>>> 
>>> With __packed in qemu-arm-static's source code
>>> for target_freebsd_kevent I confirm that via
>>> gdb for the qemu-arm-static:
>>> 
>>> p/d sizeof(struct target_freebsd_kevent)
>>> p/d &((struct target_freebsd_kevent *)0)->ident
>>> p/d &((struct target_freebsd_kevent *)0)->filter
>>> p/d &((struct target_freebsd_kevent *)0)->flags
>>> p/d &((struct target_freebsd_kevent *)0)->fflags
>>> p/d &((struct target_freebsd_kevent *)0)->data
>>> p/d &((struct target_freebsd_kevent *)0)->udata
>>> p/d &((struct target_freebsd_kevent *)0)->ext
>>> 
>>> reports as the 2nd patch's problem-report
>>> material reports (56,0,4,6,8,12,20,24): not
>>> even the right size.
>>> 
>>> I also confirm that removing __packed in qemu's
>>> code and rebuilding and then checking with gdb
>>> reported a match to the above armv7 native report
>>> (64,0,4,6,8,16,24,32).
>>> 
>>> I have not verified __packed used vs. not for any
>>> other combination of host and target platforms.
>> 
>> Removing the 2 examples of __packed, including the
>> 1 for target_freebsd_kevent, as in Mikaël Urankar's
>> 2nd listed patch, was sufficient to avoid the hang
>> that I originally reported. (Technically FreeBSD 11
>> is not involved and so one of the 

Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

[Just the __packed removal patch was sufficient to no longer
have the hang problem that I originally reported for the
print/texinfo build in poudriere.]

On 2018-Oct-27, at 4:33 PM, Mark Millard  wrote:

> [Some of this discussion occurred off list. The point here
> is not specific to the hang that I originally reported.]
> 
> On 2018-Oct-27, at 3:03 PM, Mark Millard  wrote:
>> 

Mikaël Urankar is being quoted below:

>>> . . .
>>> 
 There are bugs in qemu that can cause such deadlock, you can try these
 2 patches:
 https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6baa45fdbe0dbb56a7371
 https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b

Back to me:

>>> I'll try those later. Thanks. (I need to get back to sleep.)
>>> 
>>> It was interesting that attach/detach to the ld process
>>> caused it to progress. The rest of the build completed
>>> just fine. But that one spot consistently hung up before
>>> trying gdb to look at the back trace.
>>> 
>> 
>> Looking at the qemu code related to the 2nd patch: the
>> structure of the field copies (via __get_user) seems
>> very sensitive to the ABI rules for the target and
>> how things align and such, given that the structure
>> description and code are host code. __packed vs. not
>> is possibly not sufficient control to always make things
>> match right across all the potential combinations of
>> host and target from what I can see.
>> 
>> Lack of __packed may prove sufficient for my specific
>> context (amd64 host and armv7 target) but it seems
>> non-obvious what to do in general.
>> 
>> There would also seem to be big endian vs. little endian
>> issues on the individual __get_user styles of copies
>> when the host and target do not match for a multi-byte
>> numeric encoding.
> 
> Well, I get the following for:
> 
> #include "/usr/include/sys/event.h" // kevent
> #include  // offsetof
> #include   // printf
> 
> int
> main()
> {
>printf("%lu\n", (unsigned long) sizeof(struct kevent));
>printf("ident %lu\n", (unsigned long) offsetof(struct kevent, ident));
>printf("filter %lu\n", (unsigned long) offsetof(struct kevent, 
> filter));
>printf("flags %lu\n", (unsigned long) offsetof(struct kevent, flags));
>printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, 
> fflags));
>printf("data %lu\n", (unsigned long) offsetof(struct kevent, data));
>printf("udata %lu\n", (unsigned long) offsetof(struct kevent, udata));
>printf("ext %lu\n", (unsigned long) offsetof(struct kevent, ext));
>return 0;
> }
> 
> (This code avoided warnings for type mismatches with the
> printf strings and such.)
> 
> amd64 native [host of qemu use] (comments hand added):
> 
> # ./a.out
> 64
> ident 0
> filter 8  // NOTE!
> flags 10  // NOTE!
> fflags 12 // NOTE!
> data 16
> udata 24
> ext 32
> 
> (The above is not particularly important but I
> include it for completeness.)
> 
> armv7 native [target in qemu use] (comments hand added):
> 
> # ./a.out
> 64   // NOTE vs. below!
> ident 0
> filter 4 // NOTE vs. above!
> flags 6  // NOTE vs. above!
> fflags 8 // NOTE vs. above!
> data 16  // NOTE vs. below!
> udata 24 // NOTE vs. below!
> ext 32   // NOTE vs. below!
> 
> /usr/include/sys/event.h lacks __packed in both cases.
> 
> With __packed in qemu-arm-static's source code
> for target_freebsd_kevent I confirm that via
> gdb for the qemu-arm-static:
> 
> p/d sizeof(struct target_freebsd_kevent)
> p/d &((struct target_freebsd_kevent *)0)->ident
> p/d &((struct target_freebsd_kevent *)0)->filter
> p/d &((struct target_freebsd_kevent *)0)->flags
> p/d &((struct target_freebsd_kevent *)0)->fflags
> p/d &((struct target_freebsd_kevent *)0)->data
> p/d &((struct target_freebsd_kevent *)0)->udata
> p/d &((struct target_freebsd_kevent *)0)->ext
> 
> reports as the 2nd patch's problem-report
> material reports (56,0,4,6,8,12,20,24): not
> even the right size.
> 
> I also confirm that removing __packed in qemu's
> code and rebuilding and then checking with gdb
> reported a match to the above armv7 native report
> (64,0,4,6,8,16,24,32).
> 
> I have not verified __packed used vs. not for any
> other combination of host and target platforms.

Removing the 2 examples of __packed, including the
1 for target_freebsd_kevent, as in Mikaël Urankar's
2nd listed patch, was sufficient to avoid the hang
that I originally reported. (Technically FreeBSD 11
is not involved and so one of the __packed removals
is not relevant to my example.)

I have not applied Mikaël Urankar's first listed
patch at all. It did not prove necessary for my
context.

Again: the only tested context is amd64 -> armv7
(host -> target) under a head -r339076 based
build. (So still 12.)

I'm doing a larger amd64 -> armv7 rebuild (around
210 ports overall) that originally included the
problematical hang and a full-bootstrap build
of lang/gcc8 (so extensive emulation use after
the 

Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

[The bigger test still hung up.]

On 2018-Oct-27, at 5:30 PM, Mark Millard  wrote:

> [Just the __packed removal patch was sufficient to no longer
> have the hang problem that I originally reported for the
> print/texinfo build in poudriere.]
> 
> On 2018-Oct-27, at 4:33 PM, Mark Millard  wrote:
> 
>> [Some of this discussion occurred off list. The point here
>> is not specific to the hang that I originally reported.]
>> 
>> On 2018-Oct-27, at 3:03 PM, Mark Millard  wrote:
>>> 
> 
> Mikaël Urankar is being quoted below:
> 
 . . .
 
> There are bugs in qemu that can cause such deadlock, you can try these
> 2 patches:
> https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6baa45fdbe0dbb56a7371
> https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b
> 
> Back to me:
> 
 I'll try those later. Thanks. (I need to get back to sleep.)
 
 It was interesting that attach/detach to the ld process
 caused it to progress. The rest of the build completed
 just fine. But that one spot consistently hung up before
 trying gdb to look at the back trace.
 
>>> 
>>> Looking at the qemu code related to the 2nd patch: the
>>> structure of the field copies (via __get_user) seems
>>> very sensitive to the ABI rules for the target and
>>> how things align and such, given that the structure
>>> description and code are host code. __packed vs. not
>>> is possibly not sufficient control to always make things
>>> match right across all the potential combinations of
>>> host and target from what I can see.
>>> 
>>> Lack of __packed may prove sufficient for my specific
>>> context (amd64 host and armv7 target) but it seems
>>> non-obvious what to do in general.
>>> 
>>> There would also seem to be big endian vs. little endian
>>> issues on the individual __get_user styles of copies
>>> when the host and target do not match for a multi-byte
>>> numeric encoding.
>> 
>> Well, I get the following for:
>> 
>> #include "/usr/include/sys/event.h" // kevent
>> #include  // offsetof
>> #include   // printf
>> 
>> int
>> main()
>> {
>>   printf("%lu\n", (unsigned long) sizeof(struct kevent));
>>   printf("ident %lu\n", (unsigned long) offsetof(struct kevent, ident));
>>   printf("filter %lu\n", (unsigned long) offsetof(struct kevent, 
>> filter));
>>   printf("flags %lu\n", (unsigned long) offsetof(struct kevent, flags));
>>   printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, 
>> fflags));
>>   printf("data %lu\n", (unsigned long) offsetof(struct kevent, data));
>>   printf("udata %lu\n", (unsigned long) offsetof(struct kevent, udata));
>>   printf("ext %lu\n", (unsigned long) offsetof(struct kevent, ext));
>>   return 0;
>> }
>> 
>> (This code avoided warnings for type mismatches with the
>> printf strings and such.)
>> 
>> amd64 native [host of qemu use] (comments hand added):
>> 
>> # ./a.out
>> 64
>> ident 0
>> filter 8  // NOTE!
>> flags 10  // NOTE!
>> fflags 12 // NOTE!
>> data 16
>> udata 24
>> ext 32
>> 
>> (The above is not particularly important but I
>> include it for completeness.)
>> 
>> armv7 native [target in qemu use] (comments hand added):
>> 
>> # ./a.out
>> 64   // NOTE vs. below!
>> ident 0
>> filter 4 // NOTE vs. above!
>> flags 6  // NOTE vs. above!
>> fflags 8 // NOTE vs. above!
>> data 16  // NOTE vs. below!
>> udata 24 // NOTE vs. below!
>> ext 32   // NOTE vs. below!
>> 
>> /usr/include/sys/event.h lacks __packed in both cases.
>> 
>> With __packed in qemu-arm-static's source code
>> for target_freebsd_kevent I confirm that via
>> gdb for the qemu-arm-static:
>> 
>> p/d sizeof(struct target_freebsd_kevent)
>> p/d &((struct target_freebsd_kevent *)0)->ident
>> p/d &((struct target_freebsd_kevent *)0)->filter
>> p/d &((struct target_freebsd_kevent *)0)->flags
>> p/d &((struct target_freebsd_kevent *)0)->fflags
>> p/d &((struct target_freebsd_kevent *)0)->data
>> p/d &((struct target_freebsd_kevent *)0)->udata
>> p/d &((struct target_freebsd_kevent *)0)->ext
>> 
>> reports as the 2nd patch's problem-report
>> material reports (56,0,4,6,8,12,20,24): not
>> even the right size.
>> 
>> I also confirm that removing __packed in qemu's
>> code and rebuilding and then checking with gdb
>> reported a match to the above armv7 native report
>> (64,0,4,6,8,16,24,32).
>> 
>> I have not verified __packed used vs. not for any
>> other combination of host and target platforms.
> 
> Removing the 2 examples of __packed, including the
> 1 for target_freebsd_kevent, as in Mikaël Urankar's
> 2nd listed patch, was sufficient to avoid the hang
> that I originally reported. (Technically FreeBSD 11
> is not involved and so one of the __packed removals
> is not relevant to my example.)
> 
> I have not applied Mikaël Urankar's first listed
> patch at all. It did not prove necessary for my
> context.
> 
> Again: the only tested context is amd64 -> armv7
> (host -> target) under a head 

Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work

[Mark Millard via freebsd-ports]

On 2018-Nov-4, at 1:06 AM, Thomas Zander  wrote:

> On Fri, 1 Sep 2017 at 01:37, Mark Millard  wrote:
> 
>> [I show some of the target/ppc/translate.c source code
>> and related material this time. Not that I know enough
>> to patch it correctly.]
> 
> This is still an issue, correct?
> I tried to create a powerpc poudriere jail on 11.2 earlier today, with
> the same results.

Last I looked into it: unchanged. Your result tends to confirm the
status is unchanged.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

[Some of this discussion occurred off list. The point here
is not specific to the hang that I originally reported.]

On 2018-Oct-27, at 3:03 PM, Mark Millard  wrote:
> 
>> . . .
>> 
>> 
>>> There are bugs in qemu that can cause such deadlock, you can try these
>>> 2 patches:
>>> https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6baa45fdbe0dbb56a7371
>>> https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b
>> 
>> I'll try those later. Thanks. (I need to get back to sleep.)
>> 
>> It was interesting that attach/detach to the ld process
>> caused it to progress. The rest of the build completed
>> just fine. But that one spot consistently hung up before
>> trying gdb to look at the back trace.
>> 
> 
> Looking at the qemu code related to the 2nd patch: the
> structure of the field copies (via __get_user) seems
> very sensitive to the ABI rules for the target and
> how things align and such, given that the structure
> description and code are host code. __packed vs. not
> is possibly not sufficient control to always make things
> match right across all the potential combinations of
> host and target from what I can see.
> 
> Lack of __packed may prove sufficient for my specific
> context (amd64 host and armv7 target) but it seems
> non-obvious what to do in general.
> 
> There would also seem to be big endian vs. little endian
> issues on the individual __get_user styles of copies
> when the host and target do not match for a multi-byte
> numeric encoding.

Well, I get the following for:

#include "/usr/include/sys/event.h" // kevent
#include  // offsetof
#include   // printf

int
main()
{
printf("%lu\n", (unsigned long) sizeof(struct kevent));
printf("ident %lu\n", (unsigned long) offsetof(struct kevent, ident));
printf("filter %lu\n", (unsigned long) offsetof(struct kevent, filter));
printf("flags %lu\n", (unsigned long) offsetof(struct kevent, flags));
printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, fflags));
printf("data %lu\n", (unsigned long) offsetof(struct kevent, data));
printf("udata %lu\n", (unsigned long) offsetof(struct kevent, udata));
printf("ext %lu\n", (unsigned long) offsetof(struct kevent, ext));
return 0;
}

(This code avoided warnings for type mismatches with the
printf strings and such.)

amd64 native [host of qemu use] (comments hand added):

# ./a.out
64
ident 0
filter 8  // NOTE!
flags 10  // NOTE!
fflags 12 // NOTE!
data 16
udata 24
ext 32

(The above is not particularly important but I
include it for completeness.)

armv7 native [target in qemu use] (comments hand added):

# ./a.out
64   // NOTE vs. below!
ident 0
filter 4 // NOTE vs. above!
flags 6  // NOTE vs. above!
fflags 8 // NOTE vs. above!
data 16  // NOTE vs. below!
udata 24 // NOTE vs. below!
ext 32   // NOTE vs. below!

/usr/include/sys/event.h lacks __packed in both cases.

With __packed in qemu-arm-static's source code
for target_freebsd_kevent I confirm that via
gdb for the qemu-arm-static:

p/d sizeof(struct target_freebsd_kevent)
p/d &((struct target_freebsd_kevent *)0)->ident
p/d &((struct target_freebsd_kevent *)0)->filter
p/d &((struct target_freebsd_kevent *)0)->flags
p/d &((struct target_freebsd_kevent *)0)->fflags
p/d &((struct target_freebsd_kevent *)0)->data
p/d &((struct target_freebsd_kevent *)0)->udata
p/d &((struct target_freebsd_kevent *)0)->ext

reports as the 2nd patch's problem-report
material reports (56,0,4,6,8,12,20,24): not
even the right size.

I also confirm that removing __packed in qemu's
code and rebuilding and then checking with gdb
reported a match to the above armv7 native report
(64,0,4,6,8,16,24,32).

I have not verified __packed used vs. not for any
other combination of host and target platforms.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: port building on small, single-board computers or cross building ports: for lld I'd like to use -Wl,--no-threads

[Mark Millard via freebsd-ports]

On 2018-Nov-9, at 21:38, Mark Millard  wrote:

> On 2018-Nov-9, at 14:34, Mark Millard  wrote:
> 
>> On 2018-Nov-9, at 12:48, Jan Beich  wrote:
>> 
>>> Mark Millard via freebsd-ports  writes:
>>> 
>>>> For lld I'd like to use -Wl,--no-threads during poudriere-devel use.
>>>> 
>>>> ld.bfd and such reject --no-threads .
>>>> 
>>>> It appears that for ports there is no analogous support
>>>> of something like what buildworld has as notation for
>>>> specifying such:
>>>> 
>>>> LDFLAGS.lld+= -Wl,--no-threads
>>>> 
>>>> Any recommendation on an appropriate way to have use of
>>>> lld in ports also use --no-threads in its link commands
>>>> --but other linkers not do so?
>>> 
>>> Can you try the following?
>>> 
>>> .if ${LDFLAGS:M-fuse-ld=*lld*} || ${/usr/bin/ld:L:tA} == /usr/bin/ld.lld
>>> LDFLAGS+=   -Wl,--no-threads
>>> .endif
>> 
>> I added that to /usr/local/etc/poudriere.d/make.conf . The
>> cross build via poudriere did not hang (so far). lang/gcc8
>> (full bootstrap) takes a long time so I'll not be able to
>> declare the test done for some time. (There are other
>> things to build as well.)
>> 
>> However, if a port uses devel/binutils or devel/*-binutils
>> or such would not LDFLAGS still end up with the addition,
>> which the gcc(?) ld would then reject? The notation:
>> 
>> ${/usr/bin/ld:L:tA} == /usr/bin/ld.lld
>> 
>> does not appear to depend on which linker is in actual use
>> for the specific port generally --or what config scripting
>> might do before picking how later stages will work.
> 
> For what I've cross-built so far, I've had no such examples
> as below, so for now it is working for me for that context.
> Thanks!
> 
> But the notation issue is confirmed (non-cross build
> example). . .
> 
> I updated what ports vintage my amd64 context was based on
> ( -r48-0180 to -r484565 ) and tried a poudriere bulk with
> your 3 lines in poudriere.d/make.conf . The result for
> security/nss was:
> 
> [00:12:03] [23] [00:04:06] Saved security/nss | nss-3.40 wrkdir to: 
> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjail-default/default/nss-3.40.tbz
> [00:12:04] [23] [00:04:07] Finished security/nss | nss-3.40: Failed: build
> 
> because of:
> 
> cc -B/usr/local/bin -o FreeBSD13.0_OPT.OBJ/nsinstall -O2 -pipe  
> -I/usr/local/include/nspr -g -fstack-protector -fno-strict-aliasing   -fPIC 
> -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -Wall -Wshadow 
> -Qunused-arguments -Wno-parentheses-equality -Wno-array-bounds 
> -Wno-unevaluated-expression -Werror -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE 
> -D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
> -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
> -I./../dist/FreeBSD13.0_OPT.OBJ/include -I./../dist/public/ 
> -I./../dist/private/   -fPIC -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR 
> -DHAVE_BSD_FLOCK -Wall -Wshadow -Qunused-arguments -Wno-parentheses-equality 
> -Wno-array-bounds -Wno-unevaluated-expression -Werror -DXP_UNIX -UDEBUG 
> -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_NO_INIT_SUPPORT 
> -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
> -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
> -I../../dist/FreeBSD13.0_OPT.OBJ/include -I../../dist/public/coreconf 
> -I../../dist/private/co
 reconf   -fPIC -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK 
-Wall -Wshadow -Qunused-arguments -Wno-parentheses-equality -Wno-array-bounds 
-Wno-unevaluated-expression -Werror -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE 
-D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
-DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
-I../../../dist/FreeBSD13.0_OPT.OBJ/include -I../../../dist/public/coreconf 
-I../../../dist/private/coreconf  FreeBSD13.0_OPT.OBJ/nsinstall.o 
FreeBSD13.0_OPT.OBJ/pathsub.o  -Wl,--no-threads -fstack-protector-pthread
> /usr/local/bin/ld: unrecognized option '--no-threads'
> /usr/local/bin/ld: use the --help option for usage information
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[3]: *** [../../coreconf/rules.mk:243: FreeBSD13.0_OPT.OBJ/nsinstall] 
> Error 1
> gmake[3]: Leaving directory 
> '/wrkdirs/usr/ports/security/nss/work/nss-3.40/nss/coreconf/nsinstall'
> 
> 
> So, a mix of cc (system clang) and /usr/local/bin/ld in use together.
> It ended up with -Wl,--no-threads used and passing /usr/local/bin/ld
> --no-threads .

Just an FYI: gcc8 (set as the default) was given the
-Wl,--no-threads by devel/kBuild :

cd /wrkdirs/usr/ports/devel/kBuild/work/kBuild-0.1.9998 

Re: port building on small, single-board computers or cross building ports: for lld I'd like to use -Wl,--no-threads

[Mark Millard via freebsd-ports]

On 2018-Nov-9, at 14:34, Mark Millard  wrote:

> On 2018-Nov-9, at 12:48, Jan Beich  wrote:
> 
>> Mark Millard via freebsd-ports  writes:
>> 
>>> For lld I'd like to use -Wl,--no-threads during poudriere-devel use.
>>> 
>>> ld.bfd and such reject --no-threads .
>>> 
>>> It appears that for ports there is no analogous support
>>> of something like what buildworld has as notation for
>>> specifying such:
>>> 
>>> LDFLAGS.lld+= -Wl,--no-threads
>>> 
>>> Any recommendation on an appropriate way to have use of
>>> lld in ports also use --no-threads in its link commands
>>> --but other linkers not do so?
>> 
>> Can you try the following?
>> 
>> .if ${LDFLAGS:M-fuse-ld=*lld*} || ${/usr/bin/ld:L:tA} == /usr/bin/ld.lld
>> LDFLAGS+=-Wl,--no-threads
>> .endif
> 
> I added that to /usr/local/etc/poudriere.d/make.conf . The
> cross build via poudriere did not hang (so far). lang/gcc8
> (full bootstrap) takes a long time so I'll not be able to
> declare the test done for some time. (There are other
> things to build as well.)
> 
> However, if a port uses devel/binutils or devel/*-binutils
> or such would not LDFLAGS still end up with the addition,
> which the gcc(?) ld would then reject? The notation:
> 
> ${/usr/bin/ld:L:tA} == /usr/bin/ld.lld
> 
> does not appear to depend on which linker is in actual use
> for the specific port generally --or what config scripting
> might do before picking how later stages will work.

For what I've cross-built so far, I've had no such examples
as below, so for now it is working for me for that context.
Thanks!

But the notation issue is confirmed (non-cross build
example). . .

I updated what ports vintage my amd64 context was based on
( -r48-0180 to -r484565 ) and tried a poudriere bulk with
your 3 lines in poudriere.d/make.conf . The result for
security/nss was:

[00:12:03] [23] [00:04:06] Saved security/nss | nss-3.40 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDFSSDjail-default/default/nss-3.40.tbz
[00:12:04] [23] [00:04:07] Finished security/nss | nss-3.40: Failed: build

because of:

cc -B/usr/local/bin -o FreeBSD13.0_OPT.OBJ/nsinstall -O2 -pipe  
-I/usr/local/include/nspr -g -fstack-protector -fno-strict-aliasing   -fPIC 
-Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -Wall -Wshadow 
-Qunused-arguments -Wno-parentheses-equality -Wno-array-bounds 
-Wno-unevaluated-expression -Werror -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE 
-D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
-DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
-I./../dist/FreeBSD13.0_OPT.OBJ/include -I./../dist/public/ 
-I./../dist/private/   -fPIC -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR 
-DHAVE_BSD_FLOCK -Wall -Wshadow -Qunused-arguments -Wno-parentheses-equality 
-Wno-array-bounds -Wno-unevaluated-expression -Werror -DXP_UNIX -UDEBUG 
-DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY 
-DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
-I../../dist/FreeBSD13.0_OPT.OBJ/include -I../../dist/public/coreconf 
-I../../dist/private/core
 conf   -fPIC -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK 
-Wall -Wshadow -Qunused-arguments -Wno-parentheses-equality -Wno-array-bounds 
-Wno-unevaluated-expression -Werror -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE 
-D_REENTRANT -DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
-DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
-I../../../dist/FreeBSD13.0_OPT.OBJ/include -I../../../dist/public/coreconf 
-I../../../dist/private/coreconf  FreeBSD13.0_OPT.OBJ/nsinstall.o 
FreeBSD13.0_OPT.OBJ/pathsub.o  -Wl,--no-threads -fstack-protector-pthread
/usr/local/bin/ld: unrecognized option '--no-threads'
/usr/local/bin/ld: use the --help option for usage information
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [../../coreconf/rules.mk:243: FreeBSD13.0_OPT.OBJ/nsinstall] 
Error 1
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/security/nss/work/nss-3.40/nss/coreconf/nsinstall'


So, a mix of cc (system clang) and /usr/local/bin/ld in use together.
It ended up with -Wl,--no-threads used and passing /usr/local/bin/ld
--no-threads .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: port building on small, single-board computers or cross building ports: for lld I'd like to use -Wl,--no-threads

[Mark Millard via freebsd-ports]

On 2018-Nov-9, at 12:48, Jan Beich  wrote:

> Mark Millard via freebsd-ports  writes:
> 
>> For lld I'd like to use -Wl,--no-threads during poudriere-devel use.
>> 
>> ld.bfd and such reject --no-threads .
>> 
>> It appears that for ports there is no analogous support
>> of something like what buildworld has as notation for
>> specifying such:
>> 
>> LDFLAGS.lld+= -Wl,--no-threads
>> 
>> Any recommendation on an appropriate way to have use of
>> lld in ports also use --no-threads in its link commands
>> --but other linkers not do so?
> 
> Can you try the following?
> 
> .if ${LDFLAGS:M-fuse-ld=*lld*} || ${/usr/bin/ld:L:tA} == /usr/bin/ld.lld
> LDFLAGS+= -Wl,--no-threads
> .endif

I added that to /usr/local/etc/poudriere.d/make.conf . The
cross build via poudriere did not hang (so far). lang/gcc8
(full bootstrap) takes a long time so I'll not be able to
declare the test done for some time. (There are other
things to build as well.)

However, if a port uses devel/binutils or devel/*-binutils
or such would not LDFLAGS still end up with the addition,
which the gcc(?) ld would then reject? The notation:

${/usr/bin/ld:L:tA} == /usr/bin/ld.lld

does not appear to depend on which linker is in actual use
for the specific port generally --or what config scripting
might do before picking how later stages will work.


>> Without --no-threads, lld creates approximately one
>> thread per "cpu" (as FreeBSD counts such). For
>> cross building, this can run into bugs under
>> qemu-arm-static and hang up. It may also use more
>> memory in low memory contexts that might do better
>> without such extra memory use.
> 
> Are those only ports using non-default Clang? If not maybe haven't used
> -x flag from poudriere-jail(8).

I use -x in a jail -c command to have the native cross tools
around.

Past experiments have shown that some conftest.c
compiles/links via emulation do sometimes have the hanging
problem. Some config scripts explore some issues while
ignoring CC and the like and so end up running some
experiments with emulated cc and ld code.

Turns out attaching to the hung process with gdb and then
detaching is enough to let the process start running after
such a hang, at least in my examples.


Extra notes:

( from the test under 12 head -r339076 )
# gdb `which qemu-arm-static`
. . .
(gdb) attach 18703
Attaching to program: /usr/local/bin/qemu-arm-static, process 18703
Couldn't get registers: Device busy.
. . .
(gdb) bt
#0  _umtx_op () at _umtx_op.S:3
#1  0x60050cd4 in _umtx_wait_uint_private (where=0x0, addr=, target_val=, tsz=, t=)
   at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/freebsd/os-thread.c:258
#2  freebsd_lock_umutex (target_addr=4102556064, id=100867, ts=0x0, 
mode=) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/freebsd/os-thread.c:890
#3  0x6004a808 in do_freebsd__umtx_op (obj=4102556064, op=, val=0, uaddr=0, target_time=0)
   at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/freebsd/os-thread.h:359
#4  0x600414d5 in do_freebsd_syscall (cpu_env=0x8607a4c58, num=454, 
arg1=, arg2=, arg3=, arg4=0, 
arg5=0, arg6=-185272152, arg7=0, arg8=0)
   at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/syscall.c:1364
#5  0x60038d03 in target_cpu_loop (env=0x8607a4c58) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/arm/target_arch_cpu.h:207
#6  0x600386a9 in cpu_loop (env=0xf48809bc) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/main.c:121
#7  0x60039922 in main (argc=-10608, argv=0x7fffd1d8) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-495fb3a/bsd-user/main.c:513
(gdb) detach
Detaching from program: /usr/local/bin/qemu-arm-static, process 18703

Things started back up from there. (The above only listed one thread's
backtrace.)



I separately confirmed that the _packed use removed in:

https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b

does make the target_freebsd_kevent field offsets for
the armv7 context match the host environment and that
the qemu-user-static code does depend on such matching.
(I did this back on 12 head -r339076 as well.)

I've not checked aarch64 or any others, just armv7.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ports -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Mark Millard via freebsd-ports]

After updating ports from -r480180 to -r484565 the rebuilt
qemu-arm-static used to cross-build ports with poudriere now
fails with the likes of the following assert (2 examples).
Other ports have completed their package phase just fine
so this does not always fail. But for cmake and gcc8 failure
seems repeatable in my context.

I did not have this problem at all when based on -r480180 .


===
===>  Building package for cmake-3.12.3
Assertion failed: (start < end), function page_set_flags, file 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c,
 line 2077.
Child process pid=8254 terminated abnormally: Abort trap
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/cmake
=>> Cleaning up wrkdir
===>  Cleaning for cmake-3.12.3
build of devel/cmake | cmake-3.12.3 ended at Sat Nov 10 00:32:06 PST 2018
build time: 00:22:40


and:

===
===>  Building package for gcc8-8.2.0_1
Assertion failed: (start < end), function page_set_flags, file 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c,
 line 2077.
Child process pid=3100 terminated abnormally: Abort trap
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/gcc8
=>> Cleaning up wrkdir
===>  Cleaning for gcc8-8.2.0_1
build of lang/gcc8 | gcc8-8.2.0_1 ended at Sat Nov 10 04:10:58 PST 2018
build time: 04:08:19



The code with the assert is:

/* Modify the flags of a page and invalidate the code if necessary.
   The flag PAGE_WRITE_ORG is positioned automatically depending
   on PAGE_WRITE.  The mmap_lock should already be held.  */
void page_set_flags(target_ulong start, target_ulong end, int flags)
{
target_ulong addr, len;

/* This function should never be called with addresses outside the
   guest address space.  If this assert fires, it probably indicates
   a missing call to h2g_valid.  */
#if TARGET_ABI_BITS > L1_MAP_ADDR_SPACE_BITS
assert(end <= ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS));
#endif
assert(start < end);
assert_memory_lock();
. . .


The failed assert looks a bit odd because for:

start+TARGET_PAGE_SIZE < end

len will wrap around in the following, making for a huge len:

target_ulong addr, len;
. . .
for (addr = start, len = end - start;
 len != 0;
 len -= TARGET_PAGE_SIZE, addr += TARGET_PAGE_SIZE) {
. . .

(I ignore start+TARGET_PAGE_SIZE itself overflowing above.)


Context based on: head -r484565

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Mark Millard via freebsd-ports]

On 2018-Nov-10, at 06:45, Sean Bruno  wrote:


> On 11/10/18 7:04 AM, Mark Millard wrote:
>> I did not have this problem at all when based on -r480180 .
> 
> 
> Ok.  We'll take a quick look.

Reverting qemu-sbruno to -r438807 still gets the assert.

May be the updated pkg touches a bug that was present before?

I'll try reverting to -r478711 (which would be back to what -r480180 had
for qemu-sbruno but still -r484565 based pkg).


For reference:

I'll note that I've tried both without and with the patch in the
below and it made no difference to the problem:

https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b
 


(I checked that the patch makes the field offsets involved match
for the amd64 running armv7 code context and that the the code
structure depends on the offsets matching.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net  went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Mark Millard via freebsd-ports]

[Ignore: -r487807 was built but not installed.]

On 2018-Nov-10, at 08:26, Mark Millard  wrote:

> On 2018-Nov-10, at 06:45, Sean Bruno  > wrote:
> 
> 
>> On 11/10/18 7:04 AM, Mark Millard wrote:
>>> I did not have this problem at all when based on -r480180 .
>> 
>> 
>> Ok.  We'll take a quick look.
> 
> Reverting qemu-sbruno to -r438807 still gets the assert.

The revert was incomplete by not being installed, just built. I'll
run the test again.

Teach me to try to make progress after waking up in the middle
of the night.

> May be the updated pkg touches a bug that was present before?
> 
> I'll try reverting to -r478711 (which would be back to what -r480180 had
> for qemu-sbruno but still -r484565 based pkg).
> 
> 
> For reference:
> 
> I'll note that I've tried both without and with the patch in the
> below and it made no difference to the problem:
> 
> https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d499d8e465d4d2026c52b
>  
> 
> 
> (I checked that the patch makes the field offsets involved match
> for the amd64 running armv7 code context and that the the code
> structure depends on the offsets matching.)

This last part does apply to the original -r484565 test.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net  went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Mark Millard via freebsd-ports]

Having actually installed the reverted code fist ( -r438807 ),
cmake's package stage is now well past were it was failing.

So it is not the pkg vintage that matters: it is the qemu-sbruno
vintage that matters.

(gcc8 getting that far is hours away: full bootstrap, so mostly
emulated.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Mark Millard via freebsd-ports]

On 2018-Nov-10, at 12:28, Kyle Evans  wrote:

> On Sat, Nov 10, 2018 at 11:38 AM Mark Millard via freebsd-ports
>  wrote:
>> 
>> Having actually installed the reverted code fist ( -r438807 ),
>> cmake's package stage is now well past were it was failing.
>> 
>> So it is not the pkg vintage that matters: it is the qemu-sbruno
>> vintage that matters.
>> 
>> (gcc8 getting that far is hours away: full bootstrap, so mostly
>> emulated.)
>> 
> 
> I find the assertion you've reported fairly bizarre, since all of the
> page_set_flags invocations we would've touched are generally of the
> form `page_set_flags(start, start + len, ...)` -- I'm working on
> reproducing locally, though.

Looking at the overall sources for the two versions ( as seen via
-r483807 and -r484565 ) I find a possibly-significant changed file:

# diff -u 
/wrkdirs/usr/ports/emulators/qemu-user-static/*work/qemu-bsd-user-*/bsd-user/mmap.c
 | more
--- 
/wrkdirs/usr/ports/emulators/qemu-user-static/483807-work/qemu-bsd-user-495fb3a/bsd-user/mmap.c
 2018-05-25 07:28:13.0 -0700
+++ 
/wrkdirs/usr/ports/emulators/qemu-user-static/484565-work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c
 2018-11-09 09:27:18.0 -0800

(I'll not list much of the differences here.)

It includes things like:

-static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size)
+static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size, 
abi_ulong alignment)
. . .
-abi_ulong mmap_find_vma(abi_ulong start, abi_ulong size)
+static abi_ulong mmap_find_vma_aligned(abi_ulong start, abi_ulong size, 
abi_ulong alignment)
. . .
+abi_ulong mmap_find_vma(abi_ulong start, abi_ulong size)
+{
+return mmap_find_vma_aligned(start, size, 0);
+}
+

and changes inside:

 abi_long target_mmap(abi_ulong start, abi_ulong len, int prot,
  int flags, int fd, off_t offset)


This looks like it might change what address ranges are used.
(But I do not claim familiarity with the code or its use.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ports head -r484652: multimedia/gstreamer1-libav fails to amd64 -> armv7 cross build: error: /usr/local/bin/as: unrecognized option `-isystem'

[Mark Millard via freebsd-ports]

poudirere-devel reported:

[00:38:41] [03] [00:02:01] Saved multimedia/gstreamer1-libav | 
gstreamer1-libav-1.14.4_1 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/gstreamer1-libav-1.14.4_1.tbz
[00:38:42] [03] [00:02:02] Finished multimedia/gstreamer1-libav | 
gstreamer1-libav-1.14.4_1: Failed: configure

Looking around . . .

# less 
/usr/local/poudriere/data/logs/bulk/FBSDFSSDjailArmV7-default/2018-11-10_17h48m06s/logs/errors/gstreamer1-libav-1.14.4_1.log
. . .
Configuring included Libav instance with args --prefix=/usr/local 
--enable-static --enable-pic --disable-avdevice --disable-postproc  
   --disable-programs --disable-ffserver --dis
able-ffplay --disable-ffprobe --disable-ffmpeg --disable-encoder=flac 
--disable-protocols --disable-devices --disable-network 
--disable-hwaccels --disable-dxva2 --disable-vdpau
 --disable-filters --enable-filter=yadif --disable-doc --disable-vda 
--disable-d3d11va --disable-dxva2 --disable-audiotoolbox 
--disable-videotoolbox --disable-vaapi --disable-crystalhd
 --disable-mediacodec --disable-nvenc --disable-mmal --disable-omx 
--disable-omx-rpi --disable-cuda --disable-cuvid --disable-libmfx 
--disable-libnpp --disable-iconv --disable-jni --di
sable-v4l2_m2m --enable-optimizations --ar="$AR" --as="$orig_AS" --cc="$CC" 
--ld="$CC" --nm="$NM" --disable-ffmpeg 
GNU assembler not found, install/update gas-preprocessor
. . .

 After expanding the tar archive of the failure . . .

# less 
/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.14.4/gst-libs/ext/libav/ffbuild/config.log
. . .
gas-preprocessor.pl -arch arm -as-type -- /usr/local/bin/as -v
./configure: gas-preprocessor.pl: not found
check_gas using '/usr/local/bin/as' as AS
check_as
BEGIN /tmp/ffconf.mw9w5KeR/test.S
1   .macro m n, y:vararg=0
2   \n: .int \y
3   .endm
4   m x
END /tmp/ffconf.mw9w5KeR/test.S
/usr/local/bin/as -mcpu=cortex-a7 -isystem /usr/local/include -D_ISOC99_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -no-integrated-as 
-march=armv7-a -fPIC -c -o /tmp/ffconf.mw9w5KeR/test.o 
/tmp/ffconf.mw9w5KeR/test.S
/usr/local/bin/as: unrecognized option `-isystem'
check_gas using '/usr/local/bin/as' as AS
check_as
BEGIN /tmp/ffconf.mw9w5KeR/test.S
1   .macro m n, y:vararg=0
2   \n: .int \y
3   .endm
4   m x
END /tmp/ffconf.mw9w5KeR/test.S
/usr/local/bin/as -mcpu=cortex-a7 -isystem /usr/local/include -D_ISOC99_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -no-integrated-as 
-march=armv7-a -fPIC -c -o /tmp/ffconf.mw9w5KeR/test.o 
/tmp/ffconf.mw9w5KeR/test.S
/usr/local/bin/as: unrecognized option `-isystem'
GNU assembler not found, install/update gas-preprocessor

(And that is the end of that config.log file.)

The -mcpu=cortex-a7 use is likely from:

# more /usr/local/etc/poudriere.d/FBSDFSSDjailArmV7-make.conf 
CFLAGS+= -mcpu=cortex-a7
CXXFLAGS+= -mcpu=cortex-a7
CPPFLAGS+= -mcpu=cortex-a7

I did not supply a -isystem myself.


FreeBSD build for the context was based on: head -r340287

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ports head -r484652: lang/ruby24 fails to amd64 -> armv7 cross build: qemu: uncaught target signal 11 (2 of them)

[Mark Millard via freebsd-ports]

Poudriere-devel reported:

[00:18:32] [07] [00:02:56] Saved lang/ruby24 | ruby-2.4.5,1 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/ruby-2.4.5,1.tbz
[00:18:32] [07] [00:02:56] Finished lang/ruby24 | ruby-2.4.5,1: Failed: build

The log showed:

--- miniruby ---
linking miniruby
--- .rbconfig.time ---
--- encdb.h ---
generating encdb.h
--- .rbconfig.time ---
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
*** [.rbconfig.time] Error code 139

make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5
--- encdb.h ---
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
*** [encdb.h] Error code 139

make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5
2 errors


Despite how the above looks, I find only one .core file in the
tar archive produced for the failure:

# find /wrkdirs/usr/ports/lang/ruby/ -name "*.core" -print
/wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/qemu_miniruby.core

Apparently qemu does not allow for separate files for distinct
processes.

For that .core file I find (libexec/gdb):

# chroot /usr/obj/DESTDIRs/clang-armv7-installworld-poud
# cd /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/
# /usr/libexec/gdb miniruby qemu_miniruby.core 
. . .
(gdb) bt
#0  0x00113f84 in rb_gc_writebarrier_unprotect (obj=4104601600) at gc.c:1119
1119return RVALUE_WB_UNPROTECTED_BITMAP(obj) != 0;
[New Thread f4b5d000 (LWP 100638/)]
[New LWP 61684]
Current language:  auto; currently minimal
(gdb) bt
#0  0x00113f84 in rb_gc_writebarrier_unprotect (obj=4104601600) at gc.c:1119
#1  0x000c3fc8 in rb_include_class_new (module=4104569400, super=) at ruby.h:1456
#2  0x000c4424 in include_modules_at (klass=4104602160, c=4104602160, 
module=4104569400, search_super=) at class.c:913
#3  0x000c41f0 in rb_include_module (klass=4104602160, module=4104569400) at 
class.c:870
#4  0x001f6dec in Init_String () at string.c:10021
#5  0x00129398 in rb_call_inits () at inits.c:28
#6  0x00103bac in ruby_setup () at eval.c:60
#7  0x00103be8 in ruby_init () at eval.c:76
#8  0x000a3300 in main (argc=11, argv=0x9fffe41c) at main.c:35
(gdb) up
#1  0x000c3fc8 in rb_include_class_new (module=4104569400, super=) at ruby.h:1456
1456rb_gc_writebarrier_unprotect(x);
(gdb) up
#2  0x000c4424 in include_modules_at (klass=4104602160, c=4104602160, 
module=4104569400, search_super=) at class.c:913
913 iclass = rb_include_class_new(module, RCLASS_SUPER(c));
(gdb) up
#3  0x000c41f0 in rb_include_module (klass=4104602160, module=4104569400) at 
class.c:870
870 changed = include_modules_at(klass, RCLASS_ORIGIN(klass), module, 
TRUE);
(gdb) up
#4  0x001f6dec in Init_String () at string.c:10021
10021   rb_include_module(rb_cString, rb_mComparable);
(gdb) up
#5  0x00129398 in rb_call_inits () at inits.c:28
28  CALL(String);
(gdb) up
#6  0x00103bac in ruby_setup () at eval.c:60
60  rb_call_inits();
(gdb) up
#7  0x00103be8 in ruby_init () at eval.c:76
76  int state = ruby_setup();
(gdb) up
#8  0x000a3300 in main (argc=11, argv=0x9fffe41c) at main.c:35
35  ruby_init();

(I'm not familiar with what details libexec/gdb gets
right vs. wrong. But the call chain seems coherent.)

Host environment:

# uname -apKU
FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r340287M: Fri Nov  9 
08:37:01 PST 2018 
markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
  amd64 amd64 133 133



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Mark Millard via freebsd-ports]

On 2018-Nov-10, at 20:00, Kyle Evans  wrote:

> On Sat, Nov 10, 2018 at 4:30 PM Mark Millard  wrote:
>> 
>> On 2018-Nov-10, at 12:28, Kyle Evans  wrote:
>> 
>>> On Sat, Nov 10, 2018 at 11:38 AM Mark Millard via freebsd-ports
>>>  wrote:
>>>> 
>>>> Having actually installed the reverted code fist ( -r438807 ),
>>>> cmake's package stage is now well past were it was failing.
>>>> 
>>>> So it is not the pkg vintage that matters: it is the qemu-sbruno
>>>> vintage that matters.
>>>> 
>>>> (gcc8 getting that far is hours away: full bootstrap, so mostly
>>>> emulated.)
>>>> 
>>> 
>>> I find the assertion you've reported fairly bizarre, since all of the
>>> page_set_flags invocations we would've touched are generally of the
>>> form `page_set_flags(start, start + len, ...)` -- I'm working on
>>> reproducing locally, though.
>> 
>> Looking at the overall sources for the two versions ( as seen via
>> -r483807 and -r484565 ) I find a possibly-significant changed file:
>> 
>> # diff -u 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/*work/qemu-bsd-user-*/bsd-user/mmap.c
>>  | more
>> --- 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/483807-work/qemu-bsd-user-495fb3a/bsd-user/mmap.c
>>  2018-05-25 07:28:13.0 -0700
>> +++ 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/484565-work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c
>>  2018-11-09 09:27:18.0 -0800
>> 
> 
> Yes, I'm familiar with this particular changeset- I wrote it. =)

I noticed that later when researching.

> Unfortunately, I can't reproduce this locally- neither with
> devel/cmake nor any of the other ports that I build.

Out of 200+ I only saw it for the two. Multiple bulk tests
for cmake. (I did not wait for lang/gcc8's full bootstrap
to finish.) Some uncommon (limiting?) condition, apparently.

> I think we'll
> have to wait until either we get more reports of this or portmgr@
> trips over it in a way that I can reproduce and dig in a bit.

If there is a change that would force a core dump or
backtrace or something to give context, I could try such.
(My normal builds are non-debug but with symbols enabled,
even for ports, a combination I had to add local support
for.) I did not find a core file when I looked in the
tar archive of the failure. (I've not yet checked
qemu-arm-static does something to prevent generating
host core files.)

Or I could substitute the old version of the one source in
with the rest being new, rebuild qemu-user-static, and try
again.

Such would be tomorrow, my time (US Pacific).

(The reason for tomorrow: I've got a bulk going for updating
to ports -r484652 --other than the reverted qemu-user-static.
It is done but for the full-bootstrap lang/gcc8 that will
take hours more.)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end): backtrace included; start+len arithmetic overflow (abi_ulong wrap) for TARGET_FREEBSD_NR_mmap use

[Mark Millard via freebsd-ports]

I attached with gdb in order to stop at the assert and look around.



The following is a backtrace with notes and prints mixed in:

(gdb) bt
#0  thr_kill () at thr_kill.S:3
#1  0x6028a21f in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x60204949 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3  0x6027855a in __assert (func=, file=, 
line=, failedexpr=) at 
/usr/src/lib/libc/gen/assert.c:51

Note end==37146624 below vs. start (37146624 will show up again in later notes)

#4  0x60036243 in page_set_flags (start=4143968256, end=37146624, 
flags=9) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c:2077

Note start and len below:

#5  0x6003df2b in target_mmap (start=4143968256, len=188145664, 
prot=, flags=, fd=, 
offset=)
at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c:626

(gdb) print/x start
$5 = 0xf6fff000
(gdb) print/x len
$6 = 0xb36e000

Note start+len for the above (without wrapping):

(gdb) print/x (long long)start + (long long)len
$10 = 0x10236d000
(gdb) print (long long)start + (long long)len
$11 = 4332113920

With wrapping:

(gdb) print/x start+len
$8 = 0x236d000
(gdb) print start+len
$9 = 37146624

And there is end's value again.

The code doing the wrapping is (with more context):

621 if (p == MAP_FAILED)
622 goto fail;
623 }
624 }
625  the_end1:
626 page_set_flags(start, start + len, prot | PAGE_VALID);
627  the_end:
628 #ifdef DEBUG_MMAP
629 printf("ret=0x" TARGET_ABI_FMT_lx "\n", start);
630 page_dump(stdout);


#6  0x6004219c in do_bsd_mmap (arg1=, arg2=, arg3=, arg4=2, arg5=, arg6=, 
arg7=, arg8=0, 
cpu_env=) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/bsd-mem.h:75

The code for the above is:

if (regpairs_aligned(cpu_env) != 0) {
   arg6 = arg7;
   arg7 = arg8;
}
return get_errno(target_mmap(arg1, arg2, arg3,
target_to_host_bitmask(arg4, mmap_flags_tbl), arg5,
target_arg64(arg6, arg7)));


#7  do_freebsd_syscall (cpu_env=0x860c08318, num=477, arg1=, 
arg2=, arg3=, arg4=2, arg5=9, arg6=0, arg7=0, 
arg8=0)
at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/syscall.c:946
The code above is (with some context):

break;


/*
 * Memory management system calls.
 */
   case TARGET_FREEBSD_NR_mmap: /* mmap(2) */
ret = do_bsd_mmap(cpu_env, arg1, arg2, arg3, arg4, arg5, arg6, arg7,
   arg8);
break;


#8  0x60038be3 in target_cpu_loop (env=0x860c08318) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/arm/target_arch_cpu.h:207

The code and its context for the above is:

break;
case EXCP_SWI:
case EXCP_BKPT:
. . .
/*
 * system call
 * See arm/arm/trap.c cpu_fetch_syscall_args()
 */
. . .
DEBUG_PRINTF("AVANT CALL %d\n", n);
if (bsd_type == target_freebsd) {
int ret;
abi_ulong params = get_sp_from_cpustate(env);
int32_t syscall_nr = n;
int32_t arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8;

if (syscall_nr == TARGET_FREEBSD_NR_syscall) {
. . .
} else if (syscall_nr == TARGET_FREEBSD_NR___syscall) {
. . .
} else {
arg1 = env->regs[0];
arg2 = env->regs[1];
arg3 = env->regs[2];
arg4 = env->regs[3];
get_user_s32(arg5, params);
params += sizeof(int32_t);
get_user_s32(arg6, params);
params += sizeof(int32_t);
get_user_s32(arg7, params);
params += sizeof(int32_t);
get_user_s32(arg8, params);
}

ret = do_freebsd_syscall(env, syscall_nr, arg1, arg2, arg3,
arg4, arg5, arg6, arg7, arg8);


#9  0x60038589 in cpu_loop (env=0x18b2f) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/main.c:121

#10 0x60039802 in main (argc=-10089, argv=0x7fffd4e0) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/main.c:513


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports head -r484652: multimedia/gstreamer1-libav fails to amd64 -> armv7 cross build: error: /usr/local/bin/as: unrecognized option `-isystem'

[Mark Millard via freebsd-ports]

On 2018-Nov-11, at 03:55, Jan Beich  wrote:

> Mark Millard via freebsd-multimedia 
> writes:
> 
>> poudirere-devel reported:
>> 
>> [00:38:41] [03] [00:02:01] Saved multimedia/gstreamer1-libav | 
>> gstreamer1-libav-1.14.4_1 wrkdir to: 
>> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/gstreamer1-libav-1.14.4_1.tbz
>> [00:38:42] [03] [00:02:02] Finished multimedia/gstreamer1-libav | 
>> gstreamer1-libav-1.14.4_1: Failed: configure
>> 
> 
> I can't reproduce on 13.0 armv7 (clang 7.0.1): https://ptpb.pw/wdCK
> 
>> /usr/local/bin/as -mcpu=cortex-a7 -isystem /usr/local/include 
>> -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC 
>> -no-integrated-as -march=armv7-a -fPIC -c -o /tmp/ffconf.mw9w5KeR/test.o 
>> /tmp/ffconf.mw9w5KeR/test.S
>> /usr/local/bin/as: unrecognized option `-isystem'
> 
> -isystem originates from USES=localbase defined in the port's Makefile.
> No clue how you've got ASFLAGS poisoned by CPPFLAGS or CFLAGS, though.
> 
> Can you provide poudriere log?

Sure. But first for reference:

# svnlite status /usr/ports/multimedia/gstreamer1-libav/
# 

So, no local changes.

As for the log . . .

Only the --MAKE_ENV-- and /usr/local/etc/poudriere.d/FBSDFSSDjailArmV7-make.conf
sections show any -mcpu text. ASFLAGS only shows in the --CONFIGURE_ENV-- 
section
and does not show a -mcpu example.

phase: configure fails so the build attempt does not get far.

And here is from one of the build attempts:

# less 
/usr/local/poudriere/data/logs/bulk/FBSDFSSDjailArmV7-default/2018-11-10_17h48m06s/logs/gstreamer1-libav-1.14.4_1.log
=>> Building multimedia/gstreamer1-libav
build started at Sat Nov 10 18:24:47 PST 2018
port directory: /usr/ports/multimedia/gstreamer1-libav
package name: gstreamer1-libav-1.14.4_1
building for: FreeBSD FBSDFSSDjailVariant 13.0-CURRENT FreeBSD 13.0-CURRENT arm
maintained by: multime...@freebsd.org
Makefile ident:  $FreeBSD: head/multimedia/gstreamer1-libav/Makefile 484273 
2018-11-06 01:50:26Z jbeich $
Poudriere version: 3.2.99.20181024
Host OSVERSION: 133
Jail OSVERSION: 133
Job Id: 03

---Begin Environment---
SHELL=/bin/csh
UNAME_p=armv7
UNAME_m=arm
ABI_FILE=/usr/lib/crt1.o
OSVERSION=133
UNAME_v=FreeBSD 13.0-CURRENT
UNAME_r=13.0-CURRENT
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
HOME=/root
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
LOCALBASE=/usr/local
QEMU_EMULATING=1
USER=root
LIBEXECPREFIX=/usr/local/libexec/poudriere
POUDRIERE_VERSION=3.2.99.20181024
MASTERMNT=/usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/ref
POUDRIERE_BUILD_TYPE=bulk
PACKAGE_BUILDING=yes
SAVED_TERM=xterm-256color
PWD=/usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/ref/.p/pool
P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS
MASTERNAME=FBSDFSSDjailArmV7-default
SCRIPTPREFIX=/usr/local/share/poudriere
OLDPWD=/usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/ref/.p
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
POUDRIEREPATH=/usr/local/bin/poudriere
---End Environment---

---Begin Poudriere Port Flags/Env---
PORT_FLAGS=
PKGENV=
FLAVOR=
DEPENDS_ARGS=
MAKE_ARGS=
---End Poudriere Port Flags/Env---

---Begin OPTIONS List---
===> The following configuration options are available for 
gstreamer1-libav-1.14.4_1:
 FFMPEG=off: Use system ffmpeg instead of internal libav
===> Use 'make config' to modify these settings
---End OPTIONS List---

--MAINTAINER--
multime...@freebsd.org
--End MAINTAINER--

--CONFIGURE_ARGS--
--without-system-libav --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
ASFLAGS=-no-integrated-as MAKE=gmake PKG_CONFIG=pkgconf 
PYTHON="/usr/local/bin/python2.7" 
XDG_DATA_HOME=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work  
XDG_CONFIG_HOME=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work  
HOME=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work TMPDIR="/tmp" 
PATH=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
 SHELL=/bin/sh CONFIG_SHELL=/bin/sh ADDR2LINE="/usr/local/bin/addr2line" 
AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" 
GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" 
OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" 
RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" 
SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" 
CMAKE_PREFIX_PATH="/usr/local" LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 
CONFIG_SITE=/usr/ports/Templates/config.site lt_cv_sys_max_cmd_len=262144
--End CONFIGURE_ENV--

--MAKE_ENV--
V=1 XDG_DATA_HOME=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work  
XDG_CONFIG_HOME=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work  
HOME=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work TMPDIR="/tmp" 
PATH=/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
 DONTSTRIP=yes NO_PIE=yes 

Re: ports head -r484652: multimedia/gstreamer1-libav fails to amd64 -> armv7 cross build: error: /usr/local/bin/as: unrecognized option `-isystem'

[Mark Millard via freebsd-ports]

On 2018-Nov-11, at 04:36, Mark Millard  wrote:

> On 2018-Nov-11, at 03:55, Jan Beich  wrote:
> 
>> Mark Millard via freebsd-multimedia 
>> writes:
>> 
>>> poudirere-devel reported:
>>> 
>>> [00:38:41] [03] [00:02:01] Saved multimedia/gstreamer1-libav | 
>>> gstreamer1-libav-1.14.4_1 wrkdir to: 
>>> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/gstreamer1-libav-1.14.4_1.tbz
>>> [00:38:42] [03] [00:02:02] Finished multimedia/gstreamer1-libav | 
>>> gstreamer1-libav-1.14.4_1: Failed: configure
>>> 
>> 
>> I can't reproduce on 13.0 armv7 (clang 7.0.1): https://ptpb.pw/wdCK
>> 
>>> /usr/local/bin/as -mcpu=cortex-a7 -isystem /usr/local/include 
>>> -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC 
>>> -no-integrated-as -march=armv7-a -fPIC -c -o /tmp/ffconf.mw9w5KeR/test.o 
>>> /tmp/ffconf.mw9w5KeR/test.S
>>> /usr/local/bin/as: unrecognized option `-isystem'
>> 
>> -isystem originates from USES=localbase defined in the port's Makefile.
>> No clue how you've got ASFLAGS poisoned by CPPFLAGS or CFLAGS, though.
>> 

Looking I see 3 places with ASFLAGS mixed with CPPFLAGS:

gst-libs/ext/libav/ffbuild/common.mak:ASFLAGS:= $(CPPFLAGS) $(ASFLAGS)
gst-libs/ext/libav/configure:check_cmd $as $CPPFLAGS $ASFLAGS "$@" $AS_C 
$(as_o $TMPO) $TMPS
gst-libs/ext/libav/configure:DEPASFLAGS=$DEPASFLAGS \$(CPPFLAGS)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports head -r484652: multimedia/gstreamer1-libav fails to amd64 -> armv7 cross build: error: /usr/local/bin/as: unrecognized option `-isystem'

[Mark Millard via freebsd-ports]

On 2018-Nov-11, at 05:26, Jan Beich  wrote:

> Mark Millard  writes:
> 
>> On 2018-Nov-11, at 03:55, Jan Beich  wrote:
>> 
>>> Mark Millard via freebsd-multimedia 
>>> writes:
>>> 
 poudirere-devel reported:
 
 [00:38:41] [03] [00:02:01] Saved multimedia/gstreamer1-libav | 
 gstreamer1-libav-1.14.4_1 wrkdir to: 
 /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/gstreamer1-libav-1.14.4_1.tbz
 [00:38:42] [03] [00:02:02] Finished multimedia/gstreamer1-libav | 
 gstreamer1-libav-1.14.4_1: Failed: configure
 
>>> 
>>> I can't reproduce on 13.0 armv7 (clang 7.0.1): https://ptpb.pw/wdCK
>>> 
 /usr/local/bin/as -mcpu=cortex-a7 -isystem /usr/local/include 
 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC 
 -no-integrated-as -march=armv7-a -fPIC -c -o /tmp/ffconf.mw9w5KeR/test.o 
 /tmp/ffconf.mw9w5KeR/test.S
 /usr/local/bin/as: unrecognized option `-isystem'
>>> 
>>> -isystem originates from USES=localbase defined in the port's Makefile.
>>> No clue how you've got ASFLAGS poisoned by CPPFLAGS or CFLAGS, though.
>>> 
>>> Can you provide poudriere log?
>> 
>> Sure. But first for reference:
>> 
>> # svnlite status /usr/ports/multimedia/gstreamer1-libav/
>> # 
>> 
>> So, no local changes.
>> 
>> As for the log . . .
> [...]
>> --CONFIGURE_ENV--
>> ... ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" 
>> AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" 
>> GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" 
>> OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" 
>> RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" 
>> SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" ...
>> --End CONFIGURE_ENV--
> [...]
>> ===>   gstreamer1-libav-1.14.4_1 depends on executable: as - not found
>> ===>   Installing existing package /packages/All/binutils-2.30_5,1.txz
>> Installing binutils-2.30_5,1...
>> `-- Installing gettext-runtime-0.19.8.1_2...
>> |   `-- Installing indexinfo-0.3.1...
>> |   `-- Extracting indexinfo-0.3.1:  done
>> `-- Extracting gettext-runtime-0.19.8.1_2: .. done
>> Extracting binutils-2.30_5,1: .. done
> 
> Can you track down what defines USE_BINUTILS=yes on armv7 ?

/usr/ports/multimedia/gstreamer1-libav/Makefile has:

FFMPEG_VARS_OFF+=   LLD_UNSAFE=yes # aarch64

(The comment about aarch64 is not indicating conditional
logic. My guess it just indicates a context where LLD_UNSAFE
is required, rather than conceptually optional --even if
always currently applied for the FFMEG_VAR_OFF context.)

The one place with USE_BINUTILS=yes in /usr/ports/Mk/bsd.port.mk
is:

.if defined(LLD_UNSAFE) && ${/usr/bin/ld:L:tA} == /usr/bin/ld.lld
LDFLAGS+=   -fuse-ld=bfd
BINARY_ALIAS+=  ld=${LD}
.  if !defined(USE_BINUTILS)
.if exists(/usr/bin/ld.bfd)
LD= /usr/bin/ld.bfd
CONFIGURE_ENV+= LD=${LD}
MAKE_ENV+=  LD=${LD}
.else
USE_BINUTILS=   yes
.endif
.  endif
.endif

Note that WITH_BINTUILS/WITHOUT_BINUTILS has buildworld defaults
of:

 WITHOUT_BINUTILS
 Set to not build or install binutils (as, ld, and objdump) as
 part of the normal system build.  The resulting system cannot
 build programs from source.

 This is a default setting on arm64/aarch64 and riscv/riscv64.
 When set, it enforces these options:

 WITHOUT_GDB

 WITH_BINUTILS
 Set to build and install binutils (as, ld, and objdump) as part
 of the normal system build.

 This is a default setting on amd64/amd64, arm/arm, arm/armv6,
 arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el,
 mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf,
 mips/mips64elhf, mips/mips64hf, powerpc/powerpc,
 powerpc/powerpc64, powerpc/powerpcspe and sparc64/sparc64.

But at this stage in many contexts WITHOUT_BINUTILS= can validly
be manually set.

I'd originally done that for /usr/obj/DESTDIRs/clang-armv7-installworld-poud/
and other armv7 material until I wanted to use /libexec/gdb inside that
context to get a backtrace and related information for another problem. (Well
after my report of the gstreamer1-linav issue.) I'll likely be going back to
using WITHOUT_BINUTILS=  now that I've reported the detail for a
qemu-arm-static failure.

For amd64, armv7, and powerpc64 I only have WITH_BINUTILS= in order to allow
WITH_GDB= when it seems appropriate for what is going on. (Sometime contexts
are not appropriate for ports or are not ready for having ports yet.)



> See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233137

My understanding is that /usr/bin/ld.bfd does not work for
aarch64 and so WITHOUT_BINUTILS= is more of a requirement.

So if lld is a problem, then USE_BINUTILS=yes ends up being
nearly required. There is devel/aarch64-binutils as an
alternative.

FFMPEG_VARS_OFF+=   LLD_UNSAFE=yes # 

qemu-arm-static: bsd-user/arm/target_syscall.h: #define TARGET_HW_MACHINE_ARCH "armv6" // what of armv7?

[Mark Millard via freebsd-ports]

11.x:
o 11.2-STABLE armv6 BANANAPI
o 11.2-STABLE armv6 BEAGLEBONE
o 11.2-STABLE armv6 CUBIEBOARD
o 11.2-STABLE armv6 CUBIEBOARD2
o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD
o 11.2-STABLE armv6 RPI-B
o 11.2-STABLE armv6 RPI2
o 11.2-STABLE armv6 PANDABOARD
o 11.2-STABLE armv6 WANDBOARD

12.x+ (I got the list from a 13.0 snapshot announcement):
o 13.0-CURRENT armv6 RPI-B
o 13.0-CURRENT armv7 BANANAPI
o 13.0-CURRENT armv7 BEAGLEBONE
o 13.0-CURRENT armv7 CUBIEBOARD
o 13.0-CURRENT armv7 CUBIEBOARD2
o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD
o 13.0-CURRENT armv7 RPI2
o 13.0-CURRENT armv7 PANDABOARD
o 13.0-CURRENT armv7 WANDBOARD
o 13.0-CURRENT armv7 GENERICSD

So as of 12.x+ most are armv7 --as are most new ones
expected to be.

As stands, in my amd64 -> armv7 13.0 cross-build activity,
uname -p and the like under the chroot context are
returning armv6 instead of armv7 unless I override via
a UNAME_p definition.

This appears to trace back to: bsd-user/arm/target_syscall.h
and its:

#define TARGET_HW_MACHINE   "arm"
#define TARGET_HW_MACHINE_ARCH  "armv6"

and lack context sensitivity, such as to the FreeBSD version
that it is in use under.

So it seems that most 12.x+ use needs to define UNAME_p to
actually have armv7 in uname output and the like.

I noticed this by trying a armv7 buildworld under a
chroot and it reported:

make[1]: "/usr/src/Makefile.inc1" line 577: To cross-build, set TARGET_ARCH.

This was because of Makefile.inc1 and its:

.if make(buildworld)
BUILD_ARCH!=uname -p
.if ${MACHINE_ARCH} != ${BUILD_ARCH}
.error To cross-build, set TARGET_ARCH.
.endif
.endif

in which it compared armv7 != armv6 and
stopped the build. As it sees things under
qemu-arm-static, only armv6 is a native
buildworld, the rest are cross-builds.

Ports could be choosing inappropriately based on
armv6 being reported in/for armv7 contexts.

Should ports normally see armv6 instead of armv7 on
FreeBSD 12.x+ for some reason? Or would this better be
changed to armv7 as the default for such contexts?

Should documentation report on the issue and how
to handle it when the default is inappropriate?


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-arm-static: bsd-user/arm/target_syscall.h: #define TARGET_HW_MACHINE_ARCH "armv6" // what of armv7?

[Mark Millard via freebsd-ports]

On 2018-Nov-12, at 20:58, Kyle Evans  wrote:

> On Mon, Nov 12, 2018 at 10:41 PM Mark Millard  wrote:
>> 
>> 11.x:
>> o 11.2-STABLE armv6 BANANAPI
>> o 11.2-STABLE armv6 BEAGLEBONE
>> o 11.2-STABLE armv6 CUBIEBOARD
>> o 11.2-STABLE armv6 CUBIEBOARD2
>> o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD
>> o 11.2-STABLE armv6 RPI-B
>> o 11.2-STABLE armv6 RPI2
>> o 11.2-STABLE armv6 PANDABOARD
>> o 11.2-STABLE armv6 WANDBOARD
>> 
>> 12.x+ (I got the list from a 13.0 snapshot announcement):
>> o 13.0-CURRENT armv6 RPI-B
>> o 13.0-CURRENT armv7 BANANAPI
>> o 13.0-CURRENT armv7 BEAGLEBONE
>> o 13.0-CURRENT armv7 CUBIEBOARD
>> o 13.0-CURRENT armv7 CUBIEBOARD2
>> o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD
>> o 13.0-CURRENT armv7 RPI2
>> o 13.0-CURRENT armv7 PANDABOARD
>> o 13.0-CURRENT armv7 WANDBOARD
>> o 13.0-CURRENT armv7 GENERICSD
>> 
>> So as of 12.x+ most are armv7 --as are most new ones
>> expected to be.
>> 
>> As stands, in my amd64 -> armv7 13.0 cross-build activity,
>> uname -p and the like under the chroot context are
>> returning armv6 instead of armv7 unless I override via
>> a UNAME_p definition.
>> 
>> This appears to trace back to: bsd-user/arm/target_syscall.h
>> and its:
>> 
>> #define TARGET_HW_MACHINE   "arm"
>> #define TARGET_HW_MACHINE_ARCH  "armv6"
>> 
>> and lack context sensitivity, such as to the FreeBSD version
>> that it is in use under.
>> 
> 
> Indeed, I opened this a couple of hours ago:
> https://github.com/seanbruno/qemu-bsd-user/pull/70 -- It turns out
> this is basically wrong, though I'm not sure immediately how to
> rectify. I don't think we can reasonably decide at compile-time what
> this should look like since all 32-bit ARM are shoved into this one
> target, so perhaps the right answer is that armv6 and armv7 need to
> split off from arm.arm and we use a check like the one in the above
> PR. CC'ing imp for a wisdom drop.

Looks like poudriere-devel is defining UNAME_p and UNAME_m to cause
the right results for its port builds.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FYI: ports head -r484783 poudriere-devel with qemu-arm-static: sometimes hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

[I still can not produce the problem below on demand.
It seems racy with no fixed context producing the
problem as far as which port is building. But the
general structure of what hangs is the same each
time so far.]

The following is just an FYI for the other
qemu-arm-static tied problem that I regularly run into.
I do not have much useful information so far. It is
not clear how I'd get such information.

I still fairly frequently see the hang-up-error when
lld is emulated and does not have --no-threads (so that
it creates about as many threads as "cpus". The
context involved has had 28 Hyper-V "cpus".
Attaching-then-detaching with gdb gets the process
going again.

When lld is native, I've never seen such a hangup.

Just for illustration (a 28 "cpu" under-Hyper-V
context for the example):

Reading symbols from /usr/local/bin/qemu-arm-static...done.
(gdb) attach 14501
Attaching to program: /usr/local/bin/qemu-arm-static, process 14501
[New LWP 101722 of process 14501]
[New LWP 101937 of process 14501]
[New LWP 101967 of process 14501]
[New LWP 102144 of process 14501]
[New LWP 102153 of process 14501]
[New LWP 102128 of process 14501]
[New LWP 102166 of process 14501]
[New LWP 102178 of process 14501]
[New LWP 102251 of process 14501]
[New LWP 102266 of process 14501]
[New LWP 102268 of process 14501]
[New LWP 102123 of process 14501]
[New LWP 102475 of process 14501]
[New LWP 102477 of process 14501]
[New LWP 102478 of process 14501]
[New LWP 102479 of process 14501]
[New LWP 102481 of process 14501]
[New LWP 102482 of process 14501]
[New LWP 102483 of process 14501]
[New LWP 102484 of process 14501]
[New LWP 102485 of process 14501]
[New LWP 102487 of process 14501]
[New LWP 102488 of process 14501]
[New LWP 102489 of process 14501]
[New LWP 102490 of process 14501]
[New LWP 102124 of process 14501]
[New LWP 102493 of process 14501]
[New LWP 102494 of process 14501]
[New LWP 102495 of process 14501]
[Switching to LWP 100873 of process 14501]
_umtx_op () at _umtx_op.S:3
3   RSYSCALL(_umtx_op)
(gdb) info threads
  Id   Target Id   Frame 
* 1LWP 100873 of process 14501 _umtx_op () at _umtx_op.S:3
  2LWP 101722 of process 14501 _umtx_op_err () at 
/usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
  3LWP 101937 of process 14501 _umtx_op () at _umtx_op.S:3
  4LWP 101967 of process 14501 _umtx_op () at _umtx_op.S:3
  5LWP 102144 of process 14501 _umtx_op () at _umtx_op.S:3
  6LWP 102153 of process 14501 _umtx_op () at _umtx_op.S:3
  7LWP 102128 of process 14501 _umtx_op () at _umtx_op.S:3
  8LWP 102166 of process 14501 _umtx_op () at _umtx_op.S:3
  9LWP 102178 of process 14501 _umtx_op () at _umtx_op.S:3
  10   LWP 102251 of process 14501 _umtx_op () at _umtx_op.S:3
  11   LWP 102266 of process 14501 _umtx_op () at _umtx_op.S:3
  12   LWP 102268 of process 14501 _umtx_op () at _umtx_op.S:3
  13   LWP 102123 of process 14501 _umtx_op () at _umtx_op.S:3
  14   LWP 102475 of process 14501 _umtx_op () at _umtx_op.S:3
  15   LWP 102477 of process 14501 _umtx_op () at _umtx_op.S:3
  16   LWP 102478 of process 14501 _umtx_op () at _umtx_op.S:3
  17   LWP 102479 of process 14501 _umtx_op () at _umtx_op.S:3
  18   LWP 102481 of process 14501 _umtx_op () at _umtx_op.S:3
  19   LWP 102482 of process 14501 _umtx_op () at _umtx_op.S:3
  20   LWP 102483 of process 14501 _umtx_op () at _umtx_op.S:3
  21   LWP 102484 of process 14501 _umtx_op () at _umtx_op.S:3
  22   LWP 102485 of process 14501 _umtx_op () at _umtx_op.S:3
  23   LWP 102487 of process 14501 _umtx_op () at _umtx_op.S:3
  24   LWP 102488 of process 14501 _umtx_op () at _umtx_op.S:3
  25   LWP 102489 of process 14501 _umtx_op () at _umtx_op.S:3
  26   LWP 102490 of process 14501 _umtx_op () at _umtx_op.S:3
  27   LWP 102124 of process 14501 _umtx_op () at _umtx_op.S:3
  28   LWP 102493 of process 14501 _umtx_op () at _umtx_op.S:3
  29   LWP 102494 of process 14501 _umtx_op () at _umtx_op.S:3
  30   LWP 102495 of process 14501 _umtx_op () at _umtx_op.S:3
(gdb) detach

Just FYI, a little detail:

The /usr/local/bin/qemu-arm-static above was the one running
lld emulated.

Thread 1 and threads 3-30 are similar by the call chain, although
thread 1 has main. Thread 2 is different in general.

With --no-thread the fanout does not happen. So far I've never
had a hangup with --no-thread.

(Overall using --no-thread is messy for builds of many ports
because the gcc*'s ld's reject the command line option and
this leads to build failures. Ports has no equivalents of
LDFLAGS.lld+=-Wl,--no-threads to make the option only show
up for lld. There are ports that mix clang with gcc's ld
instead of using lld so knowing just the compiler in use
is insufficient context.)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any 

Re: ports -r484565 : qemu-arm-static fails with: (start < end): backtrace included; start+len arithmetic overflow (abi_ulong wrap) for TARGET_FREEBSD_NR_mmap use

[Mark Millard via freebsd-ports]

On 2018-Nov-11, at 17:43, Kyle Evans  wrote:

> On Sun, Nov 11, 2018 at 5:24 AM Mark Millard  wrote:
>> 
>> I attached with gdb in order to stop at the assert and look around.
>> 
>> 
>> 
>> The following is a backtrace with notes and prints mixed in:
>> 
>> (gdb) bt
>> #0  thr_kill () at thr_kill.S:3
>> #1  0x6028a21f in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
>> #2  0x60204949 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
>> #3  0x6027855a in __assert (func=, file=> out>, line=, failedexpr=) at 
>> /usr/src/lib/libc/gen/assert.c:51
>> 
>> Note end==37146624 below vs. start (37146624 will show up again in later 
>> notes)
>> 
>> #4  0x60036243 in page_set_flags (start=4143968256, end=37146624, 
>> flags=9) at 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c:2077
>> 
>> Note start and len below:
>> 
>> #5  0x6003df2b in target_mmap (start=4143968256, len=188145664, 
>> prot=, flags=, fd=, 
>> offset=)
>>at 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c:626
>> 
>> (gdb) print/x start
>> $5 = 0xf6fff000
>> (gdb) print/x len
>> $6 = 0xb36e000
>> 
>> Note start+len for the above (without wrapping):
>> 
>> (gdb) print/x (long long)start + (long long)len
>> $10 = 0x10236d000
>> (gdb) print (long long)start + (long long)len
>> $11 = 4332113920
>> 
>> With wrapping:
>> 
>> (gdb) print/x start+len
>> $8 = 0x236d000
>> (gdb) print start+len
>> $9 = 37146624
>> 
>> And there is end's value again.
>> 
> 
> Hi,
> 
> This should be fixed as of ports r484702; please do try this and let
> us know how it goes.

I've updated ports to -r484783 and an amd64 -> armv7
poudriere-devel/qemu-user-static cross-build is in
progress. devel/cmake completed fine, overall about
63 ports have. The 1 port failure is not tied to
qemu-arm-static issues.

It will be hours before lang/gcc8 would finish. There
are somewhat over 70 ports to go overall.

So far so good.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ports head -r484783 : multimedia/libvpx built via poudriere-devel fails for: /bin/sh: as: not found

[Mark Millard via freebsd-ports]

[The armv7 head -r340287 based context has WITHOUT_BINUTILS= .]


echo 'Cflags: -I${includedir}' >> vpx.pc
as -meabi=5 --defsym ARCHITECTURE=7 -march=armv7-a -mfloat-abi=hard -mfpu=neon 
-I./ -I"/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0"/ -o 
vpx_dsp/arm/intrapred_neon_asm.asm.S.o vpx_dsp/arm/intrapred_neon_asm.asm.S
as -meabi=5 --defsym ARCHITECTURE=7 -march=armv7-a -mfloat-abi=hard -mfpu=neon 
-I./ -I"/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0"/ -o 
vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o 
vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S
as -meabi=5 --defsym ARCHITECTURE=7 -march=armv7-a -mfloat-abi=hard -mfpu=neon 
-I./ -I"/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0"/ -o 
vpx_dsp/arm/vpx_convolve8_avg_neon_asm.asm.S.o 
vpx_dsp/arm/vpx_convolve8_avg_neon_asm.asm.S
/bin/sh: as: not found
as -meabi=5 --defsym ARCHITECTURE=7 -march=armv7-a -mfloat-abi=hard -mfpu=neon 
-I./ -I"/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0"/ -o 
vpx_dsp/arm/vpx_convolve8_neon_asm.asm.S.o 
vpx_dsp/arm/vpx_convolve8_neon_asm.asm.S
gmake[2]: *** [Makefile:199: vpx_dsp/arm/intrapred_neon_asm.asm.S.o] Error 127
gmake[2]: *** Waiting for unfinished jobs
/bin/sh: as: not found
/bin/sh: as: not found
/bin/sh: as: not found
gmake[2]: *** [Makefile:199: vpx_dsp/arm/vpx_convolve_copy_neon_asm.asm.S.o] 
Error 127
gmake[2]: *** [Makefile:199: vpx_dsp/arm/vpx_convolve8_neon_asm.asm.S.o] Error 
127
gmake[2]: *** [Makefile:199: vpx_dsp/arm/vpx_convolve8_avg_neon_asm.asm.S.o] 
Error 127
gmake[1]: *** [Makefile:17: .DEFAULT] Error 2
gmake[1]: Leaving directory 
'/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Apparently multimedia/libvpx does not automatically use
devel/binutils material or other such when the system
does not have the gcc binutils toolchain, at least for
armv7.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports -r484565 : qemu-arm-static fails with: (start < end): backtrace included; start+len arithmetic overflow (abi_ulong wrap) for TARGET_FREEBSD_NR_mmap use

[Mark Millard via freebsd-ports]

On 2018-Nov-11, at 17:50, Mark Millard  wrote:

> On 2018-Nov-11, at 17:43, Kyle Evans  wrote:
> 
>> On Sun, Nov 11, 2018 at 5:24 AM Mark Millard  wrote:
>>> 
>>> I attached with gdb in order to stop at the assert and look around.
>>> 
>>> 
>>> 
>>> The following is a backtrace with notes and prints mixed in:
>>> 
>>> (gdb) bt
>>> #0  thr_kill () at thr_kill.S:3
>>> #1  0x6028a21f in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
>>> #2  0x60204949 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
>>> #3  0x6027855a in __assert (func=, file=>> out>, line=, failedexpr=) at 
>>> /usr/src/lib/libc/gen/assert.c:51
>>> 
>>> Note end==37146624 below vs. start (37146624 will show up again in later 
>>> notes)
>>> 
>>> #4  0x60036243 in page_set_flags (start=4143968256, end=37146624, 
>>> flags=9) at 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c:2077
>>> 
>>> Note start and len below:
>>> 
>>> #5  0x6003df2b in target_mmap (start=4143968256, len=188145664, 
>>> prot=, flags=, fd=, 
>>> offset=)
>>>   at 
>>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c:626
>>> 
>>> (gdb) print/x start
>>> $5 = 0xf6fff000
>>> (gdb) print/x len
>>> $6 = 0xb36e000
>>> 
>>> Note start+len for the above (without wrapping):
>>> 
>>> (gdb) print/x (long long)start + (long long)len
>>> $10 = 0x10236d000
>>> (gdb) print (long long)start + (long long)len
>>> $11 = 4332113920
>>> 
>>> With wrapping:
>>> 
>>> (gdb) print/x start+len
>>> $8 = 0x236d000
>>> (gdb) print start+len
>>> $9 = 37146624
>>> 
>>> And there is end's value again.
>>> 
>> 
>> Hi,
>> 
>> This should be fixed as of ports r484702; please do try this and let
>> us know how it goes.
> 
> I've updated ports to -r484783 and an amd64 -> armv7
> poudriere-devel/qemu-user-static cross-build is in
> progress. devel/cmake completed fine, overall about
> 63 ports have. The 1 port failure is not tied to
> qemu-arm-static issues.
> 
> It will be hours before lang/gcc8 would finish. There
> are somewhat over 70 ports to go overall.
> 
> So far so good.
> 

lang/gcc8 (full bootstrap) and the other about 70
ports built fine.

(There was one example of the lld hang-up, for which
I used a gdb attach/detach sequence to cause the
emulated lld to continue.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FYI: ports head -r484783 poudriere-devel with qemu-arm-static: sometimes hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

On 2018-Nov-12, at 10:18, Mark Millard  wrote:

> On 2018-Nov-12, at 05:54, Kyle Evans  wrote:
> 
>> On Sun, Nov 11, 2018 at 9:11 PM Mark Millard  wrote:
>>> 
>>> [I still can not produce the problem below on demand.
>>> It seems racy with no fixed context producing the
>>> problem as far as which port is building. But the
>>> general structure of what hangs is the same each
>>> time so far.]
>>> 
>>> The following is just an FYI for the other
>>> qemu-arm-static tied problem that I regularly run into.
>>> I do not have much useful information so far. It is
>>> not clear how I'd get such information.
>>> 
>> 
>> Hi,
>> 
>> Just so we're clear- in what kind of time frame did you start
>> observing this hang?
> 
> Unfortunately, I did no qemu-user-static use after
> 2018-Feb-6 until 2018-10-26. My list activity reported
> the problem for the first time on Oct. 26 and I had
> updated before using qemu-arm-static on the 26th.
> 
> Looks like back on Feb. 6 I was using:  qemu-user-static-2.11.50.g20171215_3
> 
> Looks like back on Oct. 26 I was using: qemu-user-static-2.11.50.g20180622_1
> 
> I'm now using qemu-user-static-2.11.50.g20181011 .
> 
> 
> For reference:
> 
> The Feb cross build logs for Feb 6 show things like:
> 
> =>> Building ports-mgmt/poudriere-devel
> build started at Tue Feb  6 17:39:36 PST 2018
> port directory: /usr/ports/ports-mgmt/poudriere-devel
> package name: poudriere-devel-3.2.99.20180202_2
> building for: FreeBSD FBSDFSSDjailVariant 12.0-CURRENT FreeBSD 12.0-CURRENT  
> r327485M  arm
> maintained by: bdrew...@freebsd.org
> Makefile ident:  $FreeBSD: head/ports-mgmt/poudriere-devel/Makefile 
> 461075 2018-02-06 16:33:15Z brd $
> Poudriere version: 3.2.99.20180202_2
> Host OSVERSION: 1200054
> Jail OSVERSION: 1200054
> 
> The amd64 (host) logs before that show for qemu-user-static:
> 
> =>> Building emulators/qemu-user-static
> build started at Sun Feb  4 11:22:59 PST 2018
> port directory: /usr/ports/emulators/qemu-user-static
> package name: qemu-user-static-2.11.50.g20171215_3
> building for: FreeBSD FBSDFSSDjailVariant 12.0-CURRENT FreeBSD 12.0-CURRENT  
> r327485M  amd64
> maintained by: sbr...@freebsd.org
> Makefile ident:  $FreeBSD: head/emulators/qemu-user-static/Makefile 
> 441455 2017-05-22 13:17:38Z linimon $
> Poudriere version: 3.2.99.20180202_1
> Host OSVERSION: 1200054
> Jail OSVERSION: 1200054
> 
> (I normally keep the system source code the same across TARGET_ARCH's,
> with some exceptions for powerpc families.)
> 
> Oct. 26 shows for qemu-user-static:
> 
> =>> Building emulators/qemu-user-static
> build started at Fri Oct 26 13:55:50 PDT 2018
> port directory: /usr/ports/emulators/qemu-user-static
> package name: qemu-user-static-2.11.50.g20180622_1
> building for: FreeBSD FBSDFSSDjailVariant 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #1 
> r339076:339432M: Mon Oct 22 17:48:28 PDT 2018 
> markmi@FBSDFSSD:/usr/obj/amd64_clang_alt/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
>   amd64
> maintained by: sbr...@freebsd.org
> Makefile ident:  $FreeBSD: head/emulators/qemu-user-static/Makefile 
> 441455 2017-05-22 13:17:38Z linimon $
> Poudriere version: 3.2.99.20180511
> Host OSVERSION: 1200084
> Jail OSVERSION: 1200063
> 
> The armv7 jail context would also be based on the same system source,
> mostly -r339076 source.
> 
> 
> Currently for qemu-user-static I'm at:
> 
> =>> Building emulators/qemu-user-static
> build started at Sun Nov 11 14:52:52 PST 2018
> port directory: /usr/ports/emulators/qemu-user-static
> package name: qemu-user-static-2.11.50.g20181011
> building for: FreeBSD FBSDFSSDjailVariant 13.0-CURRENT FreeBSD 13.0-CURRENT 
> amd64
> maintained by: sbr...@freebsd.org
> Makefile ident:  $FreeBSD: head/emulators/qemu-user-static/Makefile 
> 441455 2017-05-22 13:17:38Z linimon $
> Poudriere version: 3.2.99.20181024
> Host OSVERSION: 133
> Jail OSVERSION: 133


I did some buildworld's inside a bulk -i session.
I got a hangup that was not lld: an emulated
ctfmerge hangup. It too had a thread fanout, but
only 7 threads. The attach/detach sequence did
not start things going. The thread backtraces
look like for the lld example.

(gdb) info threads
  Id   Target Id   Frame 
* 1LWP 100502 of process 64885 _umtx_op () at _umtx_op.S:3
  2LWP 101208 of process 64885 _umtx_op_err () at 
/usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
  3LWP 102353 of process 64885 _umtx_op () at _umtx_op.S:3
  4LWP 101899 of process 64885 _umtx_op () at _umtx_op.S:3
  5LWP 101783 of process 64885 _umtx_op () at _umtx_op.S:3
  6LWP 101902 of process 64885 _umtx_op () at _umtx_op.S:3
  7LWP 101907 of process 64885 _umtx_op () at _umtx_op.S:3

(gdb) bt
#0  _umtx_op () at _umtx_op.S:3
#1  0x60050c34 in _umtx_wait_uint_private (addr=, 
target_val=, tsz=, t=, 
where=)
at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:258
#2  freebsd_lock_umutex 

Re: ports head -r484652: lang/ruby24 fails to amd64 -> armv7 cross build: qemu: uncaught target signal 11 (2 of them) [armv7 native build worked]

[Mark Millard via freebsd-ports]

[While the poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7
cross build failed, a native armv7 build worked. It turns out the
difference that matters is likely -O2 use vs -O use. More later
below.]

On 2018-Nov-10, at 23:29, Mark Millard  wrote:

> Poudriere-devel reported:
> 
> [00:18:32] [07] [00:02:56] Saved lang/ruby24 | ruby-2.4.5,1 wrkdir to: 
> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/ruby-2.4.5,1.tbz
> [00:18:32] [07] [00:02:56] Finished lang/ruby24 | ruby-2.4.5,1: Failed: build
> 
> The log showed:
> 
> --- miniruby ---
> linking miniruby
> --- .rbconfig.time ---
> --- encdb.h ---
> generating encdb.h
> --- .rbconfig.time ---
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> *** [.rbconfig.time] Error code 139
> 
> make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5
> --- encdb.h ---
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> *** [encdb.h] Error code 139
> 
> make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5
> 2 errors
> 
> 
> Despite how the above looks, I find only one .core file in the
> tar archive produced for the failure:
> 
> # find /wrkdirs/usr/ports/lang/ruby/ -name "*.core" -print
> /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/qemu_miniruby.core
> 
> Apparently qemu does not allow for separate files for distinct
> processes.
> 
> For that .core file I find (libexec/gdb):
> 
> # chroot /usr/obj/DESTDIRs/clang-armv7-installworld-poud
> # cd /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/
> # /usr/libexec/gdb miniruby qemu_miniruby.core 
> . . .
> (gdb) bt
> #0  0x00113f84 in rb_gc_writebarrier_unprotect (obj=4104601600) at gc.c:1119
> 1119  return RVALUE_WB_UNPROTECTED_BITMAP(obj) != 0;
> [New Thread f4b5d000 (LWP 100638/)]
> [New LWP 61684]
> Current language:  auto; currently minimal
> (gdb) bt
> #0  0x00113f84 in rb_gc_writebarrier_unprotect (obj=4104601600) at gc.c:1119
> #1  0x000c3fc8 in rb_include_class_new (module=4104569400, super= optimized out>) at ruby.h:1456
> #2  0x000c4424 in include_modules_at (klass=4104602160, c=4104602160, 
> module=4104569400, search_super=) at class.c:913
> #3  0x000c41f0 in rb_include_module (klass=4104602160, module=4104569400) at 
> class.c:870
> #4  0x001f6dec in Init_String () at string.c:10021
> #5  0x00129398 in rb_call_inits () at inits.c:28
> #6  0x00103bac in ruby_setup () at eval.c:60
> #7  0x00103be8 in ruby_init () at eval.c:76
> #8  0x000a3300 in main (argc=11, argv=0x9fffe41c) at main.c:35
> (gdb) up
> #1  0x000c3fc8 in rb_include_class_new (module=4104569400, super= optimized out>) at ruby.h:1456
> 1456  rb_gc_writebarrier_unprotect(x);
> (gdb) up
> #2  0x000c4424 in include_modules_at (klass=4104602160, c=4104602160, 
> module=4104569400, search_super=) at class.c:913
> 913   iclass = rb_include_class_new(module, RCLASS_SUPER(c));
> (gdb) up
> #3  0x000c41f0 in rb_include_module (klass=4104602160, module=4104569400) at 
> class.c:870
> 870   changed = include_modules_at(klass, RCLASS_ORIGIN(klass), module, 
> TRUE);
> (gdb) up
> #4  0x001f6dec in Init_String () at string.c:10021
> 10021 rb_include_module(rb_cString, rb_mComparable);
> (gdb) up
> #5  0x00129398 in rb_call_inits () at inits.c:28
> 28CALL(String);
> (gdb) up
> #6  0x00103bac in ruby_setup () at eval.c:60
> 60rb_call_inits();
> (gdb) up
> #7  0x00103be8 in ruby_init () at eval.c:76
> 76int state = ruby_setup();
> (gdb) up
> #8  0x000a3300 in main (argc=11, argv=0x9fffe41c) at main.c:35
> 35ruby_init();
> 
> (I'm not familiar with what details libexec/gdb gets
> right vs. wrong. But the call chain seems coherent.)
> 
> Host environment:
> 
> # uname -apKU
> FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r340287M: Fri Nov  9 
> 08:37:01 PST 2018 
> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
>   amd64 amd64 133 133

A prior example that fails for native armv7 builds
but works for poudriere-devel/qemu-arm-static/nxb-bin/
(native cross tools based) amd64 -> armv7 cross builds
is x11/pixman.

Previously I discovered that x11/pixman builds fine in
poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7
cross builds but a link fails during native armv7
builds. It turned out that with the host-native cross
tools involved -O2 was being used where native -O
was being used: the code in share/mk/sys.mk that
is designed to use -O for arm fails to do so and uses
-O2 instead.

(MACHINE_ARCH temporarily looks to be amd64, which
gets a -O2 put in CFLAGS instead of -O .)

ruby seems to go the other direction: with -O2 involved
something builds that fails to run during the build.
With -O involved instead ruby builds fine and produces
a ruby that works.

(I've not done any analysis to see if the -O2 based
build failure is because of code making assumption
that are not guaranteed vs. if the compiler/linker
is 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

[Tracking down -O2 vs. -O lead to share/mk/sys.mk instead of
to my materials. It in turn leads back to poudriere-devel with
qemu-user-static in use defining MACHINE_ARCH but without it
instead not doing so. share/mk/sys.mk behaves differently
for with vs. without the definition, leading to -O2 vs -O
differences in the two build contexts. Details later below.]

On 2018-Nov-14, at 13:05, Mark Millard  wrote:

> [Added: The original cross-build via poudriere-devel and qemu-user-static
> did not get this problem. I give details later. Sumamry: Looks like -O2
> was used for the cross build and -O was used for armv7 native. The
> difference is likely(?) from my materials but not supporting both ways of
> building is likely a problem with the port(?).]
> 
> On 2018-Nov-14, at 10:10, Mark Millard  wrote:
> 
>> I'll first note:
>> 
>> # /usr/bin/ld -v
>> LLD 6.0.1 (FreeBSD 335540-130) (compatible with GNU linkers)
>> 
>> and that I use:
>> 
>> CFLAGS.clang+= -mcpu=cortex-a7
>> CXXFLAGS.clang+= -mcpu=cortex-a7
>> CPPFLAGS.clang+= -mcpu=cortex-a7
>> 
>> in the src.conf like ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host
>> file that I used.
>> 
>> The error reports were:
>> 
>> --- libpixman-1.la ---
>> /bin/sh ../libtool  --tag=CC--mode=link cc   -O -pipe -mcpu=cortex-a7  
>> -g -fno-strict-aliasing  -Wall -Wdeclaration-after-statement 
>> -Wno-unused-local-typedefs -fno-strict-aliasing -fvisibility=hid
>> den -version-info 34:0:34  -no-undefined   -pthread   -o  libpixman-1.la 
>> -rpath /usr/local/lib pixman.lo pixman-access.lo pixman-access-accessors.lo  
>> pixman-bits-image.lo pixman-combine32.lo  pixm
>> an-combine-float.lo pixman-conical-gradient.lo  pixman-filter.lo 
>> pixman-x86.lo pixman-mips.lo pixman-arm.lo  pixman-ppc.lo pixman-edge.lo 
>> pixman-edge-accessors.lo  pixman-fast-path.lo pixman-glyph.lo 
>> pixman-general.lo  pixman-gradient-walker.lo pixman-image.lo  
>> pixman-implementation.lo pixman-linear-gradient.lo  pixman-matrix.lo 
>> pixman-noop.lo pixman-radial-gradient.lo  pixman-region16.lo pixman-r
>> egion32.lo pixman-solid-fill.lo  pixman-timer.lo pixman-trap.lo 
>> pixman-utils.lo  -lm   -lm   libpixman-arm-simd.la libpixman-arm-neon.la 
>> -lm
>> libtool: link: cc -shared  -fPIC -DPIC  .libs/pixman.o .libs/pixman-access.o 
>> .libs/pixman-access-accessors.o .libs/pixman-bits-image.o 
>> .libs/pixman-combine32.o .libs/pixman-combine-float.o .libs/pixma
>> n-conical-gradient.o .libs/pixman-filter.o .libs/pixman-x86.o 
>> .libs/pixman-mips.o .libs/pixman-arm.o .libs/pixman-ppc.o 
>> .libs/pixman-edge.o .libs/pixman-edge-accessors.o .libs/pixman-fast-path.o 
>> .libs
>> /pixman-glyph.o .libs/pixman-general.o .libs/pixman-gradient-walker.o 
>> .libs/pixman-image.o .libs/pixman-implementation.o 
>> .libs/pixman-linear-gradient.o .libs/pixman-matrix.o .libs/pixman-noop.o 
>> .libs/
>> pixman-radial-gradient.o .libs/pixman-region16.o .libs/pixman-region32.o 
>> .libs/pixman-solid-fill.o .libs/pixman-timer.o .libs/pixman-trap.o 
>> .libs/pixman-utils.o  -Wl,--whole-archive ./.libs/libpixman-
>> arm-simd.a ./.libs/libpixman-arm-neon.a -Wl,--no-whole-archive  -lm  -O 
>> -mcpu=cortex-a7 -g -pthread   -pthread -Wl,-soname -Wl,libpixman-1.so.0 -o 
>> .libs/libpixman-1.so.0.34.0
>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
>> symbol in readonly segment; recompile object files with -fPIC
> defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
> referenced by pixman-arm-simd-asm-scaled.o:(.text+0x1B8) in archive 
> ./.libs/libpixman-arm-simd.a
>> 
>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
>> symbol in readonly segment; recompile object files with -fPIC
> defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
> referenced by pixman-arm-simd-asm-scaled.o:(.text+0x374) in archive 
> ./.libs/libpixman-arm-simd.a
>> 
>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
>> symbol in readonly segment; recompile object files with -fPIC
> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
> referenced by pixman-arm-neon-asm.o:(.text+0x17AC) in archive 
> ./.libs/libpixman-arm-neon.a
>> 
>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
>> symbol in readonly segment; recompile object files with -fPIC
> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
> referenced by pixman-arm-neon-asm.o:(.text+0x1814) in archive 
> ./.libs/libpixman-arm-neon.a
>> 
>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
>> symbol in readonly segment; recompile object files with -fPIC
> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
> referenced by pixman-arm-neon-asm.o:(.text+0x1A38) in archive 
> ./.libs/libpixman-arm-neon.a
>> 
>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
>> 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

[Looking at package fallout logs: the official armv6 and armv7
builds are using -O2 because of MACHINE_ARCH being defined
because of qemu-user-static use. (mips too?) The logic in
share/mk/sys.mk is not causing -O . An implication
is that -O2 for armv6 and armv7 is probably far more tested
than people generally expect. The share/mk/sys.mk change
goes back to -r319861 2017-Jun-12 . Previously the logic
would have caused -O use for armv6 or armv7 in MACHINE_ARCH .]

On 2018-Nov-14, at 13:51, Mark Millard  wrote:

> [Tracking down -O2 vs. -O lead to share/mk/sys.mk instead of
> to my materials. It in turn leads back to poudriere-devel with
> qemu-user-static in use defining MACHINE_ARCH but without it
> instead not doing so. share/mk/sys.mk behaves differently
> for with vs. without the definition, leading to -O2 vs -O
> differences in the two build contexts. Details later below.]
> 
> On 2018-Nov-14, at 13:05, Mark Millard  wrote:
> 
>> [Added: The original cross-build via poudriere-devel and qemu-user-static
>> did not get this problem. I give details later. Sumamry: Looks like -O2
>> was used for the cross build and -O was used for armv7 native. The
>> difference is likely(?) from my materials but not supporting both ways of
>> building is likely a problem with the port(?).]
>> 
>> On 2018-Nov-14, at 10:10, Mark Millard  wrote:
>> 
>>> I'll first note:
>>> 
>>> # /usr/bin/ld -v
>>> LLD 6.0.1 (FreeBSD 335540-130) (compatible with GNU linkers)
>>> 
>>> and that I use:
>>> 
>>> CFLAGS.clang+= -mcpu=cortex-a7
>>> CXXFLAGS.clang+= -mcpu=cortex-a7
>>> CPPFLAGS.clang+= -mcpu=cortex-a7
>>> 
>>> in the src.conf like ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host
>>> file that I used.
>>> 
>>> The error reports were:
>>> 
>>> --- libpixman-1.la ---
>>> /bin/sh ../libtool  --tag=CC--mode=link cc   -O -pipe -mcpu=cortex-a7  
>>> -g -fno-strict-aliasing  -Wall -Wdeclaration-after-statement 
>>> -Wno-unused-local-typedefs -fno-strict-aliasing -fvisibility=hid
>>> den -version-info 34:0:34  -no-undefined   -pthread   -o  
>>> libpixman-1.la -rpath /usr/local/lib pixman.lo pixman-access.lo 
>>> pixman-access-accessors.lo  pixman-bits-image.lo pixman-combine32.lo  pixm
>>> an-combine-float.lo pixman-conical-gradient.lo  pixman-filter.lo 
>>> pixman-x86.lo pixman-mips.lo pixman-arm.lo  pixman-ppc.lo pixman-edge.lo 
>>> pixman-edge-accessors.lo  pixman-fast-path.lo pixman-glyph.lo 
>>> pixman-general.lo  pixman-gradient-walker.lo pixman-image.lo  
>>> pixman-implementation.lo pixman-linear-gradient.lo  pixman-matrix.lo 
>>> pixman-noop.lo pixman-radial-gradient.lo  pixman-region16.lo pixman-r
>>> egion32.lo pixman-solid-fill.lo  pixman-timer.lo pixman-trap.lo 
>>> pixman-utils.lo  -lm   -lm   libpixman-arm-simd.la 
>>> libpixman-arm-neon.la -lm
>>> libtool: link: cc -shared  -fPIC -DPIC  .libs/pixman.o 
>>> .libs/pixman-access.o .libs/pixman-access-accessors.o 
>>> .libs/pixman-bits-image.o .libs/pixman-combine32.o 
>>> .libs/pixman-combine-float.o .libs/pixma
>>> n-conical-gradient.o .libs/pixman-filter.o .libs/pixman-x86.o 
>>> .libs/pixman-mips.o .libs/pixman-arm.o .libs/pixman-ppc.o 
>>> .libs/pixman-edge.o .libs/pixman-edge-accessors.o .libs/pixman-fast-path.o 
>>> .libs
>>> /pixman-glyph.o .libs/pixman-general.o .libs/pixman-gradient-walker.o 
>>> .libs/pixman-image.o .libs/pixman-implementation.o 
>>> .libs/pixman-linear-gradient.o .libs/pixman-matrix.o .libs/pixman-noop.o 
>>> .libs/
>>> pixman-radial-gradient.o .libs/pixman-region16.o .libs/pixman-region32.o 
>>> .libs/pixman-solid-fill.o .libs/pixman-timer.o .libs/pixman-trap.o 
>>> .libs/pixman-utils.o  -Wl,--whole-archive ./.libs/libpixman-
>>> arm-simd.a ./.libs/libpixman-arm-neon.a -Wl,--no-whole-archive  -lm  -O 
>>> -mcpu=cortex-a7 -g -pthread   -pthread -Wl,-soname -Wl,libpixman-1.so.0 -o 
>>> .libs/libpixman-1.so.0.34.0
>>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against 
>>> local symbol in readonly segment; recompile object files with -fPIC
>> defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
>> referenced by pixman-arm-simd-asm-scaled.o:(.text+0x1B8) in archive 
>> ./.libs/libpixman-arm-simd.a
>>> 
>>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against 
>>> local symbol in readonly segment; recompile object files with -fPIC
>> defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
>> referenced by pixman-arm-simd-asm-scaled.o:(.text+0x374) in archive 
>> ./.libs/libpixman-arm-simd.a
>>> 
>>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against 
>>> local symbol in readonly segment; recompile object files with -fPIC
>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>> referenced by pixman-arm-neon-asm.o:(.text+0x17AC) in archive 
>> ./.libs/libpixman-arm-neon.a
>>> 
>>> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against 
>>> local symbol in readonly segment; 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

[Evidence from inside poudriere bulk -j... -i ports-mgmt/pkg .
Use of native /nxb-bin/. . . leads to MACHINE_ARCH being amd64
instead of armv7 or the like. See later supporting material.]

On 2018-Nov-14, at 14:38, Bryan Drewery  wrote:

> On 11/14/18 2:35 PM, Mark Millard wrote:
>> [Looking at package fallout logs: the official armv6 and armv7
>> builds are using -O2 because of MACHINE_ARCH being defined
>> because of qemu-user-static use. (mips too?) The logic in
>> share/mk/sys.mk is not causing -O . An implication
>> is that -O2 for armv6 and armv7 is probably far more tested
>> than people generally expect. The share/mk/sys.mk change
>> goes back to -r319861 2017-Jun-12 . Previously the logic
>> would have caused -O use for armv6 or armv7 in MACHINE_ARCH .]
> 
> r319861 doesn't look related here.

# more /etc/make.conf 
.sinclude "/etc/make.nxb.conf"
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PORTSDIR=/usr/ports
PACKAGES=/packages
DISTDIR=/distfiles
FORCE_PACKAGE=yes
PACKAGE_BUILDING=yes
PACKAGE_BUILDING_FLAVORS=yes
MACHINE=arm
MACHINE_ARCH=armv7
ARCH=${MACHINE_ARCH}
 /usr/local/etc/poudriere.d/make.conf 
 /usr/ports/Mk/Scripts/ports_env.sh 
_CCVERSION_9d218390=FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) 
(based on LLVM 6.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf Thread model: 
posix InstalledDir: /nxb-bin/usr/bin
_ALTCCVERSION_9d218390=none
_CXXINTERNAL_9c45a5b1=FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 
335540) (based on LLVM 6.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf 
Thread model: posix InstalledDir: /nxb-bin/usr/bin "/nxb-bin/usr/bin/ld" 
"--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" 
"--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" 
"/usr/lib/crtbegin.o" "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" 
"--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"
CC_OUTPUT_9d218390_58173849=yes
CC_OUTPUT_9d218390_9bdba57c=yes
CC_OUTPUT_9d218390_6a4fe7f5=yes
CC_OUTPUT_9d218390_6bcac02b=yes
CC_OUTPUT_9d218390_67d20829=yes
CC_OUTPUT_9d218390_bfa62e83=yes
CC_OUTPUT_9d218390_f0b4d593=yes
CC_OUTPUT_9d218390_308abb44=yes
CC_OUTPUT_9d218390_f00456e5=yes
CC_OUTPUT_9d218390_65ad290d=yes
CC_OUTPUT_9d218390_f2776b26=yes
CC_OUTPUT_9d218390_b2657cc3=yes
CC_OUTPUT_9d218390_380987f7=yes
CC_OUTPUT_9d218390_160933ec=yes
CC_OUTPUT_9d218390_fb62803b=yes
_OBJC_CCVERSION_9d218390=FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 
335540) (based on LLVM 6.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf 
Thread model: posix InstalledDir: /nxb-bin/usr/bin
_OBJC_ALTCCVERSION_9d218390=none
ARCH=armv7
OPSYS=FreeBSD
_OSRELEASE=13.0-CURRENT
OSREL=13.0
OSVERSION=133
PYTHONBASE=/usr/local
_SMP_CPUS=32
CONFIGURE_MAX_CMD_LEN=262144
HAVE_PORTS_ENV=1
 Misc Poudriere 
GID=0
UID=0
PACKAGES=/packages

# more /etc/src.conf
/etc/src.conf: No such file or directory

# more Makefile
all:
echo ${MACHINE_ARCH}
echo ${MACHINE_CPUARCH}
echo ${CFLAGS}

# make
echo armv7
armv7
echo arm
arm
echo -O2 -pipe
-O2 -pipe

# grep -r "\-O2" /usr/src/share/mk/
/usr/src/share/mk/sys.mk:CFLAGS ?=  -O2 -pipe

# grep -r "\-pipe" /usr/src/share/mk/
/usr/src/share/mk/sys.mk:CFLAGS ?=  -O -pipe
/usr/src/share/mk/sys.mk:CFLAGS ?=  -O2 -pipe

Those lines come from:

.if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "mips"
CFLAGS  ?=  -O -pipe
.else
CFLAGS  ?=  -O2 -pipe
.endif

So I used:

# make -dA 2>2mmjnk.txt 1>1mmjnk.txt

and looked for the first -pipe in 2mmjnk.txt. (It is also
the first -O , in this case -O2 .)

. . .
Got 
'C/mips(n32|64)?(el)?(hf)?/mips/:C/arm(v[67])?(eb)?/arm/:C/powerpc(64|spe)/powerpc/:C/riscv64(sf)?/riscv/'
 from '${__TO_CPUARCH}'}
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "mips(n32|64)?(el)?(hf)?"
Modifier pattern: "mips"
Result[MACHINE_ARCH] of :C is "amd64"
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "arm(v[67])?(eb)?"
Modifier pattern: "arm"
Result[MACHINE_ARCH] of :C is "amd64"
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "powerpc(64|spe)"
Modifier pattern: "powerpc"
Result[MACHINE_ARCH] of :C is "amd64"
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "riscv64(sf)?"
Modifier pattern: "riscv"
Result[MACHINE_ARCH] of :C is "amd64"
lhs = "amd64", rhs = "arm", op = ==
Got 
'C/mips(n32|64)?(el)?(hf)?/mips/:C/arm(v[67])?(eb)?/arm/:C/powerpc(64|spe)/powerpc/:C/riscv64(sf)?/riscv/'
 from '${__TO_CPUARCH}'}
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "mips(n32|64)?(el)?(hf)?"
Modifier pattern: "mips"
Result[MACHINE_ARCH] of :C is "amd64"
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "arm(v[67])?(eb)?"
Modifier pattern: "arm"
Result[MACHINE_ARCH] of :C is "amd64"
Applying[MACHINE_ARCH] :C to "amd64"
Modifier pattern: "powerpc(64|spe)"
Modifier pattern: "powerpc"
Result[MACHINE_ARCH] 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

On 2018-Nov-14, at 14:38, Bryan Drewery  wrote:

> On 11/14/18 2:35 PM, Mark Millard wrote:
>> [Looking at package fallout logs: the official armv6 and armv7
>> builds are using -O2 because of MACHINE_ARCH being defined
>> because of qemu-user-static use. (mips too?) The logic in
>> share/mk/sys.mk is not causing -O . An implication
>> is that -O2 for armv6 and armv7 is probably far more tested
>> than people generally expect. The share/mk/sys.mk change
>> goes back to -r319861 2017-Jun-12 . Previously the logic
>> would have caused -O use for armv6 or armv7 in MACHINE_ARCH .]
> 
> r319861 doesn't look related here.

I think that you are right.

The fallout logs do show the -O2 for armv6 and armv7
use though, not the -O use.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

[Looks like there are 2 stages involved in that
2mmjnk.txt file that I generated. Before
MACHINE_ARCH is explicitly assigned and after.]

On 2018-Nov-14, at 15:40, Mark Millard  wrote:

> [Evidence from inside poudriere bulk -j... -i ports-mgmt/pkg .
> Use of native /nxb-bin/. . . leads to MACHINE_ARCH being amd64
> instead of armv7 or the like. See later supporting material.]
> 
> On 2018-Nov-14, at 14:38, Bryan Drewery  wrote:
> 
>> On 11/14/18 2:35 PM, Mark Millard wrote:
>>> [Looking at package fallout logs: the official armv6 and armv7
>>> builds are using -O2 because of MACHINE_ARCH being defined
>>> because of qemu-user-static use. (mips too?) The logic in
>>> share/mk/sys.mk is not causing -O . An implication
>>> is that -O2 for armv6 and armv7 is probably far more tested
>>> than people generally expect. The share/mk/sys.mk change
>>> goes back to -r319861 2017-Jun-12 . Previously the logic
>>> would have caused -O use for armv6 or armv7 in MACHINE_ARCH .]
>> 
>> r319861 doesn't look related here.
> 
> # more /etc/make.conf 
> .sinclude "/etc/make.nxb.conf"
> USE_PACKAGE_DEPENDS=yes
> BATCH=yes
> WRKDIRPREFIX=/wrkdirs
> PORTSDIR=/usr/ports
> PACKAGES=/packages
> DISTDIR=/distfiles
> FORCE_PACKAGE=yes
> PACKAGE_BUILDING=yes
> PACKAGE_BUILDING_FLAVORS=yes
> MACHINE=arm
> MACHINE_ARCH=armv7
> ARCH=${MACHINE_ARCH}
>  /usr/local/etc/poudriere.d/make.conf 
>  /usr/ports/Mk/Scripts/ports_env.sh 
> _CCVERSION_9d218390=FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 
> 335540) (based on LLVM 6.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf 
> Thread model: posix InstalledDir: /nxb-bin/usr/bin
> _ALTCCVERSION_9d218390=none
> _CXXINTERNAL_9c45a5b1=FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 
> 335540) (based on LLVM 6.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf 
> Thread model: posix InstalledDir: /nxb-bin/usr/bin "/nxb-bin/usr/bin/ld" 
> "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" 
> "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" 
> "/usr/lib/crtbegin.o" "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" 
> "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" 
> "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"
> CC_OUTPUT_9d218390_58173849=yes
> CC_OUTPUT_9d218390_9bdba57c=yes
> CC_OUTPUT_9d218390_6a4fe7f5=yes
> CC_OUTPUT_9d218390_6bcac02b=yes
> CC_OUTPUT_9d218390_67d20829=yes
> CC_OUTPUT_9d218390_bfa62e83=yes
> CC_OUTPUT_9d218390_f0b4d593=yes
> CC_OUTPUT_9d218390_308abb44=yes
> CC_OUTPUT_9d218390_f00456e5=yes
> CC_OUTPUT_9d218390_65ad290d=yes
> CC_OUTPUT_9d218390_f2776b26=yes
> CC_OUTPUT_9d218390_b2657cc3=yes
> CC_OUTPUT_9d218390_380987f7=yes
> CC_OUTPUT_9d218390_160933ec=yes
> CC_OUTPUT_9d218390_fb62803b=yes
> _OBJC_CCVERSION_9d218390=FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 
> 335540) (based on LLVM 6.0.1) Target: armv7-unknown-freebsd13.0-gnueabihf 
> Thread model: posix InstalledDir: /nxb-bin/usr/bin
> _OBJC_ALTCCVERSION_9d218390=none
> ARCH=armv7
> OPSYS=FreeBSD
> _OSRELEASE=13.0-CURRENT
> OSREL=13.0
> OSVERSION=133
> PYTHONBASE=/usr/local
> _SMP_CPUS=32
> CONFIGURE_MAX_CMD_LEN=262144
> HAVE_PORTS_ENV=1
>  Misc Poudriere 
> GID=0
> UID=0
> PACKAGES=/packages
> 
> # more /etc/src.conf
> /etc/src.conf: No such file or directory
> 
> # more Makefile
> all:
>echo ${MACHINE_ARCH}
>echo ${MACHINE_CPUARCH}
>echo ${CFLAGS}
> 
> # make
> echo armv7
> armv7
> echo arm
> arm
> echo -O2 -pipe
> -O2 -pipe
> 
> # grep -r "\-O2" /usr/src/share/mk/
> /usr/src/share/mk/sys.mk:CFLAGS   ?=  -O2 -pipe
> 
> # grep -r "\-pipe" /usr/src/share/mk/
> /usr/src/share/mk/sys.mk:CFLAGS   ?=  -O -pipe
> /usr/src/share/mk/sys.mk:CFLAGS   ?=  -O2 -pipe
> 
> Those lines come from:
> 
> .if ${MACHINE_CPUARCH} == "arm" || ${MACHINE_CPUARCH} == "mips"
> CFLAGS  ?=  -O -pipe
> .else
> CFLAGS  ?=  -O2 -pipe
> .endif
> 
> So I used:
> 
> # make -dA 2>2mmjnk.txt 1>1mmjnk.txt
> 
> and looked for the first -pipe in 2mmjnk.txt. (It is also
> the first -O , in this case -O2 .)
> 
> . . .
> Got 
> 'C/mips(n32|64)?(el)?(hf)?/mips/:C/arm(v[67])?(eb)?/arm/:C/powerpc(64|spe)/powerpc/:C/riscv64(sf)?/riscv/'
>  from '${__TO_CPUARCH}'}
> Applying[MACHINE_ARCH] :C to "amd64"
> Modifier pattern: "mips(n32|64)?(el)?(hf)?"
> Modifier pattern: "mips"
> Result[MACHINE_ARCH] of :C is "amd64"
> Applying[MACHINE_ARCH] :C to "amd64"
> Modifier pattern: "arm(v[67])?(eb)?"
> Modifier pattern: "arm"
> Result[MACHINE_ARCH] of :C is "amd64"
> Applying[MACHINE_ARCH] :C to "amd64"
> Modifier pattern: "powerpc(64|spe)"
> Modifier pattern: "powerpc"
> Result[MACHINE_ARCH] of :C is "amd64"
> Applying[MACHINE_ARCH] :C to "amd64"
> Modifier pattern: "riscv64(sf)?"
> Modifier pattern: "riscv"
> Result[MACHINE_ARCH] of :C is "amd64"
> lhs = "amd64", rhs = "arm", op = ==
> Got 
> 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

On 2018-Nov-14, at 17:45, Bryan Drewery  wrote:

> I think the real problem here is that Poudriere is setting MACHINE_ARCH
> in make.conf and sys.mk loads make.conf *after* checking MACHINE_CPUARCH
> (derived from MACHINE_ARCH) to determine CFLAGS; The .if is expanding
> MACHINE_CPUARCH before make.conf is included.
> 
> We probably need a make-env.conf thing like src-env.conf to allow
> modifying sys.mk earlier.

Cool.


We still get the result that arm[67], and possibly some mips,
have had a lot of -O2 use based on what has historically been
done by the qemu-user-static based official-build servers.

And that leads to questioning the need for -O instead of -O2
for armv[67] and possibly some mips contexts.

Or, going the other way: Should -O be forced and have an
exp run for, say armv7 ? An example of what would be found is
what I ran into for x11/pixman when its build used -O (native)
instead of -O2 (cross-build via qemu-user-static) and a link
command failed for -O use. (It was the failure that started my
looking for what was different from my prior cross-build that
had worked.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

[My wording presumed some context not presented.]

On 2018-Nov-14, at 18:21, Mark Millard  wrote:

> On 2018-Nov-14, at 17:45, Bryan Drewery  wrote:
> 
>> I think the real problem here is that Poudriere is setting MACHINE_ARCH
>> in make.conf and sys.mk loads make.conf *after* checking MACHINE_CPUARCH
>> (derived from MACHINE_ARCH) to determine CFLAGS; The .if is expanding
>> MACHINE_CPUARCH before make.conf is included.
>> 
>> We probably need a make-env.conf thing like src-env.conf to allow
>> modifying sys.mk earlier.
> 
> Cool.
> 
> 
> We still get the result that arm[67], and possibly some mips,
> have had a lot of -O2 use based on what has historically been
> done by the qemu-user-static based official-build servers.
 
The reference to qemu-user-static was meant to be for
with /nxb-bin/. . . (or some form of native tools). It
is the native tools that initially have MACHINE_ARCH
being amd64 by default for the example contexts.

Absent that, qemu-arm-static would likely report armv6 for
all arm's until the explicit assignment. (The "armv6" is a
single compile-time constant in the qemu-arm-static
source at this time.) So this likely would behave as on
a native build: -O .

> And that leads to questioning the need for -O instead of -O2
> for armv[67] and possibly some mips contexts.
> 
> Or, going the other way: Should -O be forced and have an
> exp run for, say armv7 ? An example of what would be found is
> what I ran into for x11/pixman when its build used -O (native)
> instead of -O2 (cross-build via qemu-user-static) and a link
> command failed for -O use. (It was the failure that started my
> looking for what was different from my prior cross-build that
> had worked.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FYI: ports head -r484783 poudriere-devel with qemu-arm-static: sometimes hangs between a cc (wait) and its child ld (uwait)

[Mark Millard via freebsd-ports]

On 2018-Nov-12, at 05:54, Kyle Evans  wrote:

> On Sun, Nov 11, 2018 at 9:11 PM Mark Millard  wrote:
>> 
>> [I still can not produce the problem below on demand.
>> It seems racy with no fixed context producing the
>> problem as far as which port is building. But the
>> general structure of what hangs is the same each
>> time so far.]
>> 
>> The following is just an FYI for the other
>> qemu-arm-static tied problem that I regularly run into.
>> I do not have much useful information so far. It is
>> not clear how I'd get such information.
>> 
> 
> Hi,
> 
> Just so we're clear- in what kind of time frame did you start
> observing this hang?

Unfortunately, I did no qemu-user-static use after
2018-Feb-6 until 2018-10-26. My list activity reported
the problem for the first time on Oct. 26 and I had
updated before using qemu-arm-static on the 26th.

Looks like back on Feb. 6 I was using:  qemu-user-static-2.11.50.g20171215_3

Looks like back on Oct. 26 I was using: qemu-user-static-2.11.50.g20180622_1

I'm now using qemu-user-static-2.11.50.g20181011 .


For reference:

The Feb cross build logs for Feb 6 show things like:

=>> Building ports-mgmt/poudriere-devel
build started at Tue Feb  6 17:39:36 PST 2018
port directory: /usr/ports/ports-mgmt/poudriere-devel
package name: poudriere-devel-3.2.99.20180202_2
building for: FreeBSD FBSDFSSDjailVariant 12.0-CURRENT FreeBSD 12.0-CURRENT  
r327485M  arm
maintained by: bdrew...@freebsd.org
Makefile ident:  $FreeBSD: head/ports-mgmt/poudriere-devel/Makefile 461075 
2018-02-06 16:33:15Z brd $
Poudriere version: 3.2.99.20180202_2
Host OSVERSION: 1200054
Jail OSVERSION: 1200054

The amd64 (host) logs before that show for qemu-user-static:

=>> Building emulators/qemu-user-static
build started at Sun Feb  4 11:22:59 PST 2018
port directory: /usr/ports/emulators/qemu-user-static
package name: qemu-user-static-2.11.50.g20171215_3
building for: FreeBSD FBSDFSSDjailVariant 12.0-CURRENT FreeBSD 12.0-CURRENT  
r327485M  amd64
maintained by: sbr...@freebsd.org
Makefile ident:  $FreeBSD: head/emulators/qemu-user-static/Makefile 441455 
2017-05-22 13:17:38Z linimon $
Poudriere version: 3.2.99.20180202_1
Host OSVERSION: 1200054
Jail OSVERSION: 1200054

(I normally keep the system source code the same across TARGET_ARCH's,
with some exceptions for powerpc families.)

Oct. 26 shows for qemu-user-static:

=>> Building emulators/qemu-user-static
build started at Fri Oct 26 13:55:50 PDT 2018
port directory: /usr/ports/emulators/qemu-user-static
package name: qemu-user-static-2.11.50.g20180622_1
building for: FreeBSD FBSDFSSDjailVariant 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #1 
r339076:339432M: Mon Oct 22 17:48:28 PDT 2018 
markmi@FBSDFSSD:/usr/obj/amd64_clang_alt/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
  amd64
maintained by: sbr...@freebsd.org
Makefile ident:  $FreeBSD: head/emulators/qemu-user-static/Makefile 441455 
2017-05-22 13:17:38Z linimon $
Poudriere version: 3.2.99.20180511
Host OSVERSION: 1200084
Jail OSVERSION: 1200063

The armv7 jail context would also be based on the same system source,
mostly -r339076 source.


Currently for qemu-user-static I'm at:

=>> Building emulators/qemu-user-static
build started at Sun Nov 11 14:52:52 PST 2018
port directory: /usr/ports/emulators/qemu-user-static
package name: qemu-user-static-2.11.50.g20181011
building for: FreeBSD FBSDFSSDjailVariant 13.0-CURRENT FreeBSD 13.0-CURRENT 
amd64
maintained by: sbr...@freebsd.org
Makefile ident:  $FreeBSD: head/emulators/qemu-user-static/Makefile 441455 
2017-05-22 13:17:38Z linimon $
Poudriere version: 3.2.99.20181024
Host OSVERSION: 133
Jail OSVERSION: 133


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

I'll first note:

# /usr/bin/ld -v
LLD 6.0.1 (FreeBSD 335540-130) (compatible with GNU linkers)

and that I use:

CFLAGS.clang+= -mcpu=cortex-a7
CXXFLAGS.clang+= -mcpu=cortex-a7
CPPFLAGS.clang+= -mcpu=cortex-a7

in the src.conf like ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host
file that I used.

The error reports were:

--- libpixman-1.la ---
/bin/sh ../libtool  --tag=CC--mode=link cc   -O -pipe -mcpu=cortex-a7  -g 
-fno-strict-aliasing  -Wall -Wdeclaration-after-statement 
-Wno-unused-local-typedefs -fno-strict-aliasing -fvisibility=hid
den -version-info 34:0:34  -no-undefined   -pthread   -o  libpixman-1.la 
-rpath /usr/local/lib pixman.lo pixman-access.lo pixman-access-accessors.lo  
pixman-bits-image.lo pixman-combine32.lo  pixm
an-combine-float.lo pixman-conical-gradient.lo  pixman-filter.lo pixman-x86.lo 
pixman-mips.lo pixman-arm.lo  pixman-ppc.lo pixman-edge.lo 
pixman-edge-accessors.lo  pixman-fast-path.lo pixman-glyph.lo 
pixman-general.lo  pixman-gradient-walker.lo pixman-image.lo  
pixman-implementation.lo pixman-linear-gradient.lo  pixman-matrix.lo 
pixman-noop.lo pixman-radial-gradient.lo  pixman-region16.lo pixman-r
egion32.lo pixman-solid-fill.lo  pixman-timer.lo pixman-trap.lo pixman-utils.lo 
 -lm   -lm   libpixman-arm-simd.la libpixman-arm-neon.la -lm
libtool: link: cc -shared  -fPIC -DPIC  .libs/pixman.o .libs/pixman-access.o 
.libs/pixman-access-accessors.o .libs/pixman-bits-image.o 
.libs/pixman-combine32.o .libs/pixman-combine-float.o .libs/pixma
n-conical-gradient.o .libs/pixman-filter.o .libs/pixman-x86.o 
.libs/pixman-mips.o .libs/pixman-arm.o .libs/pixman-ppc.o .libs/pixman-edge.o 
.libs/pixman-edge-accessors.o .libs/pixman-fast-path.o .libs
/pixman-glyph.o .libs/pixman-general.o .libs/pixman-gradient-walker.o 
.libs/pixman-image.o .libs/pixman-implementation.o 
.libs/pixman-linear-gradient.o .libs/pixman-matrix.o .libs/pixman-noop.o .libs/
pixman-radial-gradient.o .libs/pixman-region16.o .libs/pixman-region32.o 
.libs/pixman-solid-fill.o .libs/pixman-timer.o .libs/pixman-trap.o 
.libs/pixman-utils.o  -Wl,--whole-archive ./.libs/libpixman-
arm-simd.a ./.libs/libpixman-arm-neon.a -Wl,--no-whole-archive  -lm  -O 
-mcpu=cortex-a7 -g -pthread   -pthread -Wl,-soname -Wl,libpixman-1.so.0 -o 
.libs/libpixman-1.so.0.34.0
/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
>>> referenced by pixman-arm-simd-asm-scaled.o:(.text+0x1B8) in archive 
>>> ./.libs/libpixman-arm-simd.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
>>> referenced by pixman-arm-simd-asm-scaled.o:(.text+0x374) in archive 
>>> ./.libs/libpixman-arm-simd.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>>> referenced by pixman-arm-neon-asm.o:(.text+0x17AC) in archive 
>>> ./.libs/libpixman-arm-neon.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>>> referenced by pixman-arm-neon-asm.o:(.text+0x1814) in archive 
>>> ./.libs/libpixman-arm-neon.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>>> referenced by pixman-arm-neon-asm.o:(.text+0x1A38) in archive 
>>> ./.libs/libpixman-arm-neon.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>>> referenced by pixman-arm-neon-asm.o:(.text+0x1AFC) in archive 
>>> ./.libs/libpixman-arm-neon.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>>> referenced by pixman-arm-neon-asm.o:(.text+0x21C8) in archive 
>>> ./.libs/libpixman-arm-neon.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
>>> referenced by pixman-arm-neon-asm.o:(.text+0x2294) in archive 
>>> ./.libs/libpixman-arm-neon.a

/usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
symbol in readonly segment; recompile object files with -fPIC
>>> defined in 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC

[Mark Millard via freebsd-ports]

[Added: The original cross-build via poudriere-devel and qemu-user-static
did not get this problem. I give details later. Sumamry: Looks like -O2
was used for the cross build and -O was used for armv7 native. The
difference is likely(?) from my materials but not supporting both ways of
building is likely a problem with the port(?).]

On 2018-Nov-14, at 10:10, Mark Millard  wrote:

> I'll first note:
> 
> # /usr/bin/ld -v
> LLD 6.0.1 (FreeBSD 335540-130) (compatible with GNU linkers)
> 
> and that I use:
> 
> CFLAGS.clang+= -mcpu=cortex-a7
> CXXFLAGS.clang+= -mcpu=cortex-a7
> CPPFLAGS.clang+= -mcpu=cortex-a7
> 
> in the src.conf like ~/src.configs/src.conf.armv7-clang-bootstrap.armv7-host
> file that I used.
> 
> The error reports were:
> 
> --- libpixman-1.la ---
> /bin/sh ../libtool  --tag=CC--mode=link cc   -O -pipe -mcpu=cortex-a7  -g 
> -fno-strict-aliasing  -Wall -Wdeclaration-after-statement 
> -Wno-unused-local-typedefs -fno-strict-aliasing -fvisibility=hid
> den -version-info 34:0:34  -no-undefined   -pthread   -o  libpixman-1.la 
> -rpath /usr/local/lib pixman.lo pixman-access.lo pixman-access-accessors.lo  
> pixman-bits-image.lo pixman-combine32.lo  pixm
> an-combine-float.lo pixman-conical-gradient.lo  pixman-filter.lo 
> pixman-x86.lo pixman-mips.lo pixman-arm.lo  pixman-ppc.lo pixman-edge.lo 
> pixman-edge-accessors.lo  pixman-fast-path.lo pixman-glyph.lo 
> pixman-general.lo  pixman-gradient-walker.lo pixman-image.lo  
> pixman-implementation.lo pixman-linear-gradient.lo  pixman-matrix.lo 
> pixman-noop.lo pixman-radial-gradient.lo  pixman-region16.lo pixman-r
> egion32.lo pixman-solid-fill.lo  pixman-timer.lo pixman-trap.lo 
> pixman-utils.lo  -lm   -lm   libpixman-arm-simd.la libpixman-arm-neon.la  
>-lm
> libtool: link: cc -shared  -fPIC -DPIC  .libs/pixman.o .libs/pixman-access.o 
> .libs/pixman-access-accessors.o .libs/pixman-bits-image.o 
> .libs/pixman-combine32.o .libs/pixman-combine-float.o .libs/pixma
> n-conical-gradient.o .libs/pixman-filter.o .libs/pixman-x86.o 
> .libs/pixman-mips.o .libs/pixman-arm.o .libs/pixman-ppc.o .libs/pixman-edge.o 
> .libs/pixman-edge-accessors.o .libs/pixman-fast-path.o .libs
> /pixman-glyph.o .libs/pixman-general.o .libs/pixman-gradient-walker.o 
> .libs/pixman-image.o .libs/pixman-implementation.o 
> .libs/pixman-linear-gradient.o .libs/pixman-matrix.o .libs/pixman-noop.o 
> .libs/
> pixman-radial-gradient.o .libs/pixman-region16.o .libs/pixman-region32.o 
> .libs/pixman-solid-fill.o .libs/pixman-timer.o .libs/pixman-trap.o 
> .libs/pixman-utils.o  -Wl,--whole-archive ./.libs/libpixman-
> arm-simd.a ./.libs/libpixman-arm-neon.a -Wl,--no-whole-archive  -lm  -O 
> -mcpu=cortex-a7 -g -pthread   -pthread -Wl,-soname -Wl,libpixman-1.so.0 -o 
> .libs/libpixman-1.so.0.34.0
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
 referenced by pixman-arm-simd-asm-scaled.o:(.text+0x1B8) in archive 
 ./.libs/libpixman-arm-simd.a
> 
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-simd.a(pixman-arm-simd-asm-scaled.o)
 referenced by pixman-arm-simd-asm-scaled.o:(.text+0x374) in archive 
 ./.libs/libpixman-arm-simd.a
> 
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
 referenced by pixman-arm-neon-asm.o:(.text+0x17AC) in archive 
 ./.libs/libpixman-arm-neon.a
> 
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
 referenced by pixman-arm-neon-asm.o:(.text+0x1814) in archive 
 ./.libs/libpixman-arm-neon.a
> 
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
 referenced by pixman-arm-neon-asm.o:(.text+0x1A38) in archive 
 ./.libs/libpixman-arm-neon.a
> 
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
 referenced by pixman-arm-neon-asm.o:(.text+0x1AFC) in archive 
 ./.libs/libpixman-arm-neon.a
> 
> /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local 
> symbol in readonly segment; recompile object files with -fPIC
 defined in ./.libs/libpixman-arm-neon.a(pixman-arm-neon-asm.o)
 referenced by pixman-arm-neon-asm.o:(.text+0x21C8) in 

Re: Problems building rust with poudriere

[Mark Millard via freebsd-ports]

Christian Stærk xi at borderworlds.dk wrote on
Sun Nov 4 13:45:01 UTC 2018 :

> For some time, I've had problems building rust with poudriere.
> 
> Poudriere log: 
> https://borderworlds.dk/~xi/rust-1.30.0.log.txt
> 
> 
> It looks like the system is running out of swap as I get this in 
> /var/log/messages:
> 
> Oct 30 05:15:31 xindi kernel: pid 68935 (rustc), uid 65534, was killed: 
> out of swap space

Unfortunately, the wording of this message is a misnomer for what
drives the kills: it is actually driven by being unable to gain more
free memory but FreeBSD will not swap-out processes that stay runnable
(or are running), only ones that are waiting. Even a single process
that stays runnable and keeps lots of RAM in the active category can
lead to kills when swap is unused or little used. So the kill-behavior
is very workload dependent.

Real "out of swap" conditions tend to also have messages
similar to:

Aug  5 17:54:01 sentinel kernel: swap_pager_getswapspace(32): failed

If you are not seeing such messages, then it is likely that
the mount of swap space still free is not the actual thing
driving the kills.

(The system simply leaves the dirty pages in memory when a
swap_pager_getswapspace failed message is produced. Of itself,
it does not cause a kill.)


Other questions:

Are you getting any I/O error reports for the device used for
swapping and paging?

Are you seeing any reports of: swap_pager: indefinite wait buffer ?

Poor I/O performance for paging and/or swapping can contribute
to the kills happening. But I've no clue if such is an issue
for your context.


> The build host had 6GB og RAM and 14GB of swap. I think that ought to be 
> enough for building mostly anything.

Again, without extra evidence, do not beleive the "out of swap space"
part of "killed: out of swap space".

> Has anyone else observed this behaviour?

Attempting -j4 buildworld on 1 GiBYte single-board-computers for
environments that build clang/llvm have lots of problems with this
sort of kill with plenty of swap space. There was a whole, long
exchange on the arm list during the discovery of the misnomer
status.

But it turns out there is a tunable setting to control how many
tries at freeing memory before kills happen: so how long before
the kills will start.

The default vm.pageout_oom_seq=12 can be increased
to increase how long a low-free-RAM condition is tolerated.
I assign vm.pageout_oom_seq in /etc/sysctl.conf --but that may
not be the best for your context.

vm.pageout_oom_seq=120 has proved useful. In some extreme
situations (buildworld buildkernel in a low RAM, slow
context, including long I/O latencies) vm.pageout_oom_seq=1024
or more has been used to avoid kills when there was plenty
of swap space.

So you may want to try assigning vm.pageout_oom_seq .


Side note:

Quoting Trev's reply (and the original question)
from a list exchange:

QUOTE
What does the error swap_pager: indefinite wait buffer: mean?

This means that a process is trying to page memory to disk, and the page 
attempt has hung trying to access the disk for more than 20 seconds. It might 
be caused by bad blocks on the disk drive, disk wiring, cables, or any other 
disk I/O-related hardware. If the drive itself is bad, disk errors will appear 
in /var/log/messages and in the output of dmesg. Otherwise, check the cables 
and connections.
ENDQUOTE

It is possible for a some systems to queue up more than the I/O
system can process in 20 seconds, even when the I/O is working
well (but is relatively slow compared to the work load).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Port collection (incorrectly) marked as not supporting 11.1

[Mark Millard via freebsd-ports]

On 2018-Oct-1, at 8:22 AM, Aryeh Friedman  wrote:

> On:
> 
> FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28
> 23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> Attempting to run make on any port produces:
> 
> /!\ ERROR: /!\
> 
> Ports Collection support for your FreeBSD version has ended, and no ports
> are
> guaranteed to build on this system. Please upgrade to a supported release.
> 
> No support will be provided if you silence this message by defining
> 
> How is this possibly correct when 11.1 is still listed as a production
> release!?!?!?!?

https://www.freebsd.org/security/index.html#sup says otherwise.
Note the "September 30, 2018" below for 11.1 (copied from that
page's content). (I'm unsure if alignment will be preserved.)

Branch Release  Type Release DateExpected EoL
stable/10   n/a  n/a n/a October 31, 2018
releng/10.4 10.4-RELEASE Normal  October 3, 2017 October 31, 2018
stable/11   n/a  n/a n/a September 30, 2021
releng/11.1 11.1-RELEASE n/a July 26, 2017   September 30, 2018
releng/11.2 11.2-RELEASE n/a June 28, 2018   11.3-RELEASE + 3 months

Near the time of such transitions, some references may not have
been updated yet.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FYI: security/nss (as of -r480180) fails to build on powerpc64: error: incompatible pointer types passing 'int *' to parameter of type 'size_t *'

[Mark Millard via freebsd-ports]

The following is on a powerpc64 machine (old PowerMac G5 so-called
"Quad Core") running a personal build of head -r339076 that was
built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1).
The compiler is system-clang (so clang 6 as cc). [I experiment
with more modern compilers and toolchains for some powerpc family
members.]

-r339076 predates the openssl update in head.

The port build is via ports-mgmt/poudriere-devel .

Note: size_t is unsigned long (64 bits) while int is
32 bits for powerpc64.

I've no clue if this is supposed to work, be blocked as
broken, or what. (I've been without access to the powerpc
machines for some time and it is even longer since I'd
built updated ports. So this might be a long-standing
issue without my knowing it.)

For now this is just an FYI.

=>> Building security/nss
build started at Wed Oct 10 18:50:10 PDT 2018
port directory: /usr/ports/security/nss
package name: nss-3.39
building for: FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 powerpc
maintained by: ge...@freebsd.org
Makefile ident:  $FreeBSD: head/security/nss/Makefile 478586 2018-08-31 
14:44:13Z jbeich $
Poudriere version: 3.2.99.20180511
Host OSVERSION: 1200084
Jail OSVERSION: 1200084
Job Id: 04
. . .
gmake[3]: Entering directory 
'/wrkdirs/usr/ports/security/nss/work/nss-3.39/nss/lib/freebl'
. . .
mpi/mpcpucache.c:728:23: error: incompatible pointer types passing 'int *' to 
parameter of type 'size_t *' (aka 'unsigned long *') 
[-Werror,-Wincompatible-pointer-types]
_size, , NULL, 0) < 0 || !cacheline_size)
 ^
/usr/include/sys/sysctl.h:1062:48: note: passing argument to parameter here
int sysctl(const int *, u_int, void *, size_t *, const void *, size_t);
   ^
1 error generated.
gmake[4]: *** [../../coreconf/rules.mk:393: 
FreeBSD12.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/mpcpucache.o] Error 1
gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/security/nss/work/nss-3.39/nss/lib/freebl'
gmake[3]: *** [Makefile:629: libs] Error 2
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/security/nss/work/nss-3.39/nss/lib/freebl'
gmake[2]: *** [../coreconf/rules.mk:101: libs] Error 2
gmake[2]: Leaving directory 
'/wrkdirs/usr/ports/security/nss/work/nss-3.39/nss/lib'
gmake[1]: *** [coreconf/rules.mk:101: libs] Error 2
gmake[1]: Leaving directory '/wrkdirs/usr/ports/security/nss/work/nss-3.39/nss'
*** Error code 1

Stop.
make: stopped in /usr/ports/security/nss
=>> Cleaning up wrkdir
===>  Cleaning for nss-3.39
build of security/nss | nss-3.39 ended at Wed Oct 10 18:55:35 PDT 2018
build time: 00:05:25
!!! build failure encountered !!!


For reference:

[04:59:20] [04] [00:05:16] Saved security/nss | nss-3.39 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDpowerpc64-default/default/nss-3.39.tbz
[04:59:29] [04] [00:05:25] Finished security/nss | nss-3.39: Failed: build
[04:59:30] [04] [00:05:26] Skipping x11/lumina | lumina-1.4.1,3: Dependent port 
security/nss | nss-3.39 failed
[04:59:30] [04] [00:05:26] Skipping deskutils/lumina-pdf | lumina-pdf-1.4.1: 
Dependent port security/nss | nss-3.39 failed
[04:59:30] [04] [00:05:26] Skipping graphics/poppler | poppler-0.57.0_1: 
Dependent port security/nss | nss-3.39 failed
[04:59:30] [04] [00:05:26] Skipping graphics/poppler-qt5 | 
poppler-qt5-0.57.0_1: Dependent port security/nss | nss-3.39 failed


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: error: undefined symbol: OPENSSL_cpuid_setup

[Mark Millard via freebsd-ports]

Lorenzo Salvadore phascolarctos at protonmail.ch wrote on
Wed Sep 26 17:01:01 UTC 2018 :

> > On Wed, Sep 26, 2018 at 09:53:32AM +, Lorenzo Salvadore via 
> > freebsd-ports wrote:
> >
> > > > > While playing with compiling www/chromium, I'm seeing make stop with
> > > > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup
> > > > > This is on a Raspberry Pi 3 running
> > > > > FreeBSD www.zefox.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338880 GENERIC
> > > > > with ports at
> > > > > 480613
> > > > > World and kernel build, install and run acceptably, so the system as
> > > > > a whole isn't hugely broken. Can anybody suggest a fix/workaround?
> > > >
> > > > Changed the make command to
> > > > make -DBATCH DISABLE_VULNERABILITIES=yes DEFAULT_VERSIONS+=ssl=base > 
> > > > make.log
> > > > but make stopped with the same error:
> > > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup
> > > >
> > > > > > > referenced by crypto.c
> > > > > > > crypto.o:(do_library_init) in archive 
> > > > > > > obj/third_party/boringssl/libboringssl.a
> > > >
> > > > c++: error: linker command failed with exit code 1 (use -v to see 
> > > > invocation)
> > > > It's not clear to me if this is an issue with the port, or the base 
> > > > system.
> > > > Any advice appreciated!
> > >
> > > I might be wrong, but I see some similiraties with an issue discussed in 
> > > those days
> > > under the subject "error: undefined symbol: main in poudriere jail". It 
> > > was a
> > > linking problem that appeared only on 12.0-ALPHA7 (or current any anyway, 
> > > not on
> > > 11.2-RELEASE). I suggest you take a look into it.
> > > Here are the links to the most relevant messages (from the week archive, 
> > > so they
> > > will not work anymore after the week pass and then you will have to 
> > > search them
> > > in an other archive):
> > > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=87161+0+current/freebsd-ports
> > > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=108259+0+current/freebsd-ports
> >
> > My situation is much simpler than the one described, there's no jail, just
> > a plain "make" in /usr/ports/www/chromium. Hopefully it'll be less complex!
> 
> The jail was not relevant for that problem: the point was that the new 
> default linker
> for 12.0-ALPHA7 made disappear the symbol main() and my guess is that it also 
> makes
> disappear the symbol OPENSSL_cpuid_setup in your case.
> 
> If that was the case making the suggested symlink may solve your problem:
> ln -sf ld.bfd /usr/bin/ld
> 
> As I do not have a 12.0-ALPHA7 installed, I can not tell you where is ld.bfd, 
> but I am sure
> you will not have problem to find it.
> 
> On this topic, you might also like to take a look at this:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864

In particular there is Comment 168 from Jan Beich:

QUOTE
I'm puzzled why my port started to fail only recently. Not to mention, 
audio/openal-soft builds fine with LLD >= 7. Maybe merge clang700 *before* 
/stable/12 branches to avoid facepalm for a whole year until EOL.

http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fbeefy12.nyi.freebsd.org%2Fdata%2Flatest-per-pkg%2Frpcs3%2F0.0.5.892%2Fhead-amd64-default.log
http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fbeefy12.nyi.freebsd.org%2Fdata%2Flatest-per-pkg%2Frpcs3%2F0.0.5.912%2Fhead-amd64-default.log
END QUOTE

Although that last link (the failure example) shows getting:

/usr/bin/ld: error: cannot preempt symbol: . . .

errors. Still, it seems to be another example of
recently changed linking behavior if I read
correctly.

I think that makes 3 new link failures for 3 different people
for 3 distinct contexts that are referenced in the above
material: the "cannot preempt symbol" one, the "main" one,
and the "OPENSSL_cpuid_setup" one.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

On 2018-Nov-16, at 12:58, Jan Beich  wrote:

> Mark Millard  writes:
> 
>> Jan Beich jbeich at FreeBSD.org wrote on
>> Fri Nov 16 02:15:57 UTC 2018 :
>> 
>>> Mark Millard via freebsd-x11  writes:
>>> 
 [Added: The original cross-build via poudriere-devel and qemu-user-static
 did not get this problem. I give details later. Sumamry: Looks like -O2
 was used for the cross build and -O was used for armv7 native. The
 difference is likely(?) from my materials but not supporting both ways of
 building is likely a problem with the port(?).]
>>> 
>>> x11/pixman builds fine on armv7 even with -O. Tested both Clang/LLD 6.0
>>> and 7.0 after forcing MACHINE_CPUARCH=arm on command line.
> [...]
>> Do you have a log that would show the commands that were used to produce
>> the things that were listed in my original report for the "R_ARM_V4BX
>> against local in readonly segment":
> 
> Build logs:
> - clang/lld 6.0: https://ptpb.pw/5dip (via devel/llvm60)
> - clang/lld 7.0: https://ptpb.pw/wwi9 (via native-xtools)
> - -mcpu=cortex-a7: https://ptpb.pw/_zAP


Thanks.

You tried a cross-build via QEMU_EMULATING=1 with
CC=clang60 and links using  -fuse-ld=/usr/local/bin/ld.lld60
and -O instead of -O2 . Looks like /nxb-bin/. . . was
not involved. No -mcpu in use.

Using pixman-arm-simd-asm-scaled as an example: I do not see
other differences in the command used to produce
.libs/pixman-arm-simd-asm-scaled.o .

That still leave system clang/llvm vs. devel/llvm60 patch levels
or configuration vs. system clang/llvm and such as possibilities
for variations.

clang/llvm 7 material are definitely more recent than anything
that I've used. Again I do not see any other differences in
command used to produce .libs/pixman-arm-simd-asm-scaled.o .

And nothing when -mcpu=cortex-a7 is in your test either.

So far all tests via amd64->armv7 cross-builds do not report
the problem, yours and mine.

Only a native build on armv7 has generated the messages. So far
I'm the only one that has tried that sort of context in this
investigation as far as I know.

We do have https://bugs.llvm.org/show_bug.cgi?id=38303 as a
report from a linux context for cross-building to Android,
specifically for a pixman example for the same problem.
So, whatever the issue is, it is not strictly local to my
context.

But the question is probably more "why was R_ARM_V4BX
relocation record generated at all?" than the messages
produced when the relocation records are discovered by
lld.

Does the llvm60 and llvm70 configuration deal with older
arm's that do not have bx instructions? Might the system
clang/llvm have enabled supporting such so that it
outputs the V_ARM_V4BX relocation records? (Just pondering.)
If yes: This seems to imply lld is then to be avoided,
at least when there may be bx lr code (and so the V_ARM_V4BX
use).

My native armv7 configuration's system clang/llvm was in use and
is still at:

# cc -v
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
6.0.1)
Target: armv7-unknown-freebsd13.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin

# ld -v
LLD 6.0.1 (FreeBSD 335540-130) (compatible with GNU linkers)

But the cross-build /nxb-bin/. . . was also based on the
building the same sources. The whole buildworlds were
based on the same sources.

I'm still no closer to correctly identifying what makes the
difference for my native build vs. cross building. So far
the effort has just eliminated various ideas for
possibilities.

(It also lead to the poudriere/nxb-bin/ discovery of the
-O2 vs. -O sys.mk code not picking the intended -O for arm*,
including armv6 and armv7.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

[I add some objdump output from what was in the .tar archive for
the failure in the poudriere build (the 3 specific .o's). Also I
show tool version information.]

On 2018-Nov-16, at 11:39, Mark Millard  wrote:

> Jan Beich jbeich at FreeBSD.org wrote on
> Fri Nov 16 02:15:57 UTC 2018 :
> 
>> Mark Millard via freebsd-x11  writes:
>> 
>>> [Added: The original cross-build via poudriere-devel and qemu-user-static
>>> did not get this problem. I give details later. Sumamry: Looks like -O2
>>> was used for the cross build and -O was used for armv7 native. The
>>> difference is likely(?) from my materials but not supporting both ways of
>>> building is likely a problem with the port(?).]
>> 
>> x11/pixman builds fine on armv7 even with -O. Tested both Clang/LLD 6.0
>> and 7.0 after forcing MACHINE_CPUARCH=arm on command line.
> 
> Interesting. My context was a poudriere build that was rebuilding all
> my normal ports for the armv7 context (414 total). (poudriere is still
> running, still having 12 to go, including llvm60, llvm70, and gcc8.)
> This was/is under:
> 
> # uname -apKU
> FreeBSD OPiP2E 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r340287M: Sat Nov 10 
> 22:40:25 PST 2018 
> markmi@FBSDFSSD:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENERIC-NODBG
>   arm armv7 133 133
> 
> and is tied to my jump from before openssl was updated( -r339076 ) to
> after.
> 
> It was using system clang and lld, not devel/llvm* .
> 
> The only other thing to have failed so far is multimedia/libpvx but it
> failed built both ways ( native and cross-build with /nxb-bin/. . . ).
> 
> Do you have a log that would show the commands that were used to produce
> the things that were listed in my original report for the "R_ARM_V4BX
> against local in readonly segment":
> 
> pixman-arm-simd-asm-scaled.o
> pixman-arm-neon-asm.o
> pixman-arm-neon-asm-bilinear.o
> 
> --- libpixman-1.la --- (for where the use of the .o's was attempted via a 
> library)
> 
> ? If yes we might be able to compare for differences to explain the
> variation. I do have the logs from the poudriere build attempts
> in both contexts ( native and cross-build with /nxb-bin/. . . ).
> 
> It might be possible that my -mcpu use mixed with -O is part of
> what is required to have the problem. (Only difference?)
> 
> It looks to be a long time (days) before the armv7 poudriere run
> will complete. So testing alternatives in that environment is
> delayed. For now comparing commands in log files is all I've got
> to work with initially (if we can). Next would be to look at the
> .S files.
> 
> 
> My failing-context's commands:
> (The 3 sources are .S files. The -o .libs/*.o commands do list -fPIC and -DPIC
> but I'm not sure how those would apply to .S files.)
> 
> --- pixman-arm-simd-asm-scaled.lo ---
> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
> -mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
> pixman-arm-simd-asm-scaled.lo -MD -MP -MF 
> .deps/pixman-arm-simd-asm-scaled.Tpo -c pixman-arm-simd-asm-scaled.S  -fPIC 
> -DPIC -o .libs/pixman-arm-simd-asm-scaled.o
> 
> --- pixman-arm-simd-asm-scaled.lo ---
> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
> -mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
> pixman-arm-simd-asm-scaled.lo -MD -MP -MF 
> .deps/pixman-arm-simd-asm-scaled.Tpo -c pixman-arm-simd-asm-scaled.S -o 
> pixman-arm-simd-asm-scaled.o >/dev/null 2>&1
> 
> --- libpixman-arm-simd.la ---
> libtool: link: ar cru .libs/libpixman-arm-simd.a .libs/pixman-arm-simd.o 
> .libs/pixman-arm-simd-asm.o .libs/pixman-arm-simd-asm-scaled.o 
> libtool: link: ranlib .libs/libpixman-arm-simd.a
> libtool: link: ( cd ".libs" && rm -f "libpixman-arm-simd.la" && ln -s 
> "../libpixman-arm-simd.la" "libpixman-arm-simd.la" )
> 
> --- pixman-arm-neon-asm.lo ---
> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
> -mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
> pixman-arm-neon-asm.lo -MD -MP -MF .deps/pixman-arm-neon-asm.Tpo -c 
> pixman-arm-neon-asm.S  -fPIC -DPIC -o .libs/pixman-arm-neon-asm.o
> 
> --- pixman-arm-neon-asm.lo ---
> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
> -mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
> pixman-arm-neon-asm.lo -MD -MP -MF .deps/pixman-arm-neon-asm.Tpo -c 
> pixman-arm-neon-asm.S -o pixman-arm-neon-asm.o >/dev/null 2>&1
> 
> --- libpixman-arm-neon.la ---
> /bin/sh ../libtool  --tag=CC--mode=link cc  -O -pipe -mcpu=cortex-a7  -g 
> -fno-strict-aliasing  -Wall -Wdeclaration-after-statement 
> -Wno-unused-local-typedefs -fno-strict-aliasing -fvisibility=hidden-o 
> libpixman-arm-neon.la  pixman-arm-neon.lo pixman-arm-neon-asm.lo  
> pixman-arm-neon-asm-bilinear.lo  -lm
> libtool: link: ar cru .libs/libpixman-arm-neon.a .libs/pixman-arm-neon.o 
> .libs/pixman-arm-neon-asm.o .libs/pixman-arm-neon-asm-bilinear.o 
> libtool: link: ranlib .libs/libpixman-arm-neon.a

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

Top post of llvm's lld status:

Turns out various vintages of lld do not support R_ARM_V4BX *ABS* :

https://bugs.llvm.org/show_bug.cgi?id=38303

Its shown example is one of the ones that I reported (pixman) but for
building FireFox for Android (Linux context, not FreeBSD):

QUOTE
builds/worker/workspace/build/src/clang/bin/ld.lld: error: can't create dynamic 
relocation R_ARM_V4BX against local symbol in readonly segment; recompile 
object files with -fPIC

>>> defined in ../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o
>>> referenced by 
>>> ../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o:(.text+0x4F0)
END QOUTE

It also points out that:

QUOTE
Linking with -z notext is more explicit:

/builds/worker/workspace/build/src/clang/bin/ld.lld: error: 
../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o:(.text+0x4F0): 
unrecognized reloc 40
END QUOTE


On 2018-Nov-16, at 12:34, Mark Millard  wrote:

> [I add some objdump output from what was in the .tar archive for
> the failure in the poudriere build (the 3 specific .o's). Also I
> show tool version information.]
> 
> On 2018-Nov-16, at 11:39, Mark Millard  wrote:
> 
>> Jan Beich jbeich at FreeBSD.org wrote on
>> Fri Nov 16 02:15:57 UTC 2018 :
>> 
>>> Mark Millard via freebsd-x11  writes:
>>> 
 [Added: The original cross-build via poudriere-devel and qemu-user-static
 did not get this problem. I give details later. Sumamry: Looks like -O2
 was used for the cross build and -O was used for armv7 native. The
 difference is likely(?) from my materials but not supporting both ways of
 building is likely a problem with the port(?).]
>>> 
>>> x11/pixman builds fine on armv7 even with -O. Tested both Clang/LLD 6.0
>>> and 7.0 after forcing MACHINE_CPUARCH=arm on command line.
>> 
>> Interesting. My context was a poudriere build that was rebuilding all
>> my normal ports for the armv7 context (414 total). (poudriere is still
>> running, still having 12 to go, including llvm60, llvm70, and gcc8.)
>> This was/is under:
>> 
>> # uname -apKU
>> FreeBSD OPiP2E 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r340287M: Sat Nov 10 
>> 22:40:25 PST 2018 
>> markmi@FBSDFSSD:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENERIC-NODBG
>>   arm armv7 133 133
>> 
>> and is tied to my jump from before openssl was updated( -r339076 ) to
>> after.
>> 
>> It was using system clang and lld, not devel/llvm* .
>> 
>> The only other thing to have failed so far is multimedia/libpvx but it
>> failed built both ways ( native and cross-build with /nxb-bin/. . . ).
>> 
>> Do you have a log that would show the commands that were used to produce
>> the things that were listed in my original report for the "R_ARM_V4BX
>> against local in readonly segment":
>> 
>> pixman-arm-simd-asm-scaled.o
>> pixman-arm-neon-asm.o
>> pixman-arm-neon-asm-bilinear.o
>> 
>> --- libpixman-1.la --- (for where the use of the .o's was attempted via a 
>> library)
>> 
>> ? If yes we might be able to compare for differences to explain the
>> variation. I do have the logs from the poudriere build attempts
>> in both contexts ( native and cross-build with /nxb-bin/. . . ).
>> 
>> It might be possible that my -mcpu use mixed with -O is part of
>> what is required to have the problem. (Only difference?)
>> 
>> It looks to be a long time (days) before the armv7 poudriere run
>> will complete. So testing alternatives in that environment is
>> delayed. For now comparing commands in log files is all I've got
>> to work with initially (if we can). Next would be to look at the
>> .S files.
>> 
>> 
>> My failing-context's commands:
>> (The 3 sources are .S files. The -o .libs/*.o commands do list -fPIC and 
>> -DPIC
>> but I'm not sure how those would apply to .S files.)
>> 
>> --- pixman-arm-simd-asm-scaled.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
>> -mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
>> pixman-arm-simd-asm-scaled.lo -MD -MP -MF 
>> .deps/pixman-arm-simd-asm-scaled.Tpo -c pixman-arm-simd-asm-scaled.S  -fPIC 
>> -DPIC -o .libs/pixman-arm-simd-asm-scaled.o
>> 
>> --- pixman-arm-simd-asm-scaled.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
>> -mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
>> pixman-arm-simd-asm-scaled.lo -MD -MP -MF 
>> .deps/pixman-arm-simd-asm-scaled.Tpo -c pixman-arm-simd-asm-scaled.S -o 
>> pixman-arm-simd-asm-scaled.o >/dev/null 2>&1
>> 
>> --- libpixman-arm-simd.la ---
>> libtool: link: ar cru .libs/libpixman-arm-simd.a .libs/pixman-arm-simd.o 
>> .libs/pixman-arm-simd-asm.o .libs/pixman-arm-simd-asm-scaled.o 
>> libtool: link: ranlib .libs/libpixman-arm-simd.a
>> libtool: link: ( cd ".libs" && rm -f "libpixman-arm-simd.la" && ln -s 
>> "../libpixman-arm-simd.la" "libpixman-arm-simd.la" )
>> 
>> --- pixman-arm-neon-asm.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
>> -mcpu=cortex-a7 -g 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

Jan Beich jbeich at FreeBSD.org wrote on
Fri Nov 16 02:15:57 UTC 2018 :

> Mark Millard via freebsd-x11  writes:
> 
> > [Added: The original cross-build via poudriere-devel and qemu-user-static
> > did not get this problem. I give details later. Sumamry: Looks like -O2
> > was used for the cross build and -O was used for armv7 native. The
> > difference is likely(?) from my materials but not supporting both ways of
> > building is likely a problem with the port(?).]
> 
> x11/pixman builds fine on armv7 even with -O. Tested both Clang/LLD 6.0
> and 7.0 after forcing MACHINE_CPUARCH=arm on command line.

Interesting. My context was a poudriere build that was rebuilding all
my normal ports for the armv7 context (414 total). (poudriere is still
running, still having 12 to go, including llvm60, llvm70, and gcc8.)
This was/is under:

# uname -apKU
FreeBSD OPiP2E 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r340287M: Sat Nov 10 
22:40:25 PST 2018 
markmi@FBSDFSSD:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENERIC-NODBG
  arm armv7 133 133

and is tied to my jump from before openssl was updated( -r339076 ) to
after.

It was using system clang and lld, not devel/llvm* .

The only other thing to have failed so far is multimedia/libpvx but it
failed built both ways ( native and cross-build with /nxb-bin/. . . ).

Do you have a log that would show the commands that were used to produce
the things that were listed in my original report for the "R_ARM_V4BX
against local in readonly segment":

pixman-arm-simd-asm-scaled.o
pixman-arm-neon-asm.o
pixman-arm-neon-asm-bilinear.o

--- libpixman-1.la --- (for where the use of the .o's was attempted via a 
library)

? If yes we might be able to compare for differences to explain the
variation. I do have the logs from the poudriere build attempts
in both contexts ( native and cross-build with /nxb-bin/. . . ).

It might be possible that my -mcpu use mixed with -O is part of
what is required to have the problem. (Only difference?)

It looks to be a long time (days) before the armv7 poudriere run
will complete. So testing alternatives in that environment is
delayed. For now comparing commands in log files is all I've got
to work with initially (if we can). Next would be to look at the
.S files.


My failing-context's commands:
(The 3 sources are .S files. The -o .libs/*.o commands do list -fPIC and -DPIC
but I'm not sure how those would apply to .S files.)

--- pixman-arm-simd-asm-scaled.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
-mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
pixman-arm-simd-asm-scaled.lo -MD -MP -MF .deps/pixman-arm-simd-asm-scaled.Tpo 
-c pixman-arm-simd-asm-scaled.S  -fPIC -DPIC -o 
.libs/pixman-arm-simd-asm-scaled.o

--- pixman-arm-simd-asm-scaled.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
-mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
pixman-arm-simd-asm-scaled.lo -MD -MP -MF .deps/pixman-arm-simd-asm-scaled.Tpo 
-c pixman-arm-simd-asm-scaled.S -o pixman-arm-simd-asm-scaled.o >/dev/null 2>&1

--- libpixman-arm-simd.la ---
libtool: link: ar cru .libs/libpixman-arm-simd.a .libs/pixman-arm-simd.o 
.libs/pixman-arm-simd-asm.o .libs/pixman-arm-simd-asm-scaled.o 
libtool: link: ranlib .libs/libpixman-arm-simd.a
libtool: link: ( cd ".libs" && rm -f "libpixman-arm-simd.la" && ln -s 
"../libpixman-arm-simd.la" "libpixman-arm-simd.la" )

--- pixman-arm-neon-asm.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
-mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
pixman-arm-neon-asm.lo -MD -MP -MF .deps/pixman-arm-neon-asm.Tpo -c 
pixman-arm-neon-asm.S  -fPIC -DPIC -o .libs/pixman-arm-neon-asm.o

--- pixman-arm-neon-asm.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
-mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
pixman-arm-neon-asm.lo -MD -MP -MF .deps/pixman-arm-neon-asm.Tpo -c 
pixman-arm-neon-asm.S -o pixman-arm-neon-asm.o >/dev/null 2>&1

--- libpixman-arm-neon.la ---
/bin/sh ../libtool  --tag=CC--mode=link cc  -O -pipe -mcpu=cortex-a7  -g 
-fno-strict-aliasing  -Wall -Wdeclaration-after-statement 
-Wno-unused-local-typedefs -fno-strict-aliasing -fvisibility=hidden-o 
libpixman-arm-neon.la  pixman-arm-neon.lo pixman-arm-neon-asm.lo  
pixman-arm-neon-asm-bilinear.lo  -lm
libtool: link: ar cru .libs/libpixman-arm-neon.a .libs/pixman-arm-neon.o 
.libs/pixman-arm-neon-asm.o .libs/pixman-arm-neon-asm-bilinear.o 
libtool: link: ranlib .libs/libpixman-arm-neon.a
libtool: link: ( cd ".libs" && rm -f "libpixman-arm-neon.la" && ln -s 
"../libpixman-arm-neon.la" "libpixman-arm-neon.la" )


--- pixman-arm-neon-asm-bilinear.lo ---
. . .

libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -mcpu=cortex-a7 -O -pipe 
-mcpu=cortex-a7 -g -fno-strict-aliasing -no-integrated-as -MT 
pixman-arm-neon-asm-bilinear.lo -MD -MP -MF 
.deps/pixman-arm-neon-asm-bilinear.Tpo -c 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

[History omitted. This should stand on its own well.]

I finally figured out parts of the issue, I think.
At least how the V_ARM_V4BX use is getting there
despite lld's status for handling it . . .

On armv7:

# more test_bx_lr.S
.text
.arch armv6
.object_arch armv4
.arm
.altmacro
.p2align 2
.func fname
.global fname
.hidden fname
.type fname, %function
fname:
bx  lr

(I got those lines from the failing port's .S files,
including includes. Note the .object_arch armv4 use
and the forced armv6, not armv7.)

# clang -target armv7-unknown-freebsd13.0-gnueabihf -O -pipe -no-integrated-as  
-MT test_bx_lr.lo -MD -MP -MF test_bx_lr.Tpo -c test_bx_lr.S -fPIC -DPIC -o 
test_bx_lr.o

(The -target is not necessary. I just choose to be explicit.)

# objdump -x test_bx_lr.o | more

test_bx_lr.o: file format elf32-littlearm
test_bx_lr.o
architecture: armv4, flags 0x0011:
HAS_RELOC, HAS_SYMS
start address 0x
private flags = 500: [Version5 EABI]

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0004      0034  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data       0038  2**0
  CONTENTS, ALLOC, LOAD, DATA
  2 .bss        0038  2**0
  ALLOC
  3 .ARM.attributes 001b      0038  2**0
  CONTENTS, READONLY
SYMBOL TABLE:
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .ARM.attributes .ARM.attributes
 g F .text   .hidden fname


RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE 
 R_ARM_V4BX*ABS*


truss for that cc command reports looking in many
places for as, finally finding /usr/local/bin/as :

access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
such file or directory'
access("/usr/bin/as",X_OK|R_OK)  ERR#2 'No such file or 
directory'

(Note: based on WITHOUT_BINUTILS= for buildworld the above would normally
not be found. But for WITH_BINUTILS= the host as would be found.)

access("/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No such 
file or directory'
access("/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No such 
file or directory'
access("/usr/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
such file or directory'
access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
such file or directory'
access("/usr/local/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) 
ERR#2 'No such file or directory'
access("/usr/local/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 
'No such file or directory'
access("/usr/home/markmi/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) 
ERR#2 'No such file or directory'
access("/sbin/as",X_OK|R_OK) ERR#2 'No such file or 
directory'
access("/bin/as",X_OK|R_OK)  ERR#2 'No such file or 
directory'
access("/usr/sbin/as",X_OK|R_OK) ERR#2 'No such file or 
directory'
access("/usr/bin/as",X_OK|R_OK)  ERR#2 'No such file or 
directory'
access("/usr/local/sbin/as",X_OK|R_OK)   ERR#2 'No such file or 
directory'
access("/usr/local/bin/as",X_OK|R_OK)= 0 (0x0)

(Note the /usr/home/markmi/bin/armv7-unknown-freebsd13.0-gnueabihf-as attempt
before the one actually found and used. I would not have guessed the
need to worry about such a place.)

Then follows:

fstatat(AT_FDCWD,"/usr/local/bin/as",{ mode=-r-xr-xr-x 
,inode=80287,size=21817416,blksize=32768 },0x0) = 0 (0x0)
__sysctl(0xbfbfe020,0x2,0xbfbfe018,0xbfbfe01c,0xe,0x236c9140) = 0 (0x0)
access("/usr/bin/clang",F_OK)= 0 (0x0)
vfork()  = 61461 (0xf015)
wait4(61461,{ EXITED,val=0 },0x0,0x0)= 61461 (0xf015)
access("/usr/local/bin/as",F_OK) = 0 (0x0)
vfork()  = 61462 (0xf016)
wait4(61462,{ EXITED,val=0 },0x0,0x0)= 61462 (0xf016)
access("/tmp/test_bx_lr-0c7bf8.s",W_OK)  = 0 (0x0)
fstatat(AT_FDCWD,"/tmp/test_bx_lr-0c7bf8.s",{ mode=-rw-r--r-- 
,inode=802647,size=210,blksize=32768 },0x0) = 0 (0x0)
fstatat(AT_FDCWD,"/tmp/test_bx_lr-0c7bf8.s",{ mode=-rw-r--r-- 
,inode=802647,size=210,blksize=32768 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
fstatat(AT_FDCWD,"/tmp/test_bx_lr-0c7bf8.s",{ mode=-rw-r--r-- 
,inode=802647,size=210,blksize=32768 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
unlink("/tmp/test_bx_lr-0c7bf8.s")   = 0 (0x0)

llvm/clang is not providing the assembler used for -no-integrated-as .
This would appear to imply that a system without ports or other such
can not use -no-integrated-as 

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

On 2018-Nov-16, at 18:15, Mark Millard  wrote:

> 
> I finally figured out parts of the issue, I think.
> At least how the V_ARM_V4BX use is getting there
> despite lld's status for handling it . . .
> 
> On armv7:
> 
> # more test_bx_lr.S
>.text
>.arch armv6
>.object_arch armv4
>.arm
>.altmacro
>.p2align 2
>.func fname
>.global fname
>.hidden fname
>.type fname, %function
>fname:
>bx  lr
> 
> (I got those lines from the failing port's .S files,
> including includes. Note the .object_arch armv4 use
> and the forced armv6, not armv7.)

For reference relative to the use of .object_arch armv4 :

# grep -r object_arch /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/ 
| more
/wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-neon-asm.S:  
  .object_arch armv4
/wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-simd-asm-scaled.S:
   .object_arch armv4
/wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-neon-asm-bilinear.S:.object_arch
 armv4
/wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-simd-asm.S:  
.object_arch armv4

Without .object_arch armv4 the assembler involved does not output
the V_ARM_V4BX *ABS* relocation records (adjusted the small example):

# objdump -x test_bx_lr.o | more

test_bx_lr.o: file format elf32-littlearm
test_bx_lr.o
architecture: arm, flags 0x0010:
HAS_SYMS
start address 0x
private flags = 500: [Version5 EABI]

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0004      0034  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data       0038  2**0
  CONTENTS, ALLOC, LOAD, DATA
  2 .bss        0038  2**0
  ALLOC
  3 .ARM.attributes 001b      0038  2**0
  CONTENTS, READONLY
SYMBOL TABLE:
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .ARM.attributes .ARM.attributes
 g F .text   .hidden fname



> # clang -target armv7-unknown-freebsd13.0-gnueabihf -O -pipe 
> -no-integrated-as  -MT test_bx_lr.lo -MD -MP -MF test_bx_lr.Tpo -c 
> test_bx_lr.S -fPIC -DPIC -o test_bx_lr.o
> 
> (The -target is not necessary. I just choose to be explicit.)
> 
> # objdump -x test_bx_lr.o | more
> 
> test_bx_lr.o: file format elf32-littlearm
> test_bx_lr.o
> architecture: armv4, flags 0x0011:
> HAS_RELOC, HAS_SYMS
> start address 0x
> private flags = 500: [Version5 EABI]
> 
> Sections:
> Idx Name  Size  VMA   LMA   File off  Algn
>  0 .text 0004      0034  2**2
>  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>  1 .data       0038  2**0
>  CONTENTS, ALLOC, LOAD, DATA
>  2 .bss        0038  2**0
>  ALLOC
>  3 .ARM.attributes 001b      0038  2**0
>  CONTENTS, READONLY
> SYMBOL TABLE:
>  ld  .text   .text
>  ld  .data   .data
>  ld  .bss    .bss
>  ld  .ARM.attributes .ARM.attributes
>  g F .text   .hidden fname
> 
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE  VALUE 
>  R_ARM_V4BX*ABS*
> 
> 
> truss for that cc command reports looking in many
> places for as, finally finding /usr/local/bin/as :
> 
> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
> such file or directory'
> access("/usr/bin/as",X_OK|R_OK)ERR#2 'No such file or 
> directory'
> 
> (Note: based on WITHOUT_BINUTILS= for buildworld the above would normally
> not be found. But for WITH_BINUTILS= the host as would be found.)
> 
> access("/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
> such file or directory'
> access("/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
> such file or directory'
> access("/usr/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 
> 'No such file or directory'
> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
> such file or directory'
> access("/usr/local/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) 
> ERR#2 'No such file or directory'
> access("/usr/local/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) 
> ERR#2 'No such file or directory'
> access("/usr/home/markmi/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK)
>  ERR#2 'No such file or directory'
> access("/sbin/as",X_OK|R_OK)   ERR#2 'No such file or 
> directory'
> access("/bin/as",X_OK|R_OK)   

Re: ports head -r487783: on armv7 x11/pixman fails to build: /usr/bin/ld: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPI

[Mark Millard via freebsd-ports]

Such timing: https://reviews.llvm.org/D53444 indicates
commits to lld/trunk/ELF/Arch/ARM.cpp today (2018-Nov-16)
to support R_ARM_V4BX in lld.

(No update text below. The above just did not fit well.)

On 2018-Nov-16, at 18:49, Mark Millard  wrote:


> On 2018-Nov-16, at 18:15, Mark Millard  wrote:
> 
>> 
>> I finally figured out parts of the issue, I think.
>> At least how the V_ARM_V4BX use is getting there
>> despite lld's status for handling it . . .
>> 
>> On armv7:
>> 
>> # more test_bx_lr.S
>>   .text
>>   .arch armv6
>>   .object_arch armv4
>>   .arm
>>   .altmacro
>>   .p2align 2
>>   .func fname
>>   .global fname
>>   .hidden fname
>>   .type fname, %function
>>   fname:
>>   bx  lr
>> 
>> (I got those lines from the failing port's .S files,
>> including includes. Note the .object_arch armv4 use
>> and the forced armv6, not armv7.)
> 
> For reference relative to the use of .object_arch armv4 :
> 
> # grep -r object_arch 
> /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/ | more
> /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-neon-asm.S:
> .object_arch armv4
> /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-simd-asm-scaled.S:
>.object_arch armv4
> /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-neon-asm-bilinear.S:.object_arch
>  armv4
> /wrkdirs/usr/ports/x11/pixman/work/pixman-0.34.0/pixman/pixman-arm-simd-asm.S:
>   .object_arch armv4
> 
> Without .object_arch armv4 the assembler involved does not output
> the V_ARM_V4BX *ABS* relocation records (adjusted the small example):
> 
> # objdump -x test_bx_lr.o | more
> 
> test_bx_lr.o: file format elf32-littlearm
> test_bx_lr.o
> architecture: arm, flags 0x0010:
> HAS_SYMS
> start address 0x
> private flags = 500: [Version5 EABI]
> 
> Sections:
> Idx Name  Size  VMA   LMA   File off  Algn
>  0 .text 0004      0034  2**2
>  CONTENTS, ALLOC, LOAD, READONLY, CODE
>  1 .data       0038  2**0
>  CONTENTS, ALLOC, LOAD, DATA
>  2 .bss        0038  2**0
>  ALLOC
>  3 .ARM.attributes 001b      0038  2**0
>  CONTENTS, READONLY
> SYMBOL TABLE:
>  ld  .text   .text
>  ld  .data   .data
>  ld  .bss    .bss
>  ld  .ARM.attributes .ARM.attributes
>  g F .text   .hidden fname
> 
> 
> 
>> # clang -target armv7-unknown-freebsd13.0-gnueabihf -O -pipe 
>> -no-integrated-as  -MT test_bx_lr.lo -MD -MP -MF test_bx_lr.Tpo -c 
>> test_bx_lr.S -fPIC -DPIC -o test_bx_lr.o
>> 
>> (The -target is not necessary. I just choose to be explicit.)
>> 
>> # objdump -x test_bx_lr.o | more
>> 
>> test_bx_lr.o: file format elf32-littlearm
>> test_bx_lr.o
>> architecture: armv4, flags 0x0011:
>> HAS_RELOC, HAS_SYMS
>> start address 0x
>> private flags = 500: [Version5 EABI]
>> 
>> Sections:
>> Idx Name  Size  VMA   LMA   File off  Algn
>> 0 .text 0004      0034  2**2
>> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>> 1 .data       0038  2**0
>> CONTENTS, ALLOC, LOAD, DATA
>> 2 .bss        0038  2**0
>> ALLOC
>> 3 .ARM.attributes 001b      0038  2**0
>> CONTENTS, READONLY
>> SYMBOL TABLE:
>>  ld  .text   .text
>>  ld  .data   .data
>>  ld  .bss    .bss
>>  ld  .ARM.attributes .ARM.attributes
>>  g F .text   .hidden fname
>> 
>> 
>> RELOCATION RECORDS FOR [.text]:
>> OFFSET   TYPE  VALUE 
>>  R_ARM_V4BX*ABS*
>> 
>> 
>> truss for that cc command reports looking in many
>> places for as, finally finding /usr/local/bin/as :
>> 
>> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 
>> 'No such file or directory'
>> access("/usr/bin/as",X_OK|R_OK)   ERR#2 'No such file or 
>> directory'
>> 
>> (Note: based on WITHOUT_BINUTILS= for buildworld the above would normally
>> not be found. But for WITH_BINUTILS= the host as would be found.)
>> 
>> access("/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
>> such file or directory'
>> access("/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 'No 
>> such file or directory'
>> access("/usr/sbin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 
>> 'No such file or directory'
>> access("/usr/bin/armv7-unknown-freebsd13.0-gnueabihf-as",X_OK|R_OK) ERR#2 
>> 'No such file or directory'
>> 

Re: ports head -r484652: lang/ruby24 fails to amd64 -> armv7 cross build: qemu: uncaught target signal 11 (2 of them) [armv7 native build worked]

[Mark Millard via freebsd-ports]

Top post about bad comparison:

The comparison to x11/pixman turns out to be
a misnomer. More testing by Jan B. showed that -O2
vs -O was not sufficient to control the behavior
for x11/pixman's builds. pixman's issue traces back
to use of .object_arch armv4 in four .S files and
them causing R_ARM_V4BX relocation record use,
which lld only had support-for checked in to
llvm's truck today (2018-Nov-16).

Despite that, the build environment's use of
-O2 instead of -O is real for
poudriere/qemu-arm-static/nxb/. . . use.

ruby's problem is not tied to R_ARM_V4BX use:
different problem.

(No updated text below. The above did not fit
there well.)

On 2018-Nov-15, at 11:46, Mark Millard  wrote:

> [While the poudriere-devel/qemu-arm-static/nxb-bin/ amd64 -> armv7
> cross build failed, a native armv7 build worked. It turns out the
> difference that matters is likely -O2 use vs -O use. More later
> below.]
> 
> On 2018-Nov-10, at 23:29, Mark Millard  wrote:
> 
>> Poudriere-devel reported:
>> 
>> [00:18:32] [07] [00:02:56] Saved lang/ruby24 | ruby-2.4.5,1 wrkdir to: 
>> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/ruby-2.4.5,1.tbz
>> [00:18:32] [07] [00:02:56] Finished lang/ruby24 | ruby-2.4.5,1: Failed: build
>> 
>> The log showed:
>> 
>> --- miniruby ---
>> linking miniruby
>> --- .rbconfig.time ---
>> --- encdb.h ---
>> generating encdb.h
>> --- .rbconfig.time ---
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> Segmentation fault
>> *** [.rbconfig.time] Error code 139
>> 
>> make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5
>> --- encdb.h ---
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> Segmentation fault
>> *** [encdb.h] Error code 139
>> 
>> make[1]: stopped in /wrkdirs/usr/ports/lang/ruby24/work/ruby-2.4.5
>> 2 errors
>> 
>> 
>> Despite how the above looks, I find only one .core file in the
>> tar archive produced for the failure:
>> 
>> # find /wrkdirs/usr/ports/lang/ruby/ -name "*.core" -print
>> /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/qemu_miniruby.core
>> 
>> Apparently qemu does not allow for separate files for distinct
>> processes.
>> 
>> For that .core file I find (libexec/gdb):
>> 
>> # chroot /usr/obj/DESTDIRs/clang-armv7-installworld-poud
>> # cd /wrkdirs/usr/ports/lang/ruby/work/ruby-2.4.5/
>> # /usr/libexec/gdb miniruby qemu_miniruby.core 
>> . . .
>> (gdb) bt
>> #0  0x00113f84 in rb_gc_writebarrier_unprotect (obj=4104601600) at gc.c:1119
>> 1119 return RVALUE_WB_UNPROTECTED_BITMAP(obj) != 0;
>> [New Thread f4b5d000 (LWP 100638/)]
>> [New LWP 61684]
>> Current language:  auto; currently minimal
>> (gdb) bt
>> #0  0x00113f84 in rb_gc_writebarrier_unprotect (obj=4104601600) at gc.c:1119
>> #1  0x000c3fc8 in rb_include_class_new (module=4104569400, super=> optimized out>) at ruby.h:1456
>> #2  0x000c4424 in include_modules_at (klass=4104602160, c=4104602160, 
>> module=4104569400, search_super=) at class.c:913
>> #3  0x000c41f0 in rb_include_module (klass=4104602160, module=4104569400) at 
>> class.c:870
>> #4  0x001f6dec in Init_String () at string.c:10021
>> #5  0x00129398 in rb_call_inits () at inits.c:28
>> #6  0x00103bac in ruby_setup () at eval.c:60
>> #7  0x00103be8 in ruby_init () at eval.c:76
>> #8  0x000a3300 in main (argc=11, argv=0x9fffe41c) at main.c:35
>> (gdb) up
>> #1  0x000c3fc8 in rb_include_class_new (module=4104569400, super=> optimized out>) at ruby.h:1456
>> 1456 rb_gc_writebarrier_unprotect(x);
>> (gdb) up
>> #2  0x000c4424 in include_modules_at (klass=4104602160, c=4104602160, 
>> module=4104569400, search_super=) at class.c:913
>> 913  iclass = rb_include_class_new(module, RCLASS_SUPER(c));
>> (gdb) up
>> #3  0x000c41f0 in rb_include_module (klass=4104602160, module=4104569400) at 
>> class.c:870
>> 870  changed = include_modules_at(klass, RCLASS_ORIGIN(klass), module, 
>> TRUE);
>> (gdb) up
>> #4  0x001f6dec in Init_String () at string.c:10021
>> 10021rb_include_module(rb_cString, rb_mComparable);
>> (gdb) up
>> #5  0x00129398 in rb_call_inits () at inits.c:28
>> 28   CALL(String);
>> (gdb) up
>> #6  0x00103bac in ruby_setup () at eval.c:60
>> 60   rb_call_inits();
>> (gdb) up
>> #7  0x00103be8 in ruby_init () at eval.c:76
>> 76   int state = ruby_setup();
>> (gdb) up
>> #8  0x000a3300 in main (argc=11, argv=0x9fffe41c) at main.c:35
>> 35   ruby_init();
>> 
>> (I'm not familiar with what details libexec/gdb gets
>> right vs. wrong. But the call chain seems coherent.)
>> 
>> Host environment:
>> 
>> # uname -apKU
>> FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r340287M: Fri Nov  9 
>> 08:37:01 PST 2018 
>> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
>>   amd64 amd64 133 133
> 
> A prior example that fails for native armv7 builds
> but works for poudriere-devel/qemu-arm-static/nxb-bin/
> (native cross tools based) amd64 -> armv7 cross builds
> is x11/pixman.
> 
> 

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)

[Mark Millard via freebsd-ports]

On 2018-Dec-28, at 12:12, Mark Millard  wrote:

> On 2018-Dec-28, at 05:13, Michal Meloun  wrote:
> 
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races). Theses races cannot be solved without major
>> rewrite of syscall emulation code.
>> Unfortunately, nobody actively works on this, I think.
>> 
> 
> Thanks for the note setting some expectations.
> 
> On the evidence that I have I expect that more is going on than that:
> 
> A) The hang-up always happens and always in the same place. So
> it would appear that no race is involved.
> 
> B) (A) is true even for varying the number of builders in parallel
> (so other builds also happening) and the number of jobs allowed per
> builder. It also fails for only one builder allowed only one process.
> (I get traces from that last kind of context.)
> 
> C) The problem started on the package-building servers for armv7
> and armv6 without qemu-user-static having an update (FreeBSD and
> cmake had updates, for example).
> 
> D) The problem is only observed for targeting armv7 and armv6 as
> far as I can tell. I've never seen it for aarch64, neither my
> own builds nor when I looked at the package-building server
> history.
> 
> At least that is what got me started. (I've since learned that
> qemu-user-static uses fork in place of a requested vfork.)
> 
> My ktrace/kdump experiment yesterday showed something odd for the
> kevent that hangs in cmake:
> 
> 93172 qemu-arm-static CALL  
> kevent(0x3,0x7ffe7d40,0x2,0x7ffd7d40,0x400,0)
> 93172 qemu-arm-static STRU  struct kevent[] = { { ident=6, 
> filter=EVFILT_READ, flags=0x1, fflags=0, data=0, udata=0x0 }
> { ident=0x0, filter=, flags=0, fflags=0x8, 
> data=0x1, udata=0x0 } }
> 
> Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the struct
> kevent[]. The kevent use is from cmake.
> 
> So far I've not identified a signal being delivered at a time that would seem
> to me to be likely to contribute. (But this is not familiar code so my 
> judgment
> is likely not the best.)
> 
> Note: I normally run FreeBSD using a non-debug kernel, even when using
> head. (The kernel does have symbols.)


The detail of the signal usage involved leading up to the hang-up,
starting from just before the "press return" for the "make FLAVOR=qt5"
command that I had entered:

The only "Interrupted system call" prior to my killing the hung cmake
process was (kdump -H -r -S output):

 93172 100717 qemu-arm-static CALL  execve[59](0x10392,0x8605051a0,0x860cf5400)
 93172 101706 qemu-arm-static RET   nanosleep[240] -1 errno 4 Interrupted 
system call
 93172 100717 qemu-arm-static NAMI  "/bin/sh"
 93172 100717 sh   RET   execve[59] JUSTRETURN
 93172 100717 sh   CALL  readlink[58](0x207a65,0x7fffccc0,0x400)

This is where ninja (via qemu-arm-static) execve's the amd64-native /bin/sh (to
in turn later run cmake via qemu-arm-static). (This was after the fork [for the
requested vfork].) So it is for the close-down of the thread that was in
nanosleep.

There were no PSIG's and no sigreturn's prior to the kill according to the
kdump output.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard via freebsd-ports]

On 2018-Dec-31, at 10:16, Jonathan Chen  wrote:

> On Mon, 31 Dec 2018 at 21:05, Mark Millard  wrote:
> [...]
>> But if you have a form of hang-up that shows no sign of being tied
>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>> change(s) would fix the issue.
> 
> With the __packed-modified qemu-user-static, the amd64->armv7
> crossbuilds does not hang anymore, but I get build failures instead.
> Interestingly enough, an unmodified qemu-user-static gets further
> along in a amd64->armv6 crossbuild, with only one reproducible hang.

I tend to compare cross-build failures to native-build attempts. The
multimedia-gstreamer1-qt@qt5 hang-up was qemu-arm-static specific,
not occurring native. That and being reliable about hanging-up is
what prompted the investigation.

The lld thread fanout hangup also has only happened under
qemu-arm-static but I do not have a context with more than 4 cores for
armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD
native) that I use for cross-builds.

I do not know if you care to but it is possible to see if the FreeBSD
package builders get failures or hangs for the same ports. I use
head port build examples below:

http://beefy16.nyi.freebsd.org/jail.html?mastername=head-armv7-default

http://beefy8.nyi.freebsd.org/jail.html?mastername=head-armv6-default

The pages displayed show a list of port version (p??) and freebsd
version (s??) looking like p??_s?? . Those links take you
to pages for exploring the built, failed, skipped, and ignored
ports.

Of course, for race-condition problems in builds, checking is messier
because of needing to look at possibly many port/system combinations.

My attempts to build x11/lumina fail for:

[00:01:02] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2
[00:02:23] [01] [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 wrkdir to: 
/usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx-1.7.0_2.tar
[00:02:23] [01] [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: Failed: 
build
[00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: Dependent 
port multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-libav | 
gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | libvpx-1.7.0_2 
failed
[00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-plugins-core | 
gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | libvpx-1.7.0_2 
failed
[00:02:24] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: Dependent port 
multimedia/libvpx | libvpx-1.7.0_2 failed
[00:02:24] [01] [00:01:22] Skipping x11/lumina-core | lumina-core-1.4.1: 
Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
. . .
[00:06:19] Failed ports: multimedia/libvpx:build
[00:06:19] Skipped ports: multimedia/ffmpeg multimedia/gstreamer1-libav 
multimedia/gstreamer1-plugins-core x11/lumina x11/lumina-core
[FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] Queued: 7  
Built: 1  Failed: 1  Skipped: 5  Ignored: 0  Tobuild: 0   Time: 00:06:16

Native build attempts on an armv7 get the same.

But I'm still at:

# svnlite info | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 341836
Last Changed Rev: 341836

because I froze at that while investigating the reliable hang and
have not started progressing again yet. Last I looked the
head-armv7-default package builds were also failing for libvpx if
I remember right.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

How to get multimedia/libvpx to build on a world that was built using WITHOUT_BINUTILS (armv7 example)

[Mark Millard via freebsd-ports]

[Note: My armv7 context builds ports with -mcpu=cortex-a7 via a make.conf
like file. The in-use world also was built with -mcpu=cortex-a7 .]

In order to avoid the likes of:

.  . .
as -meabi=5 --defsym ARCHITECTURE=7 -march=armv7-a -mfloat-abi=hard -mfpu=neon 
-I./ -I"/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0"/ -o 
vpx_dsp/arm/intrapred_neon_asm.asm.S.o vpx_dsp/arm/intrapred_neon_asm.asm.S
/bin/sh: as: not found
gmake[2]: *** [Makefile:199: vpx_dsp/arm/intrapred_neon_asm.asm.S.o] Error 127
gmake[1]: *** [Makefile:17: .DEFAULT] Error 2
gmake[1]: Leaving directory 
'/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.7.0'
*** Error code 1

Stop.
make: stopped in /usr/ports/multimedia/libvpx
. . .

in a context where FreeBSD world was built using WITHOUT_BINUTILS=
and then installed as the context for building ports, I made a change
to multimedia/libvpx/Makefile . I used:

# svnlite diff /usr/ports/multimedia/libvpx/Makefile 
Index: /usr/ports/multimedia/libvpx/Makefile
===
--- /usr/ports/multimedia/libvpx/Makefile   (revision 488859)
+++ /usr/ports/multimedia/libvpx/Makefile   (working copy)
@@ -14,7 +14,9 @@
 LICENSE_FILE=  ${WRKSRC}/LICENSE
 
 BUILD_DEPENDS= nasm:devel/nasm
+BUILD_DEPENDS+= as:devel/binutils
 
+
 USE_GITHUB=yes
 GH_ACCOUNT=webmproject
 

After which the reattempted build via poudriere-devel got:

[00:02:35] [02] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_3
. . .
[00:05:49] [02] [00:03:14] Finished multimedia/libvpx | libvpx-1.7.0_3: Success



(That text was actually taken from a amd64->armv7 cross-build environment
output.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]

[Mark Millard via freebsd-ports]

[I listed my /usr/src svn veriosn information instead of /usr/ports .
Correcting. . .]

On 2018-Dec-31, at 12:05, Mark Millard  wrote:

> On 2018-Dec-31, at 10:16, Jonathan Chen  wrote:
> 
>> On Mon, 31 Dec 2018 at 21:05, Mark Millard  wrote:
>> [...]
>>> But if you have a form of hang-up that shows no sign of being tied
>>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>>> change(s) would fix the issue.
>> 
>> With the __packed-modified qemu-user-static, the amd64->armv7
>> crossbuilds does not hang anymore, but I get build failures instead.
>> Interestingly enough, an unmodified qemu-user-static gets further
>> along in a amd64->armv6 crossbuild, with only one reproducible hang.
> 
> I tend to compare cross-build failures to native-build attempts. The
> multimedia-gstreamer1-qt@qt5 hang-up was qemu-arm-static specific,
> not occurring native. That and being reliable about hanging-up is
> what prompted the investigation.
> 
> The lld thread fanout hangup also has only happened under
> qemu-arm-static but I do not have a context with more than 4 cores for
> armv7: far less than 28 (FreeBSD under Hyper-V) or 32 cpus (FreeBSD
> native) that I use for cross-builds.
> 
> I do not know if you care to but it is possible to see if the FreeBSD
> package builders get failures or hangs for the same ports. I use
> head port build examples below:
> 
> http://beefy16.nyi.freebsd.org/jail.html?mastername=head-armv7-default
> 
> http://beefy8.nyi.freebsd.org/jail.html?mastername=head-armv6-default
> 
> The pages displayed show a list of port version (p??) and freebsd
> version (s??) looking like p??_s?? . Those links take you
> to pages for exploring the built, failed, skipped, and ignored
> ports.
> 
> Of course, for race-condition problems in builds, checking is messier
> because of needing to look at possibly many port/system combinations.
> 
> My attempts to build x11/lumina fail for:
> 
> [00:01:02] [01] [00:00:00] Building multimedia/libvpx | libvpx-1.7.0_2
> [00:02:23] [01] [00:01:21] Saved multimedia/libvpx | libvpx-1.7.0_2 wrkdir 
> to: 
> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/libvpx-1.7.0_2.tar
> [00:02:23] [01] [00:01:21] Finished multimedia/libvpx | libvpx-1.7.0_2: 
> Failed: build
> [00:02:24] [01] [00:01:22] Skipping multimedia/ffmpeg | ffmpeg-4.1,1: 
> Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
> [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-libav | 
> gstreamer1-libav-1.14.4_2: Dependent port multimedia/libvpx | libvpx-1.7.0_2 
> failed
> [00:02:24] [01] [00:01:22] Skipping multimedia/gstreamer1-plugins-core | 
> gstreamer1-plugins-core-1.14: Dependent port multimedia/libvpx | 
> libvpx-1.7.0_2 failed
> [00:02:24] [01] [00:01:22] Skipping x11/lumina | lumina-1.4.1,3: Dependent 
> port multimedia/libvpx | libvpx-1.7.0_2 failed
> [00:02:24] [01] [00:01:22] Skipping x11/lumina-core | lumina-core-1.4.1: 
> Dependent port multimedia/libvpx | libvpx-1.7.0_2 failed
> . . .
> [00:06:19] Failed ports: multimedia/libvpx:build
> [00:06:19] Skipped ports: multimedia/ffmpeg multimedia/gstreamer1-libav 
> multimedia/gstreamer1-plugins-core x11/lumina x11/lumina-core
> [FBSDFSSDjailArmV7-default] [2018-12-30_17h04m02s] [committing:] Queued: 7  
> Built: 1  Failed: 1  Skipped: 5  Ignored: 0  Tobuild: 0   Time: 00:06:16
> 
> Native build attempts on an armv7 get the same.
> 
> But I'm still at:
> 
> . . .

Correcting to have the /usr/ports  information:

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 484783
Last Changed Rev: 484783


> 
> because I froze at that while investigating the reliable hang and
> have not started progressing again yet. Last I looked the
> head-armv7-default package builds were also failing for libvpx if
> I remember right.

Looks like more recently libvpx builds on the package builders. So next time
that I update the ports tree I'll get to see the next problem (if any).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How much memory to compile www/chromium?

[Mark Millard via freebsd-ports]

On 2019-Jan-1, at 10:21, bob prohaska  wrote:

> On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote:
>> 
>> Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile 
>> successfully over
>> several days. The -DBATCH option was used, in hopes it'd fetch the right 
>> options. 
>> 
> 
> Just for fun I added a mechanical hard disk with a 4 GB swap partition and 
> re-ran
> the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see what 
> happens.
> OOMA was turned off with vm.pageout_oom_seq="2048" in /boot/loader.conf.
> 
> After ~11 days the process finished. Log files of gstat output and make 
> output are at 
> http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/
> in case anyone's curious. The log files are around 100MB, it seems quickest 
> to download 
> them to look around. Swap use peaked at 3522008 kB. If gstat is to be believed
> the bottleneck appears to be the mechanical hard disk, which showed near
> 100% busy when the microSD swap partition was around 15% busy. Apart from a 
> few
> "indefinite wait..." warnings on the console there was no indication of 
> errors.
> 
> As a further test, I'ved added two additional USB flash swap devices and am 
> re-running
> the compilation of www/chromium. The swap layout is quite lopsided, with the 
> USB flash
> devices having only 2 GB swap partitions on each, contrasting to the 4 GB 
> swap partitions
> on the microSD card and mechanical disk. 
> 
> The first oddity is that top doesn't seem to see the extra swap space, 
> reporting only 
> 7192M total.

If you start top before changing the swap space (swapon or
swapoff), top does not change to match: it does not monitor
the swap space total size over time. But I've no other clue
to the ordering that actually occurred.

> Swapinfo does seem to plausibly report swap status as
> Device  1K-blocks UsedAvail Capacity
> /dev/mmcsd0s2b440425252228  4352024 1%
> /dev/da0p1419430450848  4143456 1%
> /dev/da2p5209715228232  2068920 1%
> /dev/da1f 209715228060  2069092 1%
> Total12792860   159368 12633492 1%
> 
> after running overnight.
> 
> "indefinite wait..." warnings on the console have returned in abundance with 
> the use
> of USB flash swap, even though swap usage is still less than 200MB. 

You might want to report the types/models of the USB flash devices that
were in used. Also relevant is the past usage pattern and amount of
prior use on the USB flash devices.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 (with backtrace, code, and value details)

[Mark Millard via freebsd-ports]

The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, unlike
the last hang-up that I analyzed. I do not yet know how repeatable this is
but the original hang-up and the one experiment the below is from.

>From top:

  PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
COMMAND
12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
/wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0

Note: The vast margority of the 36:06 has been stuck in the uwait loop involved.

>From ps -auxd:

root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 |   
`-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
graphics/poppler-qt5
root19440.0  0.0  12932  3540  1  I+   10:420:00.00 |   
  |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
graphics/poppler-qt5
root19570.0  0.0  12932  3556  1  I10:420:00.04 |   
  |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
(poppler-qt5-0.72.0) (sh)
root   123280.0  0.0  12932  3548  1  I10:490:00.00 |   
  | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
(poppler-qt5-0.72.0) (sh)
root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 |   
  |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 |   
  | `-- /usr/bin/make -f Makefile 
DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 |   
  |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 |   
  | `-- /nxb-bin/usr/bin/make -f 
qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 |   
  |   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E 
cmake_autogen /wrkdirs/usr/ports/graphics/
root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 |   
  `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
graphics/poppler-qt5


(gdb) attach 12789
Attaching to process 12789
Reading symbols from 
/usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
[New LWP 101168 of process 12789]
[New LWP 101178 of process 12789]
[New LWP 101499 of process 12789]
[Switching to LWP 100304 of process 12789]
_umtx_op () at _umtx_op.S:3
3   RSYSCALL(_umtx_op)
(gdb) info threads
  Id   Target Id   Frame 
* 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
  2LWP 101168 of process 12789 _umtx_op_err () at 
/usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
  3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
  4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
(dst=, expect=, src=536870912) at 
/usr/include/machine/atomic.h:220
(gdb) thread 4
[Switching to thread 4 (LWP 101499 of process 12789)]
#0  0x60051c26 in atomic_cmpset_int (dst=, 
expect=, src=536870912) at /usr/include/machine/atomic.h:220
220 ATOMIC_CMPSET(int);

(gdb) bt
#0  0x60051c26 in atomic_cmpset_int (dst=, 
expect=, src=536870912) at /usr/include/machine/atomic.h:220
#1  tcmpset_32 (addr=, a=, b=536870912) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
#2  freebsd_rw_unlock (target_addr=4108246528) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
#3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
op=536870912, val=, uaddr=, 
target_time=)
at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
#4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
arg1=, arg2=, arg3=, arg4=0, 
arg5=0, arg6=-184411592, arg7=-199471616, 
arg8=-1622188640) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364
#5  0x600392f0 in target_cpu_loop (env=0x86159b118) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/arm/target_arch_cpu.h:207
#6  0x60038c99 in cpu_loop (env=0xf4dede80) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/main.c:121
#7  0x60050c1a in new_freebsd_thread_start (arg=) at 
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:152
#8  0x601ad5f6 in thread_start (curthread=0x861571300) at 

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [problem possibly found]

[Mark Millard via freebsd-ports]

[It looks to me like the assembler code has some code moved out of the
loop that it should not be (by intent). It appears that calling
tcmpset_32 does not prevent code motion to before the call and
the variable involved was not declared volatile.]

On 2019-Jan-1, at 18:43, Mark Millard  wrote:

> The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
> cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, unlike
> the last hang-up that I analyzed. I do not yet know how repeatable this is
> but the original hang-up and the one experiment the below is from.
> 
> From top:
> 
>  PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
> COMMAND
> 12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0
> 
> Note: The vast margority of the 36:06 has been stuck in the uwait loop 
> involved.
> 
> From ps -auxd:
> 
> root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 | 
>   `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> root19440.0  0.0  12932  3540  1  I+   10:420:00.00 | 
> |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> root19570.0  0.0  12932  3556  1  I10:420:00.04 | 
> |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> (poppler-qt5-0.72.0) (sh)
> root   123280.0  0.0  12932  3548  1  I10:490:00.00 | 
> | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> (poppler-qt5-0.72.0) (sh)
> root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 | 
> |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
> root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 | 
> | `-- /usr/bin/make -f Makefile 
> DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
> root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 | 
> |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
> root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 | 
> | `-- /nxb-bin/usr/bin/make -f 
> qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
> root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 | 
> |   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
> -E cmake_autogen /wrkdirs/usr/ports/graphics/
> root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 | 
> `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> 
> 
> (gdb) attach 12789
> Attaching to process 12789
> Reading symbols from 
> /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
> [New LWP 101168 of process 12789]
> [New LWP 101178 of process 12789]
> [New LWP 101499 of process 12789]
> [Switching to LWP 100304 of process 12789]
> _umtx_op () at _umtx_op.S:3
> 3 RSYSCALL(_umtx_op)
> (gdb) info threads
>  Id   Target Id   Frame 
> * 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
>  2LWP 101168 of process 12789 _umtx_op_err () at 
> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
>  3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
>  4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
> (dst=, expect=, src=536870912) at 
> /usr/include/machine/atomic.h:220
> (gdb) thread 4
> [Switching to thread 4 (LWP 101499 of process 12789)]
> #0  0x60051c26 in atomic_cmpset_int (dst=, 
> expect=, src=536870912) at /usr/include/machine/atomic.h:220
> 220   ATOMIC_CMPSET(int);
> 
> (gdb) bt
> #0  0x60051c26 in atomic_cmpset_int (dst=, 
> expect=, src=536870912) at /usr/include/machine/atomic.h:220
> #1  tcmpset_32 (addr=, a=, b=536870912) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
> #2  freebsd_rw_unlock (target_addr=4108246528) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
> #3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
> op=536870912, val=, uaddr=, 
> target_time=)
>at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
> #4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
> arg1=, arg2=, arg3=, arg4=0, 
> arg5=0, arg6=-184411592, arg7=-199471616, 
>arg8=-1622188640) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364
> #5  0x600392f0 in target_cpu_loop (env=0x86159b118) at 
> 

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

[Mark Millard via freebsd-ports]

On 2019-Jan-1, at 18:43, Mark Millard  wrote:

> The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
> cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, unlike
> the last hang-up that I analyzed. I do not yet know how repeatable this is
> but the original hang-up and the one experiment the below is from.
> 
> From top:
> 
>  PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
> COMMAND
> 12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0
> 
> Note: The vast margority of the 36:06 has been stuck in the uwait loop 
> involved.
> 
> From ps -auxd:
> 
> root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 | 
>   `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> root19440.0  0.0  12932  3540  1  I+   10:420:00.00 | 
> |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> root19570.0  0.0  12932  3556  1  I10:420:00.04 | 
> |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> (poppler-qt5-0.72.0) (sh)
> root   123280.0  0.0  12932  3548  1  I10:490:00.00 | 
> | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> (poppler-qt5-0.72.0) (sh)
> root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 | 
> |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
> root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 | 
> | `-- /usr/bin/make -f Makefile 
> DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
> root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 | 
> |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
> root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 | 
> | `-- /nxb-bin/usr/bin/make -f 
> qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
> root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 | 
> |   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
> -E cmake_autogen /wrkdirs/usr/ports/graphics/
> root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 | 
> `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> 
> 
> (gdb) attach 12789
> Attaching to process 12789
> Reading symbols from 
> /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
> [New LWP 101168 of process 12789]
> [New LWP 101178 of process 12789]
> [New LWP 101499 of process 12789]
> [Switching to LWP 100304 of process 12789]
> _umtx_op () at _umtx_op.S:3
> 3 RSYSCALL(_umtx_op)
> (gdb) info threads
>  Id   Target Id   Frame 
> * 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
>  2LWP 101168 of process 12789 _umtx_op_err () at 
> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
>  3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
>  4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
> (dst=, expect=, src=536870912) at 
> /usr/include/machine/atomic.h:220
> (gdb) thread 4
> [Switching to thread 4 (LWP 101499 of process 12789)]
> #0  0x60051c26 in atomic_cmpset_int (dst=, 
> expect=, src=536870912) at /usr/include/machine/atomic.h:220
> 220   ATOMIC_CMPSET(int);
> 
> (gdb) bt
> #0  0x60051c26 in atomic_cmpset_int (dst=, 
> expect=, src=536870912) at /usr/include/machine/atomic.h:220
> #1  tcmpset_32 (addr=, a=, b=536870912) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
> #2  freebsd_rw_unlock (target_addr=4108246528) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
> #3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
> op=536870912, val=, uaddr=, 
> target_time=)
>at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
> #4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
> arg1=, arg2=, arg3=, arg4=0, 
> arg5=0, arg6=-184411592, arg7=-199471616, 
>arg8=-1622188640) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364
> #5  0x600392f0 in target_cpu_loop (env=0x86159b118) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/arm/target_arch_cpu.h:207
> #6  0x60038c99 in cpu_loop (env=0xf4dede80) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/main.c:121
> #7  0x60050c1a in 

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [problem not found]

[Mark Millard via freebsd-ports]

[I was wrong: it is code elimination, not motion. volatile is
not a fix.]

On 2019-Jan-1, at 19:37, Mark Millard  wrote:

> [It looks to me like the assembler code has some code moved out of the
> loop that it should not be (by intent). It appears that calling
> tcmpset_32 does not prevent code motion to before the call and
> the variable involved was not declared volatile.]
> 
> On 2019-Jan-1, at 18:43, Mark Millard  wrote:
> 
>> The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
>> cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, 
>> unlike
>> the last hang-up that I analyzed. I do not yet know how repeatable this is
>> but the original hang-up and the one experiment the below is from.
>> 
>> From top:
>> 
>> PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
>> COMMAND
>> 12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
>> /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0
>> 
>> Note: The vast margority of the 36:06 has been stuck in the uwait loop 
>> involved.
>> 
>> From ps -auxd:
>> 
>> root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 |
>>`-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
>> graphics/poppler-qt5
>> root19440.0  0.0  12932  3540  1  I+   10:420:00.00 |
>>  |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
>> graphics/poppler-qt5
>> root19570.0  0.0  12932  3556  1  I10:420:00.04 |
>>  |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
>> (poppler-qt5-0.72.0) (sh)
>> root   123280.0  0.0  12932  3548  1  I10:490:00.00 |
>>  | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
>> (poppler-qt5-0.72.0) (sh)
>> root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 |
>>  |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
>> root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 |
>>  | `-- /usr/bin/make -f Makefile 
>> DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
>> root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 |
>>  |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
>> root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 |
>>  | `-- /nxb-bin/usr/bin/make -f 
>> qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
>> root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 |
>>  |   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
>> -E cmake_autogen /wrkdirs/usr/ports/graphics/
>> root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 |
>>  `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
>> graphics/poppler-qt5
>> 
>> 
>> (gdb) attach 12789
>> Attaching to process 12789
>> Reading symbols from 
>> /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
>> [New LWP 101168 of process 12789]
>> [New LWP 101178 of process 12789]
>> [New LWP 101499 of process 12789]
>> [Switching to LWP 100304 of process 12789]
>> _umtx_op () at _umtx_op.S:3
>> 3RSYSCALL(_umtx_op)
>> (gdb) info threads
>> Id   Target Id   Frame 
>> * 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
>> 2LWP 101168 of process 12789 _umtx_op_err () at 
>> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
>> 3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
>> 4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
>> (dst=, expect=, src=536870912) at 
>> /usr/include/machine/atomic.h:220
>> (gdb) thread 4
>> [Switching to thread 4 (LWP 101499 of process 12789)]
>> #0  0x60051c26 in atomic_cmpset_int (dst=, 
>> expect=, src=536870912) at /usr/include/machine/atomic.h:220
>> 220  ATOMIC_CMPSET(int);
>> 
>> (gdb) bt
>> #0  0x60051c26 in atomic_cmpset_int (dst=, 
>> expect=, src=536870912) at /usr/include/machine/atomic.h:220
>> #1  tcmpset_32 (addr=, a=, b=536870912) at 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
>> #2  freebsd_rw_unlock (target_addr=4108246528) at 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
>> #3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
>> op=536870912, val=, uaddr=, 
>> target_time=)
>>   at 
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
>> #4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
>> arg1=, arg2=, arg3=, arg4=0, 
>> arg5=0, arg6=-184411592, arg7=-199471616, 
>>   arg8=-1622188640) at 
>> 

qemu-x86_64-static has target_msghdr's msg_controllen field with the wrong size so its msg_flags is at the wrong offset and target_msghdr is too large

[Mark Millard via freebsd-ports]

[qemu-aarch64-static has the same problem but qemu-armv7-sstatic does not. The 
context here
is FreeBSD head -r341836 based and ports head -r488859 based.]

Note: I assume that "struct target_msghdr" is meant to match the memory layout
of the target's native "struct msghdr". Otherwise the reported differences
below could be irrelevant.

For amd64 and aarch64 the following code:

printf("sizeof(struct msghdr) = %lu\n", (unsigned long) sizeof(struct 
msghdr));
printf("msg_name %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_name));
printf("msg_namelen %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_namelen));
printf("msg_iov %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_iov));
printf("msg_iovlen %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_iovlen));
printf("msg_control %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_control));
printf("msg_controllen %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_controllen));
printf("msg_flags %lu\n", (unsigned long) offsetof(struct msghdr, 
msg_flags));


produces:

sizeof(struct msghdr) = 48
msg_name 0
msg_namelen 8
msg_iov 16
msg_iovlen 24
msg_control 32
msg_controllen 40
msg_flags 44

Note: msg_controllen was apparently 4 bytes wide on these 64-bit architectures.


However gdb reports for qemu-x86_64-static and qemu-aarch64-static:

(gdb) p/d sizeof(struct target_msghdr)
$1 = 56
(gdb) p/d &((struct target_msghdr *)0)->msg_name 
$2 = 0
(gdb) p/d &((struct target_msghdr *)0)->msg_namelen
$3 = 8
(gdb) p/d &((struct target_msghdr *)0)->msg_iov
$4 = 16
(gdb) p/d &((struct target_msghdr *)0)->msg_iovlen
$5 = 24
(gdb) p/d &((struct target_msghdr *)0)->msg_control
$6 = 32
(gdb) p/d &((struct target_msghdr *)0)->msg_controllen
$7 = 40
(gdb) p/d &((struct target_msghdr *)0)->msg_flags
$8 = 48

Note the larger size (56 instead of 48) and that msg_controllen 's size
puts msg_flags at the wrong offset.



Notably for armv7, gdb's information for armv7 agrees with:

sizeof(struct msghdr) = 28
msg_name 0
msg_namelen 4
msg_iov 8
msg_iovlen 12
msg_control 16
msg_controllen 20
msg_flags 24

Apparently msg_controllen should always be 4 bytes wide, even on
64-bit architectures instead of tracking the 64-bit vs. 32-bit
status for the architecture.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-x86_64-static has target_freebsd_flock being too small (__packed use issue) [subject correction: fixed to be "too small"]

[Mark Millard via freebsd-ports]

[Just correcting the "larger" to be "smaller".]

On 2019-Jan-4, at 19:29, Mark Millard  wrote:

[qemu-aarch64-static has the same problem but qemu-armv7-sstatic does not. The 
context here
is FreeBSD head -r341836 based and ports head -r488859 based.]

Note: I assume that "struct target_freebsd_flock" is meant to match the memory 
layout
of the target's native "struct flock". Otherwise the reported differences
below could be irrelevant.

For amd64 and aarch64 the following code:

   printf("sizeof(struct flock) = %lu\n", (unsigned long) sizeof(struct 
flock));
   printf("l_start %lu\n", (unsigned long) offsetof(struct flock, l_start));
   printf("l_len %lu\n", (unsigned long) offsetof(struct flock, l_len));
   printf("l_pid %lu\n", (unsigned long) offsetof(struct flock, l_pid));
   printf("l_type %lu\n", (unsigned long) offsetof(struct flock, l_type));
   printf("l_whence %lu\n", (unsigned long) offsetof(struct flock, 
l_whence));
   printf("l_sysid %lu\n", (unsigned long) offsetof(struct flock, l_sysid));


produces:

sizeof(struct flock) = 32
l_start 0
l_len 8
l_pid 16
l_type 20
l_whence 22
l_sysid 24


However gdb reports for qemu-x86_64-static and qemu-aarch64-static
and qemu-arm-static:

(gdb) p/d sizeof(struct target_freebsd_flock)
$10 = 28
(gdb) p/d &((struct target_freebsd_flock *)0)->l_start  
$11 = 0
(gdb) p/d &((struct target_freebsd_flock *)0)->l_len  
$12 = 8
(gdb) p/d &((struct target_freebsd_flock *)0)->l_pid
$13 = 16
(gdb) p/d &((struct target_freebsd_flock *)0)->l_type
$14 = 20
(gdb) p/d &((struct target_freebsd_flock *)0)->l_whence
$15 = 22
(gdb) p/d &((struct target_freebsd_flock *)0)->l_sysid 
$16 = 24

So only the overall size is different for this information. But:

struct target_freebsd_flock {
   int64_t l_start;
   int64_t l_len;
   int32_t l_pid;
   int16_t l_type;
   int16_t l_whence;
   int32_t l_sysid;
} QEMU_PACKED;

with a potential packed vs. /usr/include/sys/fcntl.h :

struct flock {
   off_t   l_start;/* starting offset */
   off_t   l_len;  /* len = 0 means until end of file */
   pid_t   l_pid;  /* lock owner */
   short   l_type; /* lock type: read/write, etc. */
   short   l_whence;   /* type of l_start */
   int l_sysid;/* remote system id or zero for local */
};

with no potential __packed.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

[Mark Millard via freebsd-ports]

On 2019-Jan-2, at 17:41, Kyle Evans  wrote:

> On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports
>  wrote:
>> 
>>> . . .
>> 
>> So (without old line numbers):
>> 
>>} else if (TARGET_URWLOCK_READER_COUNT(state) != 0) {
>>/* decrement reader count */
>>for (;;) {
>>if (!tcmpset_32(_urwlock->rw_state, state, (state  - 1))) {
>>__get_user(state, _urwlock->rw_state);
>>if (TARGET_URWLOCK_READER_COUNT(state) == 0) {
>>unlock_user_struct(target_urwlock,
>>target_addr, 1);
>>return -TARGET_EPERM;
>> }
>>} else {
>>break;
>>}
>>}
>> 
>> This follows the structure of other tcmpset_32 use in the source file.
>> 
>> With this change poudriere-devel's bulk worked for graphics/poppler-qt5
>> as a amd64->armv7 cross-build (FreeBSD head -r341836 based, under Hyper-V,
>> with 28 logical-processors assigned):
>> 
> 
> Ah, thanks for that! I think your analysis is correct, and I've
> created a pull request [1] for Sean. This should fix the apparent
> hangs reported by many across armv7/aarch64.
> 
> [1] https://github.com/seanbruno/qemu-bsd-user/pull/72

There is also the issue that the __packed use for target_freebsd_kevent
and target_freebsd11_kevent cause the wrong size and field offsets for
armv7 (and armv6) when translating to or from the host (amd64)
struct kevent vs. the target struct kevent. These hangs show up as
in the kqread state or other such implying kevent is hung-up,
unlike for the above.

I'm using the following for now:

> struct target_freebsd11_kevent {
>   abi_ulong  ident;
>   int16_tfilter;
>   uint16_t   flags;
>   uint32_t   fflags;
>   abi_long   data;
>   abi_ulong  udata;
> } ; // __packed;
> 
> struct target_freebsd_kevent {
>   abi_ulong  ident;
>   int16_tfilter;
>   uint16_t   flags;
>   uint32_t   fflags;
>   int64_t data;
>   abi_ulong  udata;
>   uint64_t  ext[4];
> } ; // __packed;

With these I was finally able to build lumina for armv7 via
a cross-build (amd64->armv7). Sean is aware of this.



However, I still get other hang-ups for targeting aarch64.
I've started trying to gather evidence for the one I currently
get.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

qemu-arm-static has target_freebsd11_nstat too small vs. arm native's struct nstat

[Mark Millard via freebsd-ports]

[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]

Note: I assume that "struct target_shmd_ds" is meant to match the memory layout
of the target's native "struct shmid_ds". Otherwise the reported differences
below could be irrelevant.

For armv7 (and likely armv6) the following code:

printf("sizeof(struct nstat) = %lu\n", (unsigned long) sizeof(struct 
nstat));
printf("st_dev %lu\n", (unsigned long) offsetof(struct nstat, st_dev));
printf("st_ino %lu\n", (unsigned long) offsetof(struct nstat, st_ino));
printf("st_mode %lu\n", (unsigned long) offsetof(struct nstat, 
st_mode));
printf("st_nlink %lu\n", (unsigned long) offsetof(struct nstat, 
st_nlink));
printf("st_uid %lu\n", (unsigned long) offsetof(struct nstat, st_uid));
printf("st_gid %lu\n", (unsigned long) offsetof(struct nstat, st_gid));
printf("st_rdev %lu\n", (unsigned long) offsetof(struct nstat, 
st_rdev));
printf("st_atim %lu\n", (unsigned long) offsetof(struct nstat, 
st_atim));
printf("st_mtim %lu\n", (unsigned long) offsetof(struct nstat, 
st_mtim));
printf("st_ctim %lu\n", (unsigned long) offsetof(struct nstat, 
st_ctim));
printf("st_size %lu\n", (unsigned long) offsetof(struct nstat, 
st_size));
printf("st_blocks %lu\n", (unsigned long) offsetof(struct nstat, 
st_blocks));
printf("st_blksize %lu\n", (unsigned long) offsetof(struct nstat, 
st_blksize));
printf("st_flags %lu\n", (unsigned long) offsetof(struct nstat, 
st_flags));
printf("st_gen %lu\n", (unsigned long) offsetof(struct nstat, st_gen));
printf("st_birthtim %lu\n", (unsigned long) offsetof(struct nstat, 
st_birthtim));

produces:

sizeof(struct nstat) = 128
st_dev 0
st_ino 4
st_mode 8
st_nlink 12
st_uid 16
st_gid 20
st_rdev 24
st_atim 32
st_mtim 48
st_ctim 64
st_size 80
st_blocks 88
st_blksize 96
st_flags 100
st_gen 104
st_birthtim 112

However gdb reports for qemu-arm-static (on amd64):

(gdb) p/d sizeof(struct target_freebsd11_nstat)
$41 = 116
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_dev   
$42 = 0
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_ino
$43 = 4
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_mode
$44 = 8
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_nlink
$45 = 10
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_uid  
$46 = 12
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_gid
$47 = 16
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_rdev
$48 = 20
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_atim
$49 = 24
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_mtim   
$50 = 40
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_ctim
$51 = 56
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_size   
$52 = 72
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_blocks
$53 = 80
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_blksize
$54 = 88
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_flags  
$55 = 92
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_gen  
$56 = 96
(gdb) p/d &((struct target_freebsd11_nstat *)0)->st_birthtim
$57 = 100

So after st_mode the offsets are wrong relative to struct nstat
(native to armv7).

/usr/include/sys/stat.h has:

struct nstat {
__uint32_t st_dev;  /* inode's device */
__uint32_t st_ino;  /* inode's number */
__uint32_t st_mode; /* inode protection mode */
__uint32_t st_nlink;/* number of hard links */
uid_t st_uid;   /* user ID of the file's owner */
gid_t st_gid;   /* group ID of the file's group */
__uint32_t st_rdev; /* device type */
struct  timespec st_atim;   /* time of last access */
struct  timespec st_mtim;   /* time of last data modification */
struct  timespec st_ctim;   /* time of last file status change */
off_t st_size;  /* file size, in bytes */
blkcnt_t st_blocks; /* blocks allocated for file */
blksize_t st_blksize;   /* optimal blocksize for I/O */
fflags_t  st_flags; /* user defined flags for file */
__uint32_t st_gen;  /* file generation number */
struct timespec st_birthtim;/* time of file creation */
/*
 * See comment in the definition of struct freebsd11_stat
 * above about the following padding.
 */
unsigned int :(8 / 2) * (16 - (int)sizeof(struct timespec));
unsigned int :(8 / 2) * (16 - (int)sizeof(struct timespec));
};

/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:

struct target_freebsd11_nstat {
uint32_t  st_dev;   /* inode's device */
uint32_t  st_ino;   /* inode's number */
int16_t   st_mode;  /* inode protection mode */
int16_t   st_nlink; /* number of hard 

qemu-arm-static has target_msqid_ds too small vs. arm natives msqid_ds

[Mark Millard via freebsd-ports]

[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]

Note: I assume that "struct target_msqid_ds" is meant to match the memory layout
of the target's native "struct msqid_ds". Otherwise the reported differences
below could be irrelevant.

For armv7 (and likely armv6) the following code:

printf("sizeof(struct msqid_ds) = %lu\n", (unsigned long) sizeof(struct 
msqid_ds));
printf("msg_perm %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_perm));
printf("__msg_first %lu\n", (unsigned long) offsetof(struct msqid_ds, 
__msg_first));
printf("__msg_last %lu\n", (unsigned long) offsetof(struct msqid_ds, 
__msg_last));
printf("msg_cbytes %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_cbytes));
printf("msg_qnum %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_qnum));
printf("msg_qbytes %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_qbytes));
printf("msg_lspid %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_lspid));
printf("msg_lrpid %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_lrpid));
printf("msg_stime %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_stime));
printf("msg_rtime %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_rtime));
printf("msg_ctime %lu\n", (unsigned long) offsetof(struct msqid_ds, 
msg_ctime));

produces:

sizeof(struct msqid_ds) = 80
msg_perm 0
__msg_first 24
__msg_last 28
msg_cbytes 32
msg_qnum 36
msg_qbytes 40
msg_lspid 44
msg_lrpid 48
msg_stime 56
msg_rtime 64
msg_ctime 72


However gdb reports for qemu-arm-static (on amd64):

(gdb) p/d sizeof(struct target_msqid_ds)
$14 = 64
(gdb) p/d &((struct target_msqid_ds *)0)->msg_first
$15 = 24
(gdb) p/d &((struct target_msqid_ds *)0)->msg_last 
$16 = 28
(gdb) p/d &((struct target_msqid_ds *)0)->msg_cbytes
$17 = 32
(gdb) p/d &((struct target_msqid_ds *)0)->msg_qnum  
$18 = 36
(gdb) p/d &((struct target_msqid_ds *)0)->msg_qbytes
$19 = 40
(gdb) p/d &((struct target_msqid_ds *)0)->msg_lspid 
$20 = 44
(gdb) p/d &((struct target_msqid_ds *)0)->msg_lrpid
$21 = 48
(gdb) p/d &((struct target_msqid_ds *)0)->msg_stime
$22 = 52
(gdb) p/d &((struct target_msqid_ds *)0)->msg_rtime
$23 = 56
(gdb) p/d &((struct target_msqid_ds *)0)->msg_ctime
$24 = 60

so after msg_lrpid the offsets are different.

/usr/include/sys/msg.h has:

struct msqid_ds {
struct  ipc_perm msg_perm;  /* msg queue permission bits */
struct  msg *__msg_first;   /* first message in the queue */
struct  msg *__msg_last;/* last message in the queue */
msglen_t msg_cbytes;/* number of bytes in use on the queue */
msgqnum_t msg_qnum; /* number of msgs in the queue */
msglen_t msg_qbytes;/* max # of bytes on the queue */
pid_t   msg_lspid;  /* pid of last msgsnd() */
pid_t   msg_lrpid;  /* pid of last msgrcv() */
time_t  msg_stime;  /* time of last msgsnd() */
time_t  msg_rtime;  /* time of last msgrcv() */
time_t  msg_ctime;  /* time of last msgctl() */
};

/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:

struct target_msqid_ds {
struct  target_ipc_perm msg_perm; /* msg queue permission bits */
abi_ulong   msg_first;  /* first message in the queue */
abi_ulong   msg_last;   /* last message in the queue */
abi_ulong   msg_cbytes; /* # of bytes in use on the queue */
abi_ulong   msg_qnum;   /* number of msgs in the queue */
abi_ulong   msg_qbytes; /* max # of bytes on the queue */
int32_t msg_lspid;  /* pid of last msgsnd() */
int32_t msg_lrpid;  /* pid of last msgrcv() */
abi_ulong   msg_stime;  /* time of last msgsnd() */
abi_ulong   msg_rtime;  /* time of last msgrcv() */
abi_ulong   msg_ctime;  /* time of last msgctl() */
};

abi_ulong's for msg_stime, msg_rtime, and msg_ctime are the wrong
size for armv7: arm uses 64-bit time_t. As of 12+ only i386
uses 32-bit time_t if I understand right. In 11.x 32-bit powerpc
also uses 32-bit time_t.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

qemu-arm-static has target_semd_ds too small vs. arm natives semid_ds

[Mark Millard via freebsd-ports]

[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]

Note: I assume that "struct target_semd_ds" is meant to match the memory layout
of the target's native "struct semid_ds". Otherwise the reported differences
below could be irrelevant.

For armv7 (and likely armv6) the following code:

printf("sizeof(struct semid_ds) = %lu\n", (unsigned long) sizeof(struct 
semid_ds));
printf("sem_perm %lu\n", (unsigned long) offsetof(struct semid_ds, 
sem_perm));
printf("__sem_base %lu\n", (unsigned long) offsetof(struct semid_ds, 
__sem_base));
printf("sem_nsems %lu\n", (unsigned long) offsetof(struct semid_ds, 
sem_nsems));
printf("sem_otime %lu\n", (unsigned long) offsetof(struct semid_ds, 
sem_otime));
printf("sem_ctime %lu\n", (unsigned long) offsetof(struct semid_ds, 
sem_ctime));
 
produces:

sizeof(struct semid_ds) = 48
sem_perm 0
__sem_base 24
sem_nsems 28
sem_otime 32
sem_ctime 40

However gdb reports for qemu-arm-static (on amd64):

(gdb) p/d sizeof(struct target_semid_ds)
$25 = 40
(gdb) p/d &((struct target_semid_ds *)0)->sem_perm 
$26 = 0
(gdb) p/d &((struct target_semid_ds *)0)->sem_base  
$27 = 24
(gdb) p/d &((struct target_semid_ds *)0)->sem_nsems
$28 = 28
(gdb) p/d &((struct target_semid_ds *)0)->sem_otime
$29 = 32
(gdb) p/d &((struct target_semid_ds *)0)->sem_ctime
$30 = 36

so after sem_otime the offsets are different.

/usr/include/sys/sem.h has:

struct semid_ds {
struct ipc_perm sem_perm;   /* operation permission struct */
struct sem  *__sem_base;/* pointer to first semaphore in set */
unsigned short  sem_nsems;  /* number of sems in set */
time_t  sem_otime;  /* last operation time */
time_t  sem_ctime;  /* last change time */
/* Times measured in secs since */
/* 00:00:00 UTC, Jan. 1, 1970, without 
leap seconds */
};

/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:

struct target_semid_ds {
struct target_ipc_perm sem_perm; /* operation permission struct */
abi_ulong   sem_base;   /* pointer to first semaphore in set */
uint16_tsem_nsems;  /* number of sems in set */
abi_ulong   sem_otime;  /* last operation time */
abi_ulong   sem_ctime;  /* times measured in secs */
};

abi_ulong's for sem_otime, and sem_otime are the wrong
size for armv7: arm uses 64-bit time_t. As of 12+ only i386
uses 32-bit time_t if I understand right. In 11.x 32-bit powerpc
also uses 32-bit time_t.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"