Re: Building qt5-gui port?

Steve Kargl sgk at troutmask.apl.washington.edu wrote on Sun Feb 10 03:32:37 UTC 2019 : > Anyone have any pointers on building x11-toolkits/qt5-gui on > FreeBSD-current? My attempts end with > > . . . > > .obj/qimage.o: In function `QImage::fill(unsigned int)': > qimage.cpp:(.text+0x2442):

multimedia/gstreamer1-libav fails for cc being clang on powerpc64: cc: error: unknown argument: '-mminimal-toc'

[I sometimes experiment with using more modern compiler toolchains on powerpc families.] The following is from a poudriere-devel use but I extracted the tar of the failure in order to see the config.log file's messages about the failure. configure:4019: checking whether the C compiler works

Re: llvm60 required by ???

> Is there anything other than mesa-dri that requires this port? https://www.freshports.org/devel/llvm60/ shows: This port is required by: for Build • devel/cpp2py • devel/cquery • devel/creduce • devel/flang • devel/flang-clang •

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_shmd_ds too small vs. arm native's shmid_ds

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

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-*-static struct target_msgbuf is greatly mismatched with /usr/include/sys/msgbuf.h 's struct msgbuf

[The context here is FreeBSD head -r341836 based and ports head -r488859 based.] /usr/include/sys/msgbuf.h has: struct msgbuf { char *msg_ptr;/* pointer to buffer */ #define MSG_MAGIC 0x063062 u_int msg_magic; u_int msg_size;

qemu-arm-static has target_prpsinfo missing pr_pid field so target_prpsinfo is too small

[The context here is FreeBSD head -r341836 based and ports head -r488859 based.] Note: I assume that "struct target_prpsinfo" is meant to match the memory layout of the target's native "struct prpsinfo". Otherwise the reported differences below could be irrelevant. Note: struct target_prpsinfo

qemu-arm-static has target_sigframe missing sf_fvp field so target_sigframe is too small

[The context here is FreeBSD head -r341836 based and ports head -r488859 based.] Note: I assume that "struct target_sigframe" is meant to match the memory layout of the target's native "struct sigframe". Otherwise the reported differences below could be irrelevant. For armv7 (and likely armv6)

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

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

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

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

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

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

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-30, at 21:01, Jonathan Chen wrote: > On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports > wrote: >> >> [Removing __packed did make the size and offsets match armv7 >> and the build worked based on the reconstructed qemu-arm-static.] > > Than

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

[Removing __packed did make the size and offsets match armv7 and the build worked based on the reconstructed qemu-arm-static.] On 2018-Dec-30, at 16:38, Mark Millard wrote: > On 2018-Dec-28, at 12:12, Mark Millard wrote: > >> On 2018-Dec-28, at 05:13, Michal Meloun wrote: >> >>> Mark, >>>

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)

[Using ktrace/kdump shows an apperent oddity in the kevent use that hang-up in cmake, not that I know it causes the hang-up.] On 2018-Dec-28, at 00:16, Mark Millard wrote: > [The historical notes are removed and replaced by partial trace > information from example hang-ups, not that I've

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

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

[The historical notes are removed and replaced by partial trace information from example hang-ups, not that I've figured out what contributes yet.] I ran into the following while trying to get evidence about the hang-up for an amd64->armv7 cross-build of multimedia/gstreamer1-qt@qt5 . The

qemu-user-static: Unknown syscall 545 (i.e., ppoll)

In trying to gain evidence for a amd64->armv{7,6} ports cross-build hangup I enabled do_strace in qemu-arm-static . One thing that I ran into is notices of: Unknown syscall 545 sys/sys/syscall.h lists: #define SYS_ppoll 545 The man pages report that ppoll was added in FreeBSD 11. 10.x

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

[A native poudreire-devel based build of multimedia/gstreamer1-qt@qt5 did not hang-up and worked fine. Official package build history also provides some evidence.] On 2018-Dec-22, at 12:55, Mark Millard wrote: > [I found my E-mail records reporting successful builds using > qemu-user-static

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

[I built a FreeBSD head -r340288 context and tried ports head -r484783 and the problem repeated.] On 2018-Dec-22, at 12:55, Mark Millard wrote: > [I found my E-mail records reporting successful builds using > qemu-user-static from ports head -r484783 under FreeBSD > head -r340287.] > > On

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

[I found my E-mail records reporting successful builds using qemu-user-static from ports head -r484783 under FreeBSD head -r340287.] On 2018-Dec-22, at 00:10, Mark Millard wrote: > [I messed up the freebsd-emulation email address the first time I sent > this. I also forgot to indicate the

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

[I messed up the freebsd-emulation email address the first time I sent this. I also forgot to indicate the qemu-user-static vintage relationship.] I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port cross builds in another message sequence. But it turns out that one

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

I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port cross builds in another message sequence. But it turns out that one thing I ran into has hung-up every time, the same way, for amd64->armv7 cross builds: multimedia/gstreamer1-qt@qt5 . So I extract the material here

poudriere-devel -w tar files are sometimes empty for failure (no contained files): an amd64->armv7 cross build example

FYI: This is based on FreeBSD head -r341836 and ports head -r484783 and was an amd64->armv7 cross build of the port(s) using amd64-native tools. For the following failure: . . . -- Build files have been written to: /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build

Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

[A amd64->armv7 cross build shows interesting hang-up behavior as well, apparently highly repeatable for my current context.] On 2018-Dec-19, at 16:21, Mark Millard wrote: > [I attached to the hung-up process with gdb and looked around a little.] > > On 2018-Dec-19, at 13:58, Mark Millard

Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

[I attached to the hung-up process with gdb and looked around a little.] On 2018-Dec-19, at 13:58, Mark Millard wrote: > [Looks like a race or some such for devel/qt5-testlib: retry of > poudreire-devel > did not hang. The other hang-up seems to be repeating and I give some > details.] > >

Re: FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

[Looks like a race or some such for devel/qt5-testlib: retry of poudreire-devel did not hang. The other hang-up seems to be repeating and I give some details.] On 2018-Dec-19, at 12:20, Mark Millard wrote: > FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . > This >

FreeBSD head -r341836 amd64->aarch64 cross-build of -r484783 ports via poudriere: devel/qt5-testlib hung-up during "Checking for POSIX monotonic clock"

FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 . This was a rebuild based on going from perl5.26 to perl5.28 without updating the ports tree and from system clang 6 for the prior FreeBSD-head context used to clang 7 this time. (I'm not attributing causes here.) poudriere

Re: Massive PORTREVSION bump for gcc8

Kevin Oberman rkoberman at gmail.com wrote on Fri Dec 14 06:36:51 UTC 2018 : > On Thu, Dec 13, 2018 at 1:36 AM Mathieu Arnold wrote: > > > On Wed, Dec 12, 2018 at 10:29:59AM -0800, Kevin Oberman wrote: > > > This morning the PORTREVISION on at least hundreds of ports was bumped > > > because

Re: head -r340287 based powerpc64: multimedia/ffmpeg -r484273 gets a system-clang assert failure [reduced to 15 program]

[I isolated the compiler crash down to a 20 line program that makes the assert fail.] On 2018-Nov-22, at 13:03, Mark Millard wrote: > During a (native) poudriere-devel run I got the following failure. > [Unfortunately clang and poudriere are mismatched for where the > preprocessed source(s) and

head -r340287 based powerpc64: multimedia/ffmpeg -r484273 gets a system-clang assert failure

During a (native) poudriere-devel run I got the following failure. [Unfortunately clang and poudriere are mismatched for where the preprocessed source(s) and run script(s) are placed as far as what is in the poudriere tar archive produced. But I did have kern.corefile set so that the core file was

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

[The update to lld/trunk/ELF/Arch/ARM.cpp will not fix what we have run into.] On 2018-Nov-16, at 19:35, Mark Millard wrote: > 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

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

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

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

[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

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

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

[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

[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

[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

[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

[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

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

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

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

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

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

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

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 |

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

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

[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

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

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

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

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

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

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

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

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

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

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

<    1   2   3   4   >