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 )

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

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

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

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

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

Re: Removing objdump breaks GCC configure

[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

Re: setting port options for multiple 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

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

[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.]

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

[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

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

[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

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

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

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

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

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

[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

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

[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

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

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}

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

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

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

[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

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

[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

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

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

Re: Removing objdump breaks GCC configure

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 >>>

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

[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

Re: getting PKGNAME from CONFLICTS

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.

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

[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. > > . . . >

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

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]

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

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

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

[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 - >

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

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=

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

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 . . . >> >>

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

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} >>

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

> 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

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

(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 ---

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

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:

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

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 --- >>

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

[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,

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

# 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

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

[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

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

[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

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

[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

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

[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

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

[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: >

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

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

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

[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: >>>

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

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-threa

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

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

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

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 analogo

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

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

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

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

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

[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.

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

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

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

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. >> &

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

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 |

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

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 ---

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

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: >>>> &g

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

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

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

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: >>

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

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:

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

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 |

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

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

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

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 >>

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

[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

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

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

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

[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

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

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

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

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

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

[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]

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

[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

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

[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

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

[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

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

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 >>

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

[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

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

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

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

[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

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

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

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

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

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

[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

Re: Problems building rust with poudriere

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 >

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

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

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

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

Re: error: undefined symbol: OPENSSL_cpuid_setup

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:

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

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

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

[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

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

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

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

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

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

[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

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

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 >

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

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

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

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

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

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

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]

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

How to get multimedia/libvpx to build on a world that was built using WITHOUT_BINUTILS (armv7 example)

[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./

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]

[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

Re: How much memory to compile www/chromium?

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.

qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 (with backtrace, code, and value details)

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.

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [problem possibly found]

[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: >

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

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

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [problem not found]

[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

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

[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

Re: qemu-x86_64-static has target_freebsd_flock being too small (__packed use issue) [subject correction: fixed to be "too small"]

[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

Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

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

qemu-arm-static has target_freebsd11_nstat too small vs. arm native's struct nstat

[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)

qemu-arm-static has target_msqid_ds too small vs. arm natives msqid_ds

[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)

qemu-arm-static has target_semd_ds too small vs. arm natives semid_ds

[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)

  1   2   3   4   >