Re: Allow clang++ to work on OpenBSD

Date: Thu, 17 Nov 2011 19:06:24 +0100 From: Pascal Stumpf pascal.stu...@cubes.de Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any

Re: Allow clang++ to work on OpenBSD

Date: Wed, 23 Nov 2011 17:06:40 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Wed, 23 Nov 2011 17:00:57 +0100 (CET), Mark Kettenis wrote: Date: Thu, 17 Nov 2011 19:06:24 +0100 From: Pascal Stumpf pascal.stu...@cubes.de Hi, this diff was already suggested by matthew

Re: Allow clang++ to work on OpenBSD

Date: Sun, 11 Dec 2011 13:37:29 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Thu, 17 Nov 2011 19:06:24 +0100, Pascal Stumpf wrote: Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see:

Re: Allow clang++ to work on OpenBSD

Date: Sun, 11 Dec 2011 19:18:40 +0100 From: Pascal Stumpf pascal.stu...@cubes.de I still think this should be investigated deeper. Matthew did a bit of digging jusdging from: http://marc.info/?l=openbsd-portsm=129783295016631w=2 That raises the question what difference

Re: Allow clang++ to work on OpenBSD

Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict

Re: Allow clang++ to work on OpenBSD

Date: Wed, 14 Dec 2011 20:54:05 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 17:06:19 +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote: Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de

bison 2.1 needs GNU m4 at runtime too

And fails without giving a warning if /usr/local/bin/gm4 isn't there. If I force it to use our in-tree m4 I get: M4sugar requires GNU M4. Install it before installing M4sugar or set the M4 environment variable to its absolute file name. The attached patch adds the RUN_DEPENDS. Mark

Openoffice packages broken?

Looks like there are some files that are both in the openoffice package and the open-i18n-nl package. # pkg_add openoffice-i18n-nl Collision: the following files already exist /usr/local/openoffice.org/basis3.2/share/template/wizard/letter/nl/bus-elegant_l.ott (openoffice-3.2.0p0)

Re: Openoffice packages broken?

Date: Sat, 17 Apr 2010 14:40:46 +0200 From: Matthias Kilian k...@outback.escape.de On Sat, Apr 17, 2010 at 02:01:43PM +0200, Mark Kettenis wrote: Looks like there are some files that are both in the openoffice package and the open-i18n-nl package. # pkg_add openoffice-i18n-nl

Re: inteldrm suspend/resume regression (Was: Suspend/resume in Gnome)

Date: Fri, 7 Mar 2014 11:35:07 +0100 From: Gregor Best g...@ring0.de On Fri, Mar 07, 2014 at 10:51:50AM +0100, Landry Breuil wrote: [...] To everyone experiencing this issue, can you try with this diff: [...] Seems to work. I get consistent ~60 FPS with glxgears during

Re: inteldrm suspend/resume regression (Was: Suspend/resume in Gnome)

From: Theo de Raadt dera...@cvs.openbsd.org Date: Fri, 07 Mar 2014 09:15:20 -0700 On Fri, Mar 07, 2014 at 10:51:50AM +0100, Landry Breuil wrote: [...] To everyone experiencing this issue, can you try with this diff: [...] Seems to work. I get consistent ~60 FPS with glxgears

Re: inteldrm suspend/resume regression (Was: Suspend/resume in Gnome)

From: Theo de Raadt dera...@cvs.openbsd.org Date: Fri, 07 Mar 2014 10:00:41 -0700 My hopethesis about what's causing the problem here is that during the DVACT_WAKEUP phase, some drivers actually sleep and that userland processes actually get to run. Yes, that is my theory too, about

x265 diff

Already sent this to Brad, who is listed as maintainer, but I guess somebody else needs to give me an ok on this. Following diff is needed to call functions in libc the proper way for PIE. Fixes building this port with binutils 2.17. ok? Index: patches/patch-source_test_checkasm-a_asm

Re: qt4 / webkit amd64 fix

