Some personal thoughts:

Ideally this should be committed before the next quarterly for two reason, obviously to get in quarterly, and also because I'd rather commit this work I did in subversion without need to rework it through git [1].

At the same time, unless it can be made to work on 12.2 at least, it makes little sense to commit this before 13.0 is released, so the ideal window for committing this amounts to a few days at the end of March at most.

[1] this is no critique of git, in fact this activity would have been easier with git, but having done all the patching in subversion moving it to git would be extra work

I was able to build, install, run, create/run VMs with this patch on 12.2-RELEASE-p3 host. Should the ignore 12 lines be removed?

Further note:

6.1.18 additions fail to compile on i386 with a strange gmake "missing separator" error. I've been unable to fix it. Any help appreciated!

In D28871#646261, @madpilot wrote:

In D28871#646258, @dereks_lifeofadishwasher.com wrote:

I was able to build, install, run, create/run VMs with this patch on 12.2-RELEASE-p3 host. Should the ignore 12 lines be removed?

If it works yes. Tomorrow I'll test myself, but you report looks promising.

I see where there might be an issue with 12.2-RELEASE-p3 and clang.

I was building with DEBUG and it works. Rebuild with default options (DEBUG off) you get the same error reported here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878#c134 while trying to start a VM.
It seems to either be an issue with the code or the way clang (10?) is building it?

So it's possible DEBUG (for the being) might be required for 12.2?

In D28871#646359, @dereks_lifeofadishwasher.com wrote:

In D28871#646261, @madpilot wrote:

In D28871#646258, @dereks_lifeofadishwasher.com wrote:

I was able to build, install, run, create/run VMs with this patch on 12.2-RELEASE-p3 host. Should the ignore 12 lines be removed?

If it works yes. Tomorrow I'll test myself, but you report looks promising.

I see where there might be an issue with 12.2-RELEASE-p3 and clang.

I was building with DEBUG and it works. Rebuild with default options (DEBUG off) you get the same error reported here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234878#c134 while trying to start a VM.
It seems to either be an issue with the code or the way clang (10?) is building it?

Interesting finding. Ideally we should understand why this happens. Maybe forcing another compiler for 12.2 would make it work?

Also, what are you compiling with DEBUG? Only the kmod is enough or is it required for all of virtualbox-ose?

So it's possible DEBUG (for the being) might be required for 12.2?

Could be an option, but I'd like to try forcing clang 11 or some other compiler before going down that way.

Maybe negligible for review purposes:

• the application icons that appear, temporarily, whilst a guest starts are generic X.org icons.

In D28871#646424, @madpilot wrote:

Interesting finding. Ideally we should understand why this happens. Maybe forcing another compiler for 12.2 would make it work?

Yeah, finding the root cause would be best however if needed forcing gcc would be next.

Also, what are you compiling with DEBUG? Only the kmod is enough or is it required for all of virtualbox-ose?

DEBUG was only enabled on emulators/virtualbox-ose

In D28871#646671, @dereks_lifeofadishwasher.com wrote:

In D28871#646424, @madpilot wrote:

Interesting finding. Ideally we should understand why this happens. Maybe forcing another compiler for 12.2 would make it work?

Yeah, finding the root cause would be best however if needed forcing gcc would be next.

Also, what are you compiling with DEBUG? Only the kmod is enough or is it required for all of virtualbox-ose?

DEBUG was only enabled on emulators/virtualbox-ose

I tested now virtualbox 6 modified to force clang 11 from ports on 12.2 and it works fine. I think this fix is cleaner than forcing DEBUG.

I'm almost sure this would work for 11.x too, but it's difficult to test because I'd have to build a full set of ports using SSL from ports, due to the QT/OpenSSL issue. Maybe I'll test that too, anyway I'll remove the restriction on 11 along with the one on 12.

This removes the need to wait for 13.0 to be released before committing.

Updated patch set coming shortly.

In D28871#646441, @grahamperrin_gmail.com wrote:

Maybe negligible for review purposes:

• the application icons that appear, temporarily, whilst a guest starts are generic X.org icons.

Good catch, although I suspect this is due to the way virtualbox creates its windows and not much can be done. Anyway if it's only limited to aesthetics a fix can also be added at a later time.

In D28871#646753, @madpilot wrote:

I tested now virtualbox 6 modified to force clang 11 from ports on 12.2 and it works fine. I think this fix is cleaner than forcing DEBUG.

I'm almost sure this would work for 11.x too, but it's difficult to test because I'd have to build a full set of ports using SSL from ports, due to the QT/OpenSSL issue. Maybe I'll test that too, anyway I'll remove the restriction on 11 along with the one on 12.

The issue I could see with using llvm11 is that building on a fresh env you need gcc10 (kbuild), llvm10 (mesalibs), and if added llvm11 to build virtualbox-ose. That's three very large ports. If you just used gcc (assuming you can reuse gcc10) it's already there.

Is it any different you force virtualbox-ose to use lang/llvm10 vs base's? If no different then using gcc10 (or whatever kbuild uses) would require less to build.

In D28871#646774, @dereks_lifeofadishwasher.com wrote:

The issue I could see with using llvm11 is that building on a fresh env you need gcc10 (kbuild), llvm10 (mesalibs), and if added llvm11 to build virtualbox-ose. That's three very large ports. If you just used gcc (assuming you can reuse gcc10) it's already there.

Is it any different you force virtualbox-ose to use lang/llvm10 vs base's? If no different then using gcc10 (or whatever kbuild uses) would require less to build.

Yes, you make a compelling point. Honestly I did not think about it.

I need to spin a new round of tests before replying. Should not take long though, since the dependencies should all be present in the poudriere jail I used.

