I suppose it is right not to hook this into audio/Makefile since this depends on /usr/src existing.

Oh it should always be hooked into the category makefile. You can do something like this:

.if !exists(${SRC_BASE}/lib/virtual_oss/sndio)
IGNORE= virtual_oss not present in base

after including <bsd.port.pre.mk> to have the port only be available on systems where virtual_oss is in base.

Please extend pkg-descr further. The point of three lines is not to have you put in empty lines and boilerplate, but rather to have you describe what the port does in detail. Explain what the port does and why a user would want to install this port.

This gives me:

% make -C audio/virtual_oss_backend_sndio check-plist
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: lib/voss_sndio.so
Error: Orphaned: @dir lib/virtual_oss
===> Checking for items in pkg-plist which are not in STAGEDIR
Error: Missing: lib/virtual_oss/voss_sndio.so
===> Error: Plist issues found.
*** Error code 1

I guess, you need

MAKE_ENV+=	LIBDIR=${PREFIX}/lib/virtual_oss

?

christos@pleb$ make -C audio/virtual_oss_backend_sndio check-plist
===>  License BSD2CLAUSE accepted by the user
===>   virtual_oss_backend_sndio-1403000 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by virtual_oss_backend_sndio-1403000 for building
===>  Extracting for virtual_oss_backend_sndio-1403000
===>  Patching for virtual_oss_backend_sndio-1403000
===>   virtual_oss_backend_sndio-1403000 depends on shared library: libsndio.so - found (/usr/local/lib/libsndio.so)
===>  Configuring for virtual_oss_backend_sndio-1403000
===>  Building for virtual_oss_backend_sndio-1403000
[Creating objdir /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio...]
Building /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio/sndio.pico
Building /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio/voss_sndio.so
Building shared library voss_sndio.so
===>  Staging for virtual_oss_backend_sndio-1403000
/bin/mkdir -p /usr/ports/audio/virtual_oss_backend_sndio/work/stage/usr/local/lib/virtual_oss
===>   Generating temporary packing list
Building /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio/_libinstall
====> Compressing man pages (compress-man)
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
===> Checking for items in pkg-plist which are not in STAGEDIR
===> No pkg-plist issues found (check-plist)

For me setting MAKE_ENV+= LIBDIR=${PREFIX}/lib/virtual_oss breaks the build:

[Creating objdir /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio...]
Building /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio/sndio.pico
Building /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio/voss_sndio.so
Building shared library voss_sndio.so
===>  Staging for virtual_oss_backend_sndio-1403000
/bin/mkdir -p /usr/ports/audio/virtual_oss_backend_sndio/work/stage/usr/local/lib/virtual_oss
===>   Generating temporary packing list
Building /usr/ports/audio/virtual_oss_backend_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio/_libinstall
install: /usr/ports/audio/virtual_oss_backend_sndio/work/stage/usr/local/lib/virtual_oss/virtual_oss: No such file or directory
*** Error code 71

Why do you have 1403000 in the port's version? I thought the necessary base changes aren't even merged to main yet?

In D52365#1197253, @arrowd wrote:

Why do you have 1403000 in the port's version? I thought the necessary base changes aren't even merged to main yet?

They are not, this is just my dev environment, but you need to have D52308 applied in /usr/src in order for this to build.

In D52365#1197255, @christos wrote:

In D52365#1197253, @arrowd wrote:

Why do you have 1403000 in the port's version? I thought the necessary base changes aren't even merged to main yet?

They are not, this is just my dev environment, but you need to have D52308 applied in /usr/src in order for this to build.

Yes, I do have it applied, but on top of main. Which is why in my build the port's version starts with 15. Could it be that you applied D52308 onto stable/14?

In D52365#1197257, @arrowd wrote:

In D52365#1197255, @christos wrote:

In D52365#1197253, @arrowd wrote:

Why do you have 1403000 in the port's version? I thought the necessary base changes aren't even merged to main yet?

They are not, this is just my dev environment, but you need to have D52308 applied in /usr/src in order for this to build.

Yes, I do have it applied, but on top of main. Which is why in my build the port's version starts with 15. Could it be that you applied D52308 onto stable/14?

I also have it on top of main, but my machine actually runs 14.3-RELEASE.

Ah, sorry for the confusion, the OSVERSION value comes from /usr/local/include/sys/param.h. All right, I'll try to figure out why this doesn't build for me.

Your logs look less verbose than mine for some reason. For example, in my logs I do see the actual command that is used to install the library:

===>   Generating temporary packing list
install  -s -o 1001 -g 1001 -m 444  -C -S  voss_sndio.so /usr/local/poudriere/ports/default/audio/virtual_oss_backend_sndio/work/stage/usr/local/lib/