Date: Wed, 13 May 2015 13:44:55 +0200 From: Marc Espie es...@nerim.net On Wed, May 13, 2015 at 01:19:40PM +0200, Mark Kettenis wrote: This is needed to make qt4 build with binutils 2.17, and fix a potential runtime issue even when compiled with 2.15. Some of the other ports that embed

qt4 / webkit amd64 fix

This is needed to make qt4 build with binutils 2.17, and fix a potential runtime issue even when compiled with 2.15. Some of the other ports that embed webkit code might need similar treatment. I suppose this needs a REVISION bump, but I'm not sure how to do that properly given that

devel/bison

This one is tricky. The bison skeleton code uses malloc(3) and free(3), and tries to make sure a prototype for those functions is in scope. It attempts to detect if stdlib.h has been included, and if not, provides its own prototypes. The detection code checks if _STDLIB_H has been defined.

mail/cyrus-imapd

Tries to link /usr/local/lib/libcom_err.a into shared library. The static library isn't PIC, so that fails. We actually do have shared libcom_err. However, this is not picked up by the configure script because using the --with-com_err configure option forces the use of the static library.

java/tanukiwrapper

Make sure object files linked into a shared library get compiled with -fPIC. Matches what is done on Linux. ok? Index: Makefile === RCS file: /cvs/ports/java/tanukiwrapper/Makefile,v retrieving revision 1.3 diff -u -p -r1.3

binutils 2.17 issues

Hi Folks, robert@ has been so kind to do a bulk build with binutils 2.17 on amd64, sent me a list of ports that failed to build and gave me access to the build logs. I've analyzed most of these now. I'm looking into the harder ones myself, but below is a list of ports with trivial issues.

Re: devel/bison

From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Mon, 18 May 2015 13:26:08 +0200 Mark Kettenis mark.kette...@xs4all.nl writes: This one is tricky. The bison skeleton code uses malloc(3) and free(3), and tries to make sure a prototype for those functions

devel/mozjs

JeagerTrampoline is referenced from C code where it is considered to be hidden and therefore local. But the inline assembly doesn't declare it as such. This results in an X86_64_PC32 relocation, which binutils 2.17 complains about. This is probably a bug in our GCC, but it's a bit of a corner

Re: devel/bison

From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Mon, 18 May 2015 18:47:34 +0200 Mark Kettenis mark.kette...@xs4all.nl writes: From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Mon, 18 May 2015 13:26:08 +0200 Mark

Re: binutils, net/wireshark, as-needed

Date: Mon, 18 May 2015 10:42:39 +0100 From: Stuart Henderson st...@openbsd.org wireshark's configure script checks for lua to enable/disable some features, however this check now fails: configure:34222: checking for luaL_openlibs in -llua5.2 configure:34247: cc -o conftest -O2 -pipe

devel/luaprofiler

Use $CC to link shared library to make sure crtbeginS.o gets linked in. Index: Makefile === RCS file: /cvs/ports/devel/luaprofiler/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile30 May 2013 17:03:59

net/isc-bind

Use $CC to link shared library to make sure crtbeginS.o gets linked in. Guess the configure.in patch isn't really needed, but good for completeness. What's the policy here? Anybody within the ports team regularly pushing stuff upstream for bind? ok? Index: Makefile

Re: binutils 2.17 issues

Date: Fri, 22 May 2015 09:59:08 +0200 From: Antoine Jacoutot ajacou...@bsdfrog.org On Mon, May 18, 2015 at 05:19:38PM +0200, Mark Kettenis wrote: Hi Folks, robert@ has been so kind to do a bulk build with binutils 2.17 on amd64, sent me a list of ports that failed to build and gave

Re: binutils 2.17 issues

Date: Fri, 22 May 2015 10:20:38 +0200 From: Antoine Jacoutot ajacou...@bsdfrog.org Seems luarexlib needs the same kind of love. Yeah. I sent out a diff for that a week ago or so, but nobody bothered to ok it. Ah sorry I missed it. I'll look at it. Hmm, I just grep'd for

Re: binutils 2.17 issues (ADMfzap, swh-plugins, valgrind)