EDIT: At the same time I'm checking the "CHOSEN_COMPILER_TYPE" variable to know what to do...Having that on clang and then forcing gcc looks strange. Not sure if there is a way to make USES=compiler choose gcc himself but only depending on OSVERSION

I coerced it in using gcc, but it's failing with a bunch of errors like this:

-- SUPDrvSem.o ---
gcc10: error: unrecognized command-line option '-fformat-extensions'; did you mean '-fno-ms-extensions'?
*** [SUPDrvSem.o] Error code 1

First, I cannot find any documentation for the flag -fformat-extensions, I'd rather know what it does before removing it, maybe it should be replaced by some gcc specific one. Anyone has any clue?

Anyway I have no idea how to remove it, since grepping the whole virtualbox sources only returns a match in Config.kmk, but in a comment, so, right now, I have no idea where that flag is growing from. I'll keep looking.

EDIT:

https://stackoverflow.com/questions/48927926/cc-error-unknown-argument-fformat-extensions

Interesting enough, this flag used to be an extension from our own gcc "fork", unsupported in newer gcc. But I could try forcing gcc only on main virtualbox port. Could work anyway.

Forcing gcc 10 gives errors both in kmod and in main port. I'd say it's a non starter.

Main port error with gcc 10:

kBuild: Compiling iPxeBaseBin - /wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src/arch/i386/core/basemem_packet.c
gcc10: error: unrecognized command-line option '-mstack-alignment=2'
kmk: *** [/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/iPxeBaseBin/src/arch/i386/core/basemem_packet.o] Error 1
The failing command:
@gcc10 -m32 -c -O2 -fno-pie -fcommon -ffreestanding -ffunction-sections -march=i386 -fomit-frame-pointer -fstrength-reduce -falign-jumps=1 -falign-loops=1 -Os -falign-functions=1 -mstack-alignment=2 -mregparm=3 -mrtd -freg-struct-return -fshort-wchar -Ui386 -Ulinux -include compiler.h -Wall -W -Wformat-nonliteral -fno-stack-protector -fno-dwarf2-cfi-asm -Wno-address -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src/arch/x86/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src/arch/i386/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src/arch/i386/include/pcbios -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/include -I/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/out/freebsd.amd64/release -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_DEBUGGER -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/share/virtualbox-ose\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/share/doc/virtualbox-ose\" -DARCH=i386 -DPLATFORM=pcbios -DVERSION_MAJOR=1 -DVERSION_MINOR=0 -DVERSION_PATCH=0 -DVERSION=\"1.0.0+\" -D_build_id=0xaffeaffe -DOBJECT=basemem_packet -Wp,-MD,/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/iPxeBaseBin/src/arch/i386/core/basemem_packet.o.dep -Wp,-MT,/wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/iPxeBaseBin/src/arch/i386/core/basemem_packet.o -Wp,-MP -o /wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/out/freebsd.amd64/release/obj/iPxeBaseBin/src/arch/i386/core/basemem_packet.o /wrkdirs/usr/ports/emulators/virtualbox-ose-nox11/work/VirtualBox-6.1.18/src/VBox/Devices/PC/ipxe/src/arch/i386/core/basemem_packet.c

I've made a test on 12.2 using base compiler and it fails to start VMs as expected.

For me forcing clang 11 is the only solution working across the board.

I've also got a negative report forcing clang11, and one positive using base clang (also on 12.2).

At this point it's difficult for me to tell what should be done, due to the contrasting reports.

My gut feeling is that going with forcing claang11(the present patch set here) is the safest option at present.

We need to make it work and get it into the tree. Things can be improved later anyway.

As a side note there is also www/phpvirtualbox (which is also maintained by vbox@) which we will need to update to latest git (develop branch) to support vbox 6.1.

Since the VBoxNetDHCP issue that has been found in the related bug report on bugzilla looks quite nasty I'll hold this for a little while, till the week end at least, to try to fix that "wrinkle".

If that ends up too hard to fix for me I would anyway commit the update. As noted version 5 is EOL and we really need to move on. A fix can be cooked later.

In D28871#649523, @decke wrote:

As a side note there is also www/phpvirtualbox (which is also maintained by vbox@) which we will need to update to latest git (develop branch) to support vbox 6.1.

This needs also a -legacy port for the old version and an update. At present it can keep working with the legacy version.

I think we never had a legacy port for phpvirtualbox because there are not that many users and upstream is almost dead. It should be enough for now to change the dependencies to vbox-legacy. We can update it when the dust has settled.

In D28871#649595, @decke wrote:

I think we never had a legacy port for phpvirtualbox because there are not that many users and upstream is almost dead. It should be enough for now to change the dependencies to vbox-legacy. We can update it when the dust has settled.

I don't think upstream is dead. Are you looking at the right project it moved to github? https://github.com/phpvirtualbox/phpvirtualbox the develop branch supports 6.1 (https://github.com/phpvirtualbox/phpvirtualbox/issues/255) last updated ~month ago.

Maybe over the weekend I could try to get www/phpvirtualbox updated to use this branch.

phpvirtualbox was a one man show (imoore76) for a long time but when he stopped it was dead for a year or more. Now a new guy has taken it over and tries to maintain it but looking at the history tells you this is basically collecting patches to keep it working. There is no improvement or development they just try to keep it working and did not manage to do a release for two years. I'd call it dead but one could also say it's legacy or feature complete.

phpvirtualbox port does not have any dependency on the virtualbox ports. I guess it can be installed standalone, and only needs to communicate with virtualbox via sockets or other methods. So I don't think there is anything to be changed there right now.

BTW forgot to mention, yes I used "svn cp" to create the legacy ports, then adjusted the conflicts and dependencies.