I don't have anything fancy in /etc/make.conf or /etc/src.conf, though.

Anyways, I dive into bsd.lib.mk and it clearly installs directly into LIBDIR. I have no idea how it works for you.

In D52365#1197260, @arrowd wrote:

Your logs look less verbose than mine for some reason. For example, in my logs I do see the actual command that is used to install the library:

===>   Generating temporary packing list
install  -s -o 1001 -g 1001 -m 444  -C -S  voss_sndio.so /usr/local/poudriere/ports/default/audio/virtual_oss_backend_sndio/work/stage/usr/local/lib/

I don't have anything fancy in /etc/make.conf or /etc/src.conf, though.

I'm actually trying to figure out the same thing, don't know what causes this, I also do not have anything fancy in the conf files.

Anyways, I dive into bsd.lib.mk and it clearly installs directly into LIBDIR. I have no idea how it works for you.

Not sure either. I suppose something is wrong on my end, but not sure what.

I tried building this in Poudriere to rule out environmental differencies and git this:

===>  Building for virtual_oss_sndio-1500053
--- sndio.pico ---
cc -fpic -DPIC   -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -fno-common -I/usr/src/usr.sbin/virtual_oss/virtual_oss  -I/usr/local/include   -MD  -MF.depend.sndio.pico -MTsndio.pico -std=gnu17 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-error=cast-function-type-mismatch  -Qunused-arguments      -c /usr/src/lib/virtual_oss/sndio/sndio.c -o sndio.pico
In file included from /usr/src/lib/virtual_oss/sndio/sndio.c:36:
/usr/src/usr.sbin/virtual_oss/virtual_oss/int.h:33:10: fatal error: 'samplerate.h' file not found
   33 | #include <samplerate.h>
      |          ^~~~~~~~~~~~~~
1 error generated.
*** [sndio.pico] Error code 1

I took the freshest revision of D52308, of course.

In D52365#1197605, @arrowd wrote:

I tried building this in Poudriere to rule out environmental differencies and git this:

===>  Building for virtual_oss_sndio-1500053
--- sndio.pico ---
cc -fpic -DPIC   -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -fno-common -I/usr/src/usr.sbin/virtual_oss/virtual_oss  -I/usr/local/include   -MD  -MF.depend.sndio.pico -MTsndio.pico -std=gnu17 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-error=cast-function-type-mismatch  -Qunused-arguments      -c /usr/src/lib/virtual_oss/sndio/sndio.c -o sndio.pico
In file included from /usr/src/lib/virtual_oss/sndio/sndio.c:36:
/usr/src/usr.sbin/virtual_oss/virtual_oss/int.h:33:10: fatal error: 'samplerate.h' file not found
   33 | #include <samplerate.h>
      |          ^~~~~~~~~~~~~~
1 error generated.
*** [sndio.pico] Error code 1

I took the freshest revision of D52308, of course.

Hmm, I suspect it needs a LIBADD=samplerate like the other backends. Please re-apply D52308 and let me know if it works now.

Is it feasible to use the latest virtual_oss for all os releases? Simply using base src does not solve the problem. The official packages are built on the oldest supported release, e.g. right now 14.2-release builds packages for 14.2, 14.3, and 14-stable. Besides, setting DISTVERSION directly to OSVERSION reduces the update flexibility: the port will be only updated when OSVERSION is increased and has to be updated regardless the actual changes in virtual_oss.

In D52365#1198141, @makc wrote:

Is it feasible to use the latest virtual_oss for all os releases? Simply using base src does not solve the problem. The official packages are built on the oldest supported release, e.g. right now 14.2-release builds packages for 14.2, 14.3, and 14-stable.

You're right, but we already have a solution for this. kmod ports are built separately from others for each supported release we have. And they also have OSVERSION in their PORTVERSIONs. These oss ports, although, not a kernel modules, should follow the same scheme.

I finally set up a proper jail for poudriere and carried out the build. This is what I'm getting with poud testport:

===>  Building for virtual_oss_sndio-1600000
[Creating objdir /wrkdirs/usr/ports/audio/virtual_oss_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio...]
--- .depend ---
echo voss_sndio.so: /wrkdirs/usr/ports/audio/virtual_oss_sndio/work/usr/src/amd64.amd64/lib/libsamplerate/libsamplerate_pie.a >> .depend
--- sndio.pico ---
cc -fpic -DPIC   -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -fno-common -I/usr/src/usr.sbin/virtual_oss/virtual_oss  -I/usr/src/contrib/libsamplerate  -I/usr/local/include   -MD  -MF.depend.sndio.pico -MTsndio.pico -std=gnu17 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-error=cast-function-type-mismatch  -Qunused-arguments      -c /usr/src/lib/virtual_oss/sndio/sndio.c -o sndio.pico