From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Thu, 21 May 2015 13:20:39 +0200 x11/pinot Fixed recently, but depends on graphics/exiv2 which is broken too. Are you already looking at it? That should be fixed by my last gcc and/or binutils commit.

Re: thunderbird segfault: mmap W^X violation

> Date: Sun, 7 Aug 2016 15:10:48 +0200 > From: Martin Natano > > On Sun, Aug 07, 2016 at 01:43:08PM +0200, Peter N. M. Hansteen wrote: > > > > /var/log/messages reports > > > > Aug 7 13:34:27 elke /bsd: thunderbird(10425): mmap W^X violation > > You will need the

Re: OpenBSD install busticated 'cuz ftp.openbsd.org

> Date: Sat, 8 Oct 2016 13:28:49 -0600 > From: Bob Beck > > Looks like ports moved a file "GeoIPLiteCity" to be named > "GeoIPCity" and broke everything when I updated packages on the box. > Once I found it and renamed what it was asking for, it works again. Thanks Bob.

Re: vmm "firmware" diff

> Date: Sat, 25 Mar 2017 15:40:01 +0100 (CET) > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > Date: Fri, 24 Mar 2017 20:34:37 +0100 (CET) > > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > > So here is my suggested change to solve the

Fix file descriptor leak in swig

Ran into this when trying to build subversion with the default ulimit -n of 128. ok? Index: devel/swig/Makefile === RCS file: /cvs/ports/devel/swig/Makefile,v retrieving revision 1.60 diff -u -p -r1.60 Makefile ---

Re: Fix file descriptor leak in swig

> Date: Mon, 10 Apr 2017 11:56:29 +0100 > From: Stuart Henderson <s...@spacehopper.org> > > On 2017/04/09 23:56, Mark Kettenis wrote: > > Ran into this when trying to build subversion with the default ulimit > > -n of 128. > > btw, the quickest way to build

ARM Trusted Firmware for RK3399

Here is a port for ARM Trusted Firmware 1.4 that builds firmware for the Rockchip RK3399. I anticipate that this port will build firmware for other ARMv8 Rockchip SoCs as well; there is code for the RK3328 and RK3368 in the tree as well. So this installs the firmware as rk3399-bl31.elf instead

Re: ARM Trusted Firmware for RK3399

> Date: Sun, 20 Aug 2017 13:44:57 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Sat, Aug 19, 2017 at 05:46:18PM +0200, Mark Kettenis wrote: > > Here is a port for ARM Trusted Firmware 1.4 that builds firmware for > > the Rockchip RK3399. I anticipate that

Re: UPDATE sysutils/dtb to linux 4.11

> Date: Mon, 1 May 2017 23:09:44 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Mon, May 01, 2017 at 02:37:14PM +0200, Mark Kettenis wrote: > > > Date: Mon, 1 May 2017 22:26:09 +1000 > > > From: Jonathan Gray <j...@jsg.id.au> > > > >

Re: UPDATE sysutils/dtb to linux 4.11

> Date: Mon, 1 May 2017 23:09:44 +1000 > From: Jonathan Gray <j...@jsg.id.au> > > On Mon, May 01, 2017 at 02:37:14PM +0200, Mark Kettenis wrote: > > > Date: Mon, 1 May 2017 22:26:09 +1000 > > > From: Jonathan Gray <j...@jsg.id.au> > > > >

Re: UPDATE sysutils/dtb to linux 4.11

> Date: Mon, 1 May 2017 22:26:09 +1000 > From: Jonathan Gray > > Update dtb to linux 4.11. > > This also switches from the gcc4 module to clang. Base gcc can't be > used as gcc 4.2 cpp can't handle whitespace between '#' and 'include'. > > This update changes pinctrl nodes in

Re: ARM Trusted Firmware for RK3399

> Date: Tue, 22 Aug 2017 12:30:46 +0100 > From: Stuart Henderson <s...@spacehopper.org> > > On 2017/08/20 23:47, Mark Kettenis wrote: > > > "arm-trusted-firmware" would match the repository name and seems a > > > better fit. Maybe expand the DESCR oth

arm64 gcc-linaro build fix

