Re: audio/csound6 and devel/sdl12-compat failing on Darwin (macOS 14.0)

[Jason Bacon <jtocino%gmx.com@localhost>]

On 10/28/23 03:43, Benny Siegert wrote:
> > Am 26.10.2023 um 10:32 schrieb Manuel Kuklinski <mk%asdfghasdfgh.de@localhost>:
> >
> > Am Mittwoch 25 Oktober 2023 um 6:06:24 -0700, schrieb Jason Bacon 3,7K:
> > > Another possibility to consider is that pkgsrc is right and upstream is
> > > wrong.  Perhaps it actually *should* generate .so files rather than .dylib
> > > for loadable modules?  It might be easier to patch the code to look for .so,
> > > rather than patch the build to generate .dylib.  I'm not saying this is the
> > > case, just that I would investigate it.
> >
> > Upstream says, they look for .dylib (Top/csmodule.c:707) and never
> > tested the function of csound with bundles, but I just blatantly renamed
> > librtjack.so to librtjack.dylib, et voilà: sound output (after starting
> > jackd, of course) :-) As it seems, you were right; now, as far a I
> > understand, I can rename the .so in lib/csound/plugins64-6.0/ or create
> > a patch for named C file; I'll test the patch first and if I can't yield
> > results, I'll take the re-naming route; will push to wip/csound6181.
>
> On macOS, if you want to dlopen a plugin at runtime, it needs to be a bundle, not a shared library. Unfortunately, the naming of bundles is widely inconsistent.
>
> I think yes, upstream is wrong. They expect a bundle, not a library, but with a file name ending in .dylib.
>
> I guess we should just rename the files and be done with it.

I wouldn't rename the files, I would patch the source code so it looks 
for ".so" instead of ".dylib".  This is just as easy, without being 
misleading.