--- voss_sndio.so ---
Building shared library voss_sndio.so
cc   -L/usr/local/lib -lsndio -Wl,-zrelro    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o voss_sndio.so -Wl,-soname,voss_sndio.so sndio.pico -L/wrkdirs/usr/ports/audio/virtual_oss_sndio/work/usr/src/amd64.amd64/lib/libsamplerate -lsamplerate_pie 
ld: error: unable to find library -lsamplerate_pie
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [voss_sndio.so] Error code 1

In D52365#1198187, @arrowd wrote:

And they also have OSVERSION in their PORTVERSIONs. These oss ports, although, not a kernel modules, should follow the same scheme.

kmod ports use versioned tarballs at least. This port takes OSVERSION from installed /usr/include/sys/param.h, assuming installed system and sources are synced. It could be the way to go, but to me this seems as error-prone approach.
Could you consider creating tarballs from the base src to use them as distfiles for these ports?

In D52365#1198590, @arrowd wrote:

I finally set up a proper jail for poudriere and carried out the build. This is what I'm getting with poud testport:

===>  Building for virtual_oss_sndio-1600000
[Creating objdir /wrkdirs/usr/ports/audio/virtual_oss_sndio/work/usr/src/amd64.amd64/lib/virtual_oss/sndio...]
--- .depend ---
echo voss_sndio.so: /wrkdirs/usr/ports/audio/virtual_oss_sndio/work/usr/src/amd64.amd64/lib/libsamplerate/libsamplerate_pie.a >> .depend
--- sndio.pico ---
cc -fpic -DPIC   -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -fno-common -I/usr/src/usr.sbin/virtual_oss/virtual_oss  -I/usr/src/contrib/libsamplerate  -I/usr/local/include   -MD  -MF.depend.sndio.pico -MTsndio.pico -std=gnu17 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-error=cast-function-type-mismatch  -Qunused-arguments      -c /usr/src/lib/virtual_oss/sndio/sndio.c -o sndio.pico

--- voss_sndio.so ---
Building shared library voss_sndio.so
cc   -L/usr/local/lib -lsndio -Wl,-zrelro    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o voss_sndio.so -Wl,-soname,voss_sndio.so sndio.pico -L/wrkdirs/usr/ports/audio/virtual_oss_sndio/work/usr/src/amd64.amd64/lib/libsamplerate -lsamplerate_pie 
ld: error: unable to find library -lsamplerate_pie
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [voss_sndio.so] Error code 1

Have you applied D52310?

In D52365#1198615, @makc wrote:

In D52365#1198187, @arrowd wrote:

And they also have OSVERSION in their PORTVERSIONs. These oss ports, although, not a kernel modules, should follow the same scheme.

kmod ports use versioned tarballs at least. This port takes OSVERSION from installed /usr/include/sys/param.h, assuming installed system and sources are synced. It could be the way to go, but to me this seems as error-prone approach.
Could you consider creating tarballs from the base src to use them as distfiles for these ports?

I am actually a bit confused with this. If I understand correctly, with the current approach the port is only built if /usr/src exists in the system building it. In that case, I'm not sure if we need to ship tarballs, because if virtual_oss is not part of base (i.e., any version before 15.0), then the port won't build in the first place, because the sources needed to build it won't exist. Also, if a user somehow ends up installing those ports as binaries, what will happen is:

• In the case of this port and D52426, nothing will happen at all, since those are extensions of the base system virtual_oss.
• In the case of D52366, it will work fine on any version.

In D52365#1198719, @christos wrote:

Have you applied D52310?

Yes, I got past that error.

I am actually a bit confused with this. If I understand correctly, with the current approach the port is only built if /usr/src exists in the system building it.

The problem @makc is talking about is that we build packages for 14.3 in the 14.2 jail. This is how our package infrastructure works. This means that all these ports will take source from 14.2, but packages will be installed into 14.3.

But I'd postpone solving this problem until we deal with complation issues.

In D52365#1198746, @arrowd wrote:

I am actually a bit confused with this. If I understand correctly, with the current approach the port is only built if /usr/src exists in the system building it.

The problem @makc is talking about is that we build packages for 14.3 in the 14.2 jail. This is how our package infrastructure works. This means that all these ports will take source from 14.2, but packages will be installed into 14.3.

Right, so in the future if a 15.0 jail build the port for 15.1, the port will have 15.0 as its version. I understand. Isn't there a way to avoid creating and maintaining tarballs?

The machinery that is used for building kmods wouldn't work for us. I talked to bapt and it turned out that kmod ports are built using cross-compilation. It works for them, because they have almost zero dependencies, but it won't work for virtual_oss ports.