Diff below fixes the build on arm64. Pretty much the same change that was also made for arm. No version bump since the port didn't build before right? ok? Index: devel/arm-none-eabi/gcc-linaro/patches/patch-gcc_config_host ===

Fix webkitgtk4 on arm64

Diff below makes it build on arm64. Not sure of it actually works. ok? Index: www/webkitgtk4/patches/patch-Source_JavaScriptCore_offlineasm_arm64_rb === RCS file:

Fix reading coredumps on armv7 with ports gdb

Diff below makes reading core dumps work again. ok? Index: devel/gdb/Makefile === RCS file: /cvs/ports/devel/gdb/Makefile,v retrieving revision 1.53 diff -u -p -r1.53 Makefile --- devel/gdb/Makefile 24 Jan 2018 00:19:56 -

Re: gtk libool slow on arm

> From: > Date: Tue, 1 May 2018 16:30:28 -0700 > > Why is the gtk libtool so slow on arm? A typical command such as: It's not libtool, but ld, the link editor that is taking its time. > libtool: link: cc -o .libs/testentrycompletion -pthread -O2 -pipe -g -Wall >

gdb for arm64

Here is a cleaned-up version of a diff that Dale made to support OpenBSD/arm64 in gdb. Single-stepping doesn't work yet, which means that stepping through the code doesn't really work. But setting breakpoints and inspecting state or looking at core files should work. I'm not sure what to do

Re: gdb for arm64

> From: Jeremie Courreges-Anglas > Date: Tue, 10 Jul 2018 12:23:30 +0200 > > On Tue, Jul 10 2018, Mark Kettenis wrote: > > Here is a cleaned-up version of a diff that Dale made to support > > OpenBSD/arm64 in gdb. Single-stepping doesn't work yet, which means > >

Re: [armv7 fix] Build database/redis

> Date: Tue, 17 Apr 2018 21:43:17 +0200 > From: Klemens Nanni > > On Sun, Apr 15, 2018 at 06:34:21PM +0200, Markus Hennecke wrote: > > On Sat, 14 Apr 2018, Jeremie Courreges-Anglas wrote: > > > > > On Thu, Apr 12 2018, Klemens Nanni wrote: > > > > On Sat,

Re: fix net/tor configure on armv7 (-fasynchronous-unwind-tables)

> Date: Wed, 25 Apr 2018 13:48:12 +0200 > From: Stefan Sperling > > tor's configure script is failing on armv7: > > checking size of short... (cached) 2 > checking size of int... configure: error: in > `/usr/ports/pobj/tor-0.3.2.10/tor-0.3.2.10': > configure: error: cannot

fpc lld issue

lang/fpcinvalid alignment of section headers https://bugs.freepascal.org/view.php?id=32900

Fix luajit

>From naddy@'s lld ports failure list: benchmarks/wrk string table non-null terminated This is caused by an off-by-one in luajit that has been fixed upstream. https://repo.or.cz/luajit-2.0.git/commitdiff/7dbf0b05f1228c1c719866db5e5f3d58f87f74c8 Apparently ld.lld checks the validity of

Re: update sysutils/arm-trusted-firmware to 1.6

> Date: Sun, 21 Oct 2018 11:24:01 +1100 > From: Jonathan Gray > > On Sat, Oct 20, 2018 at 11:42:56PM +0200, Mark Kettenis wrote: > > > Date: Sun, 23 Sep 2018 23:15:44 +1000 > > > From: Jonathan Gray > > > > > > Update to 1.6 and build

Re: update sysutils/arm-trusted-firmware to 1.6

> Date: Sun, 23 Sep 2018 23:15:44 +1000 > From: Jonathan Gray > > Update to 1.6 and build the newly added a64/h5 platform support that can > hopefully replace the atf-allwinner port. > > Only compile tested for lack of hardware. FWIW, I've now also tested rk3399. So I think you should go

Re: update sysutils/arm-trusted-firmware to 1.6

