Re: Compile sndio as static library

Hi Alexandre,

Thanks for your response! Yes I do have a patch kept in Github. web link:
https://github.com/ratchov/sndio/commit/9aa77d6829775ab346675e9a090a27db2b3b1c2d.
The idea is we always build libsndio.so as usual, but build an additional
libsndio-static.a to include sndio as client API. The static library should
be used only by projects with special needs. I can send a pull request.

For my example or best practice, I can share my scenario as below. Hope it
can help explain why I need a static library. Surely, I may be missing
something, as I'm not an audio expert. Thus any feedback or comments are
really appreciated.

Thanks,
Fuzhou

=== Scenario of static library ===
This is to serve a scenario that requires distributing "portable" binaries,
which can be copied across Linux distros. A typical scenario is to
distribute games via Steam. In this scenario, developers should assume
client OSes do not have libraries we need, or they are installed but with
incompatible versions. Thus, I can't rely on headers/libraries provided by
the OS distro, but have to build dependencies myself.

There are two solutions, that I can a) include all dependency .so files
into my software package, or b) build against all libraries as static to a
big executable. Solution a) is not ideal due to an additional restriction:
once library A is compiled as a shared library, all the dependencies
against library A must be shared, or, the -l option must be populated via
dependency chain until the top level executable. This is difficult to apply
when we need special build flags. The preferred way is to build every
dependency against static libraries, which solves both problems.

I hit this problem on my project, HashBLD. The goal is to make a game
engine, hashlink, portable: https://github.com/fuzhouch/hashbld. A
dependency chain on the audio part is: hashlink(openal.hdll module) ->
openal-soft -> libsndio -> alsa-lib. I set a fixed backend chain until
alsa-lib (since ALSA is available on all Linux distros). Previously without
my patch, libsndio is built as shared, then openal-soft must be compiled as
shared too. Given openal-soft is a C++ project, the built shared library
links to libstdc++.so, when building from my Manjaro Linux, it will crash
on Linux with older libstdc++ versions (Steam runtime in my case) because
of C++ version mismatch.

Alternatively, I can patch openal-soft, adding -static-libstdc++ to solve
C++ version mismatch problem. However, it can be cumbersome when I build
more logic on top of Hashlink: they must be kept on the chain of every .so
library in the dependency chain, and repeatedly add libstdc++ code to every
shared library, causing distribution size bloat. Building everything as
static libraries is a much simpler solution.


Note that the OS distro packaging scenario is different. Since binaries are
expected to run against a known, fixed Linux distro, we should always
provide the shared library. It helps reduce the distro size, and keep the
backend settings correct.


On Tue, Dec 12, 2023 at 4:41 PM Alexandre Ratchov <alex_at_caoua.org> wrote:

> Hi,
>
> I see no reason for not providing a static library. If you've any
> local patches to do so, or examples of best Linux practices, I'm
> interested.
>
> On Mon, Dec 04, 2023 at 03:21:40AM +0800, Fuzhou Chen wrote:
> > Hello,
> >
> > I'm a game developer. I'm working on a project to compile the game
> engine I
> > use, (Haxe/Hashlink) in 100% static link for Linux. I noticed the engine
> > depends on openal-soft -> libsndio -> alsa-lib. I have successfully build
> > openal-soft and alsa-lib as static libraries, but seems libsndio Makefile
> > supports building only .so.
> >
> > I'm not an audio expert, so I'm wondering whether there's any reason that
> > libsndio must be built as a shared library?
> >
> >    === Describe the scenario of my ask ===
> >
> > I want my game engine to be static linked is because I want to ensure
> > -static-libgcc and -static-libstdc++ option added to all dependencies,
> thus my
> > built binaries can be distributed to a Linux machine with older libgcc
> and
> > libstdc++ installed. My typical scenario is when my Github CI machine is
> > Ubuntu:latest while my code runs on Ubuntu Runtime.
> >
> > Thus, there are two solutions: a) I make all my dependencies static.
> Then I
> > just need to add the two link options when building final Hashlink
> binary. If
> > this is not possible, then b) it's also OK that I add the options when
> building
> > libsndio.
> >
> > I'm developing a private fix following b) for libsndio. I understand
> this is
> > not a common option that should be enabled by default. Thus, I would
> like to
> > ask for suggestions that which direction looks better.
> >
> > Any suggestions are appreciated.
> >
> > Regards,
> > Fuzhou
>