I don't quite get what tarballs we're talking about. We can still take sources from /usr/src, but we have to maintain the ABI so that ports build from 15.0 sources would work with 15.1+ base system.

In D52365#1198760, @arrowd wrote:

The machinery that is used for building kmods wouldn't work for us. I talked to bapt and it turned out that kmod ports are built using cross-compilation. It works for them, because they have almost zero dependencies, but it won't work for virtual_oss ports.

I don't quite get what tarballs we're talking about. We can still take sources from /usr/src, but we have to maintain the ABI so that ports build from 15.0 sources would work with 15.1+ base system.

Since virtual_oss in base is new, and is not really critical or massively complex software, I think just MFC'ing changes accordingly to keep the ports stable even if they are built for a different version, is reasonable.

Sorry, ENOTIME. I will try to go over all the oss stuff this Sunday.

In D52365#1202021, @arrowd wrote:

Sorry, ENOTIME. I will try to go over all the oss stuff this Sunday.

No worries, thank you. :-)

I finally managed to build the base part and test this port in Poudriere - it builds successfully.

The last problem we must solve is building against different OSVERSION's. To reiterate:

• Package cluster builds on a least supported minor release in a major branch.
• This means that once 15.1-RELEASE is out, but before 15.0-RELEASE goes EoL, the port will be compiled on 15.0.
• The package compiled on the 15.0 builder would obviously have 1500000 as its version.
• But this package is going to be installed onto 15.1 user machines.

For kernel modules we have a special pkg repo that contains package with versions matching the minor release. But after consulting with bapt it turned out that the machinery used for this repo involves cross-compilation and does not use poudriere. I feel like trying to reuse it for these oss ports is a bad idea.

This leaves us with a requirement for the ABI compliance. @christos would it be possible to guarantee backward ABI compatibility for the OSS bits in base, so that ports compiled against 15.0 sources would work with 15.1 binaries?

In D52365#1206153, @arrowd wrote:

This leaves us with a requirement for the ABI compliance. @christos would it be possible to guarantee backward ABI compatibility for the OSS bits in base, so that ports compiled against 15.0 sources would work with 15.1 binaries?

I suppose if I MFC changes to releng/15.0 and stable/15 we should be safe? This way all releases will share the same code.

In D52365#1206276, @christos wrote:

I suppose if I MFC changes to releng/15.0 and stable/15 we should be safe? This way all releases will share the same code.

I don't think so. The builder might run 15.0-p0 and not getting any updates. And picking something into the releng branch isn't enough - it should go through some releng process, AFAIK.

If ABI guarantees can't be held, we should look into calling sndio via dlopen/dlsym to move the dependency to the run time.

In D52365#1206279, @arrowd wrote:

In D52365#1206276, @christos wrote:

I suppose if I MFC changes to releng/15.0 and stable/15 we should be safe? This way all releases will share the same code.

I don't think so. The builder might run 15.0-p0 and not getting any updates. And picking something into the releng branch isn't enough - it should go through some releng process, AFAIK.

If ABI guarantees can't be held, we should look into calling sndio via dlopen/dlsym to move the dependency to the run time.

This is what we are doing already: https://cgit.freebsd.org/src/tree/usr.sbin/virtual_oss/virtual_oss/main.c#n1639

Or do you mean something else?

In D52365#1206280, @christos wrote:

This is what we are doing already: https://cgit.freebsd.org/src/tree/usr.sbin/virtual_oss/virtual_oss/main.c#n1639

Or do you mean something else?

Yes, I mean that we can compile voss_sndio.so as part of the base build if it wouldn't need to link with libsndio.so directly. Replacing direct calls with dlsym'ed ones will untie voss_sndio.so from voss_sndio.so and all these ports would be unnecessary.

In D52365#1206282, @arrowd wrote:

In D52365#1206280, @christos wrote:

This is what we are doing already: https://cgit.freebsd.org/src/tree/usr.sbin/virtual_oss/virtual_oss/main.c#n1639

Or do you mean something else?

Yes, I mean that we can compile voss_sndio.so as part of the base build if it wouldn't need to link with libsndio.so directly. Replacing direct calls with dlsym'ed ones will untie voss_sndio.so from voss_sndio.so and all these ports would be unnecessary.

I am not sure I'd like to do this to be honest. These backends use virtual_oss/sndio/oss/bluetooth parts that should normally not change frequently, or at all. I think we will be fine with keeping backwards compat.

All right then, all three ports build fine in Poudriere.

In D52365#1206292, @arrowd wrote:

All right then, all three ports build fine in Poudriere.

Great. If you feel like they are ready to commit, please give them an accept and I will commit them now. Thanks for all the help! :-)