> Date: Sun, 23 Sep 2018 23:15:44 +1000 > From: Jonathan Gray > > Update to 1.6 and build the newly added a64/h5 platform support that can > hopefully replace the atf-allwinner port. > > Only compile tested for lack of hardware. Works fine on my NanoPi A64. Used the diff below to pick up the

Re: sparc64 C++ exception fix for gcc8

> Date: Tue, 12 Feb 2019 18:24:32 +0100 > From: Otto Moerbeek > > On Fri, Feb 08, 2019 at 09:07:23PM +0100, Otto Moerbeek wrote: > > > Hi, > > > > This fixes regresss/misc/exceptions on sparc64 > > > > OK? > > ping... This looks good to me. ok kettenis@ > > Index: Makefile > >

Re: gcc 4.9 C++ sparc64 exception handling

> Date: Tue, 5 Feb 2019 08:39:21 +0100 > From: Otto Moerbeek > > On Sat, Feb 02, 2019 at 02:24:20PM +0100, Otto Moerbeek wrote: > > > Hi, > > > > this fixes exception handling when using eg++ on sparc64. Since stack > > frames are non-standard on OpenBSD/sparc64 because of stackghost, we > >

Re: Various rockchip u-boot aarch64 improvements

gt; > > > > > > > On Sun, Oct 06, 2019 at 09:51:20PM -0400, Kurt Miller wrote: > > > > > > > > > > > > > > > On Sun, 2019-10-06 at 18:47 +0200, Mark Kettenis wrote: > > > > > > > > > >

Re: Various rockchip u-boot aarch64 improvements

> Date: Sun, 6 Oct 2019 11:42:03 +1100 > From: Jonathan Gray > > On Sat, Oct 05, 2019 at 12:20:57PM -0400, k...@intricatesoftware.com wrote: > > Various rockchip u-boot 2019.10rc4 aarch64 improvements: > > * u-boot.itb is included in the all target for rockpro64 and > > firefly-rk3399 so

Re: update sysutils/dtb to linux 5.6

> Date: Sat, 11 Apr 2020 11:09:19 +1000 > From: Jonathan Gray > > Update dtb to the latest linux release now we can handle newer omap > dtbs. Go for it. I may have some further tweaks once this is in. ok kettenis@ > Index: Makefile >

Improve powerpc64 support in gdb

This allows running programs under gdb. ok? Index: devel/gdb/Makefile === RCS file: /cvs/ports/devel/gdb/Makefile,v retrieving revision 1.67 diff -u -p -r1.67 Makefile --- devel/gdb/Makefile 3 Jul 2020 21:12:38 - 1.67

gdb powerpc64 support

This adds basic powerpc64 support to the ports gdb. Only really implements target support, so this can only really look at core dumps. But it does a better job than base gdb. Since the ports tree is still locked, I may actually work on improving this a bit. But at least people have the diff if

Re: mail/rspamd and luajit (was: Re: amd64 bulk build failures 2020-08-07)

> From: Jeremie Courreges-Anglas > Date: Sun, 09 Aug 2020 12:23:05 +0200 > > > mail/rspamd > > http://build-failures.rhaalovely.net/amd64/2020-08-07/mail/rspamd.log > > --8<-- > ld: error: /usr/local/lib/libluajit-5.1.so.1.0: undefined reference to > _Unwind_DeleteException > ld: error:

Re: i386/LLVM 10

> From: Jeremie Courreges-Anglas > Date: Thu, 13 Aug 2020 11:54:53 +0200 > > On Wed, Aug 12 2020, Christian Weisgerber wrote: > > On 2020-08-10, Stuart Henderson wrote: > > > >> x11/qt4 > >> > >> ld: error: relocation R_386_PC32 cannot be used against symbol > >> cti_vm_throw; recompile with

Re: update arm-trusted-firmware to 2.4

> From: Kurt Miller > Date: Tue, 12 Jan 2021 10:12:06 -0500 > > I tested this with rock64-rk3328 rev c and rockpro64-rk3399 with > atf 2.4. rock64 is good, but the rockpro64 still needs the patch > to disable the preboot command.  > > When 'usb start' is issued on the rockpro64 the kernel

ports gcc for powerpc64

