net-im/libsignal: fix build on powerpc64*
ring-sys 5.0.2] /wrkdirs/usr/ports/net-im/libsignal/work/target/release/build/boring-sys-ef33d39251a122cc/out/boringssl/crypto/fipsmodule/../internal.h:230:2: error: "Must define either OPENSSL_32_BIT or OPENSSL_64_BIT"
devel/perfetto: fix build on powerpc*
Currently build requires the target architecture to be
Android-supported. That doesn't make sense, since the tools
this port builds are to run on the target system, not Android.
devel/cbmc: fix build on powerpc64*
1. powerpc64 always uses 64-bit long double.
2. powerpc64le before 16.0 uses 64-bit long double and switched to
128-bit IEEE long double in 16.0.
devel/objfw: fix build on powerpc64*
Taking the address of _objc_taggedPointerClasses with
addis %r6, %r2, _objc_taggedPointerClasses at toc@ha
addi %r6, %r6, _objc_taggedPointerClasses at toc@l
emits an R_PPC64_TOC16_LO relocation against the symbol itself, which
requires the symbol to be non-preemptible and reachable relative to the
TOC pointer. Neither holds for a global symbol in a shared library, so
linking libobjfwrt.so fails on FreeBSD/powerpc64le:
ld: error: relocation R_PPC64_TOC16_LO cannot be used against symbol
'_objc_taggedPointerClasses'; recompile with -fPIC
>>> defined in tagged-pointer.lib.o
>>> referenced by lookup-asm.lib.o:(objc_msg_lookup) in archive
lookup-asm/lookup-asm.lib.a
The "recompile with -fPIC" hint is misleading: every object is already
[14 lines not shown]
science/siesta: don't set -march=native
On powerpc64le:
gfortran14: error: unrecognized command-line option '-march=native'; did you mean '-mcpu=native'?
net-p2p/amule: fix build on 32-bit platforms properly
The port asks for libatomic on 32 bit platforms. That's a gcc thing.
We don't compile with gcc, so libatomic is not needed in any case.
Patch out the check for libatomic to fix the build on all 32-bit
platforms.
Approved by: portmgr (build fix blanket)
MFH: 2026Q3
(cherry picked from commit b700cbd3a83de54d284f95fb5f6db0b241c0b1da)
sysutils/czkawka: fix build on armv7
Not enough address space for LTO on armv7.
Approved by: portmgr (build fix blanket)
MFH: 2026Q3
(cherry picked from commit a57f15aa583798a3682e53258e0141baf6a63d8e)
irc/halloy: fix build on armv7
The usual issue of time_t being 64 bits on armv7 despite it being a
32 bit platform. Refactor the time conversion code to just use i64
throughout, avoiding any type conversion issues.
Approved by: portmgr (build fix blanket)
See also: 0c9905d54dedcf8763df802a01beb2ea3d4ac4a0
MFH: 2026Q3
(cherry picked from commit 0075dbc93fe05ae068fbabaed8d356622b391f56)
misc/claude-code-legacy: fix build on armv7
This is the same issue as in 0c9905d54dedcf8763df802a01beb2ea3d4ac4a0,
but for some reason cargo complains about a checksum error if I patch
it. Work around the error for now by disabling the AUDIO_CAPTURE
option on arm, without which this problem does not occur.
Maintainer should strongly consider unbundling the rust bits so that
they use the conventional rust support instead of hand-rolling a poorly
conceived solution.
See also: 0c9905d54dedcf8763df802a01beb2ea3d4ac4a0
MFH: 2026Q3
Approved by: portmgr (build fix blanket)
(cherry picked from commit cb13c34eb2244f54519722d66dc3b639936b2934)
net/rtpproxy: update to 3.1.1
- unbundle libucl, xxhash properly
- remove maintainer (timed out)
libexecinfo cannot be unbundled as the port requires internal headers
we do not install.
With thanks to sobomax and joshruehlig at gmail.com for providing earlier
versions of this patch.
Reported by: p5B2EA84B3 at t-online.de
Approved by: farrokhi (maintainer timeout, >1 month)
PR: 283019
cad/freecad: fix broken patch
This fixes the build on armv7.
Seems like an oversight during patch merging.
Please make sure this stuff is build-tested properly.
The other fix addresses an ambiguous overload on 32-bit platforms
where size_t is unsigned int, not unsigned long.
Approved by: portmgr (build fix blanket)
MFH: 2026Q3
Fixes: 02a0f04f8c5bd62c66bb7618728b1fa247805594
net-p2p/amule: fix build on 32-bit platforms properly
The port asks for libatomic on 32 bit platforms. That's a gcc thing.
We don't compile with gcc, so libatomic is not needed in any case.
Patch out the check for libatomic to fix the build on all 32-bit
platforms.
Approved by: portmgr (build fix blanket)
MFH: 2026Q3
irc/halloy: fix build on armv7
The usual issue of time_t being 64 bits on armv7 despite it being a
32 bit platform. Refactor the time conversion code to just use i64
throughout, avoiding any type conversion issues.
Approved by: portmgr (build fix blanket)
See also: 0c9905d54dedcf8763df802a01beb2ea3d4ac4a0
MFH: 2026Q3
misc/claude-code-legacy: fix build on armv7
This is the same issue as in 0c9905d54dedcf8763df802a01beb2ea3d4ac4a0,
but for some reason cargo complains about a checksum error if I patch
it. Work around the error for now by disabling the AUDIO_CAPTURE
option on arm, without which this problem does not occur.
Maintainer should strongly consider unbundling the rust bits so that
they use the conventional rust support instead of hand-rolling a poorly
conceived solution.
See also: 0c9905d54dedcf8763df802a01beb2ea3d4ac4a0
MFH: 2026Q3
Approved by: portmgr (build fix blanket)