I successfully built cad/magic with this. ok? Index: lang/gcc/8/Makefile === RCS file: /cvs/ports/lang/gcc/8/Makefile,v retrieving revision 1.36 diff -u -p -r1.36 Makefile --- lang/gcc/8/Makefile 14 Nov 2020 00:00:39 -

Update arm-none-eabi binutils to 2.31.1

U-Boot targets that use the CONFIG_POSITION_INDEPENDENT and CONFIG_LINUX_KERNEL_IMAGE_HEADER options don't build because they generate a relocation that binutils 2.30 doesn't like. This is fixed in binutils 2.31. Given that there is a 2.31.1 I updated to that one. ok? Index:

Re: ports/devel/gdb update with riscv support

> Date: Fri, 17 Sep 2021 13:58:46 +0200 (CEST) > From: Mark Kettenis > > > From: Jeremie Courreges-Anglas > > Date: Fri, 17 Sep 2021 13:43:19 +0200 > > > > On Fri, Sep 17 2021, Mark Kettenis wrote: > > >> From: Jeremie Courreges-Anglas

Re: ports/devel/gdb update with riscv support

> From: Jeremie Courreges-Anglas > Date: Fri, 17 Sep 2021 13:43:19 +0200 > > On Fri, Sep 17 2021, Mark Kettenis wrote: > >> From: Jeremie Courreges-Anglas > >> Date: Fri, 17 Sep 2021 13:23:58 +0200 > >> > >> On Sat, Sep 04 2021, Jeremie Cou

Re: new: lang/polyml

> Date: Sun, 09 Jan 2022 23:54:23 +0100 > From: Leo Larnack > > Daniel Dickman wrote: > > > elfexport.cpp:352:56: error: use of undeclared identifier 'R_386_32' > > reloc.r_info = ELFXX_R_INFO(symbolNum, isFuncPtr ? > > HOST_DIRECT_FPTR_RELOC : HOST_DIRECT_DATA_RELOC); > >

Re: Power-up cc --print-file-name for .so names

> From: Greg Steuck > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > To give a sense of the kind of change required to get the feature I > want, see the patch at the end. The change in DriverUtils.cpp is just to > show that the same function is hiding in there. > > If this looks like a good

Re: Power-up cc --print-file-name for .so names

> From: "Theo de Raadt" > Date: Mon, 14 Feb 2022 00:34:53 -0700 > > > The solution would be to add symlinks like all the other OSes do. But > > Theo doesn't like that. > > No, the problem is you add symbolic links, how long before software > ecosystems in ports choose the short names in

Re: Power-up cc --print-file-name for .so names

> From: Philip Guenther > Date: Sun, 13 Feb 2022 23:29:06 -0800 > > On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis > wrote: > > > From: Greg Steuck > > Date: Sun, 13 Feb 2022 22:37:13 -0800 > > > > To give a sense of the kind of change re

Re: enable -fstack-clash-protection in llvm ports

> From: Theo de Raadt > Date: Thu, 14 Sep 2023 01:02:14 -0600 (MDT) > > I do not think this should be enabled. > Our stacks work differently. > We don't put shit near the bottom of the main stack, because we > reserve the space. > For pthread stacks, we allocate them randomly also so you cannot

Clean up sysutils/u-boot a bit

Back when I split up the port, Stuart suggested to see if some simplification of the do-build rule would be possible. I think the most sensible thing to do is to move this from Makefile.inc into the per-directory Makefile. There is a tiny bit of duplication, but I think the result is more

BTI fix ruby 3.2.2

The configure scripts adds -mbranch-protection=pac-ret, which on OpenBSD actually *downgrades* the protection and makes things fail on arm64 systems that implement BTI. Use -mbranch-protection=standard instead. ok? Index: lang/ruby/3.2/Makefile

Enable LTO for arm/aarch64 cross-compiler

Newer U-Boot versions have started to require LTO in order to save some space for certain targets. I don't see a downside in enabling it as the cross compiler won't be used to build OpenBSD binaries. ok? Index: devel/arm-none-eabi/gcc/Makefile

U-Boot for RK356x SoCs

So here is the start of a port for a few RK3566 and RK3568 boards. These boards currently need some binary blobs to run. And a LICENSE file was added to the relevant repository that explicitly allows redistribution of these blobs. The default baudrate for the serial console is embedded in one of

U-Boot for RK356x SoCs (take 2)

Now that U-Boot 2023.10 has been release, here is an update. This adds a few more boards and now uses a script that U-Boot provides to switch the serial console baudrate to 115200. This way I don't need to patch the configs anymore. ok? Index: sysutils/u-boot/rk356x/Makefile

Re: m1n1: update to 1.4.3

> Date: Mon, 23 Oct 2023 20:38:33 +0200 > From: Tobias Heider > > As the title says. We need a small patch to remove an unnecessary > bash dependency, I opened an upstream PR for that. > Once this is in I will also update apple-firmware. ok kettenis@ > Index: Makefile >

Re: sysutils/u-boot-asahi

> Date: Mon, 24 Oct 2022 23:15:04 +0200 > From: Tobias Heider > > u-boot-asahi is the Asahi Linux version of the u-boot bootloader that works > on Apple Silicon Arm hardware. > > We need this package to update the bootloader chain on these devices from > OpenBSD and to distribute newer device

Re: [NEW] sysutils/m1n1

> Date: Mon, 24 Oct 2022 22:54:33 +0200 > From: Tobias Heider > > m1n1 is a bootloader for Apple silicon machines developed by the Asahi Linux > project. > > This is the first of several packages we need to upgrade the bootloader chain > from OpenBSD. The other missing parts are the asahi fork

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

> Date: Fri, 2 Dec 2022 18:44:27 + > From: Peter Stuge > > Jan Stary wrote: > > > > > Replacing the DTBs with those from the dtb package is not supposed to > > > > > work. > > > > Is this specific to the Raspberry, or is that true in general? > > I think this was specifically in response

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

> Date: Tue, 22 Nov 2022 14:40:06 +0100 > From: Jan Stary > > On Nov 22 13:52:52, h...@stare.cz wrote: > > On Nov 14 23:37:05, patr...@blueri.se wrote: > > > the u-boot and dtb ports haven't been updated in a while, mostly because > > > updating those regularly breaks working machines. I think

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

> Date: Fri, 18 Nov 2022 12:53:44 + > From: Klemens Nanni > > On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote: > > Hi, > > > > the u-boot and dtb ports haven't been updated in a while, mostly because > > updating those regularly breaks working machines. I think it's time for

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

> Date: Fri, 25 Nov 2022 00:52:24 + > From: Peter Stuge > > Jan Stary wrote: > > Here is the cpsw problem: > > > > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e > > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00 > > I confirm this on beaglebone black but

openssl3 arm64 assembly fixes

This fixes the arm64 perl assembly scripts to no longer emit data into .text segments. I removed the -Wl,--no-execute-only flags and ran "make test" which still reports that all tests passed. Index: security/openssl/3.0/patches/patch-crypto_aes_asm_aesv8-armx_pl

Re: openssl3 arm64 assembly fixes

> Date: Sat, 14 Jan 2023 00:24:19 +0100 > From: Theo Buehler > > On Fri, Jan 13, 2023 at 11:36:00PM +0100, Mark Kettenis wrote: > > This fixes the arm64 perl assembly scripts to no longer emit data into > > .text segments. I removed the -Wl,--no-execute-only flags and r

Re: OpenSSL 1.1 arm64 assembly fixes

> Date: Sat, 14 Jan 2023 16:56:32 +0100 > From: Theo Buehler > > This is a backport of kettenis's diff. Most of it applied with a few > offsets. I had to hand-apply two or three hunks due to whitespace noise. > > The only real changes are the hunks containing __ILP32__ which were > needed to

Re: libgcrypt: arm64 assembly fixes

> Date: Sat, 14 Jan 2023 21:08:38 +0100 > From: Theo Buehler > > This moves constants from .text into .rodata. > > All tests pass, gnupg tests work, gpgme and gcr build. Right, and then the idiots did this:

ffmpeg x-only fix

This makes all the tests pass on an amd64 machine with PKU. The trick is to put the dispatch tables in .data.rel.ro. That means we can have relocations there but that the tables become read-only after the relocations have been processed. Since the table now contains the actual addresses of the

x265 x-only fix

Found one file that had a little bit of data in .text. With this fix the tests pass. ok? Index: multimedia/x265/Makefile === RCS file: /cvs/ports/multimedia/x265/Makefile,v retrieving revision 1.54 diff -u -p -r1.54 Makefile ---

Update devel/arm-none-eabi/binutils

I'm trying to update the aarch64 cross-compile binutils port to something a bit more recent as I'm running into some issues building upstream u-boot. I picked version 2.40 since that is what we use for devel/binutils and devel/risc-elf/binutils. Diff below seems to do the trick, except that it

arm64 BTI for libnettle

So libnettle is interesting. I already has support for the x86 variant. This is done through defining some variables based on autoconf checks. We can add similar checks and defines for arm64. Maybe the names of the defines don't make sense, but that is something to discuss with upstream I

arm64 BTI for gnutls

So this on is a bit different. There is a small amount of arm64 assembly code; basically a copy of the assembly generated by openssl perlasm. The assembly functions are not exposed directly but used by C code that calls the assembly directly. So they don't need BTI instructions. We can simply

arm64 BTI for devel/gmp

Here the assembly gets generated by M4 macros. There is macro for generating CPU-specific function prologues. So provide one for arm64 that adds the required BTI instruction. ok? Index: devel/gmp/Makefile === RCS file:

Re: arm64 BTI for devel/gmp

> From: "Theo de Raadt" > Date: Fri, 21 Apr 2023 07:54:39 -0600 > > +.if ${MACHINE_ARCH:Maarch64} > +CONFIGURE_ENV+= ASMFLAGS=-mmark-bti-property > +.endif > > For some of these diffs, it might help to consider amd64 (and i386?) at > the same time. Or, all architectures. In theory this type

Re: arm64 BTI for libnettle

> Date: Sat, 22 Apr 2023 12:40:35 +0200 > From: Antoine Jacoutot > > On Thu, Apr 20, 2023 at 10:26:24PM +0200, Mark Kettenis wrote: > > So libnettle is interesting. I already has support for the x86 > > variant. This is done through defining some variables based on >

multimedia/dav1d arm64 fixes

This makes the regress test pass again on arm64 after the last two updates. Please make sure the regress passes when updating this ports. I can help with the arm64 asm if needed. Cheers, Mark P.S. Interestingly enough they missed a few BTI landing pads this time. Index:

Re: devel/gmp: update to 6.3.0, needs testing

> Date: Tue, 1 Aug 2023 21:36:41 +0200 > From: Christian Weisgerber > > Here's an update to devel/gmp 6.3.0: > * New public function mpz_prevprime. > * New documented pointer types mpz_ptr, mpz_srcptr, and similar for > other GMP types. > > I have successfully run the tests on > * amd64 with

Re: arm64 BTI support for mpg123

> Date: Tue, 25 Jul 2023 16:51:18 +0200 > From: Christian Weisgerber > > Christian Weisgerber: > > > Because amd64 should suffer from the same problem: > > > > fr->cpu_opts.the_dct36 = dct36_avx; > > ... > > fr->cpu_opts.the_dct36 = dct36_x86_64; > > >

Re: arm64 BTI support for mpg123

> From: "Theo de Raadt" > Date: Tue, 25 Jul 2023 08:23:14 -0600 > > Christian Weisgerber wrote: > > > Mark Kettenis: > > > > > This port has some infrastructure to use an optimized function that > > > uses a function pointer. Not sure w

Enable BTI by default in gcc 11

With this diff I can build the gcc 11 port on a machine that implements BTI. As far as I can tell the option has no effect on non-arm64 machines. ok? Index: lang/gcc/11/Makefile === RCS file: /cvs/ports/lang/gcc/11/Makefile,v

  1   2   3   4   >