Can I statically link OpenSCAD dependencies on Linux?
Short version:
Is there a way to configure a from-source build of OpenSCAD on Linux
to statically link its dependencies?
Longer version:
I am experimenting with building OpenSCAD in a Dev Container (
https://containers.dev/ ). I have dependencies installed within my
container and am able to do a basic build using:
cmake -B build -DEXPERIMENTAL=1
cmake --build build
I can run the resulting binary inside the container just fine. I can
access files that I've shared into the container, and I've found a way
to expose Wayland so the GUI works. This is perfect for development.
It would still be handy if I could run this binary outside the
container however. The problem is the binary is dynamically linked
against 80+ libraries, and does not run on my host OS where I do not
have all those dependencies installed (nor do I want them to be
installed there). I found that I can change some of these
dependencies to be statically linked. For example Boost can be
statically linked by specifying -DBoost_USE_STATIC_LIBS=ON. Is
there a blanket option to configure the build so that all dependencies
are statically linked by default, or do I need to find options to set
this one library at a time like I did with Boost?
Why am I doing this?
I'd like to dip my toe in contributing to OpenSCAD, and ideally I
would like to use a dev container for my local development builds in
order to isolate the development environment and keep my host clean.
Hi!
On 18.04.25 10:21, Paul Richards via Discuss wrote:
Is there a way to configure a from-source build of OpenSCAD on Linux
to statically link its dependencies?
I don't think that is possible. You may get like 95% with most of
the libraries, but some have built-in logic that does dynamic
loading anyway (Qt, Mesa).
That is basically "how to ship Linux applications to users" which
is not exactly a solved problem other than using complete Linux
environments (Snap, Flatpak) or building in a known setup (Distros,
regardless of server or local build).
Everything in-between works ok most of the time but has quite some
limitations and issues (AppImage).
ciao,
Torsten.
Hi Paul,
I don't think it is possible for GUI applications to do this, or at least
it will be very hard. You may want to look at X forwarding or wayland
socket to get the graphical application out.
Alternatively, you can try to just dynamically link things like graphics
lib. To statically link everything else, this means you need to compile
from source for every other dependencies and do static linking for them.
Best,
pca006132
On Fri, Apr 18, 2025, 9:30 PM Paul Richards via Discuss <
discuss@lists.openscad.org> wrote:
Short version:
Is there a way to configure a from-source build of OpenSCAD on Linux
to statically link its dependencies?
Longer version:
I am experimenting with building OpenSCAD in a Dev Container (
https://containers.dev/ ). I have dependencies installed within my
container and am able to do a basic build using:
cmake -B build -DEXPERIMENTAL=1
cmake --build build
I can run the resulting binary inside the container just fine. I can
access files that I've shared into the container, and I've found a way
to expose Wayland so the GUI works. This is perfect for development.
It would still be handy if I could run this binary outside the
container however. The problem is the binary is dynamically linked
against 80+ libraries, and does not run on my host OS where I do not
have all those dependencies installed (nor do I want them to be
installed there). I found that I can change some of these
dependencies to be statically linked. For example Boost can be
statically linked by specifying -DBoost_USE_STATIC_LIBS=ON. Is
there a blanket option to configure the build so that all dependencies
are statically linked by default, or do I need to find options to set
this one library at a time like I did with Boost?
Why am I doing this?
I'd like to dip my toe in contributing to OpenSCAD, and ideally I
would like to use a dev container for my local development builds in
order to isolate the development environment and keep my host clean.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thanks for the quick reply.
I've thought about it some more, and I actually think I don't need to
be running the binary outside of the container. This perhaps
sidesteps the issue entirely.
On Fri, 18 Apr 2025 at 14:47, Torsten Paul via Discuss
discuss@lists.openscad.org wrote:
Hi!
On 18.04.25 10:21, Paul Richards via Discuss wrote:
Is there a way to configure a from-source build of OpenSCAD on Linux
to statically link its dependencies?
I don't think that is possible. You may get like 95% with most of
the libraries, but some have built-in logic that does dynamic
loading anyway (Qt, Mesa).
95% would be good enough I expect. I acknowledge that certain "core
platform" libraries should not be statically linked, regardless. My
host OS will almost certainly have these. It's just the long list of
lesser libraries that I'd look to statically link.
I wonder if as a hack I could just cp the shared libraries out from
the container and set LD_LIBRARY_PATH on the host to make them
accessible.
That is basically "how to ship Linux applications to users" which
is not exactly a solved problem other than using complete Linux
environments (Snap, Flatpak) or building in a known setup (Distros,
regardless of server or local build).
Everything in-between works ok most of the time but has quite some
limitations and issues (AppImage).
Yep, acknowledged. Most of the time I'm using the Flatpak of OpenSCAD.
Thanks for the reply!
On Fri, 18 Apr 2025 at 14:51, pca006132 john.lck40@gmail.com wrote:
Hi Paul,
I don't think it is possible for GUI applications to do this, or at least it will be very hard. You may want to look at X forwarding or wayland socket to get the graphical application out.
I already have this working. I'm able to forward Wayland, and the GUI
works just fine when the app runs inside the container.
Alternatively, you can try to just dynamically link things like graphics lib. To statically link everything else, this means you need to compile from source for every other dependencies and do static linking for them.
The container image I'm using is already providing static versions of
the dependencies (I can see them sat in /usr/lib/..). I would be
happy to statically link most things, and leave some "core platform"
libraries as dynamically linked which would get picked up from the
host.
Best,
pca006132
On Fri, Apr 18, 2025, 9:30 PM Paul Richards via Discuss discuss@lists.openscad.org wrote:
Short version:
Is there a way to configure a from-source build of OpenSCAD on Linux
to statically link its dependencies?Longer version:
I am experimenting with building OpenSCAD in a Dev Container (
https://containers.dev/ ). I have dependencies installed within my
container and am able to do a basic build using:cmake -B build -DEXPERIMENTAL=1 cmake --build buildI can run the resulting binary inside the container just fine. I can
access files that I've shared into the container, and I've found a way
to expose Wayland so the GUI works. This is perfect for development.It would still be handy if I could run this binary outside the
container however. The problem is the binary is dynamically linked
against 80+ libraries, and does not run on my host OS where I do not
have all those dependencies installed (nor do I want them to be
installed there). I found that I can change some of these
dependencies to be statically linked. For example Boost can be
statically linked by specifying-DBoost_USE_STATIC_LIBS=ON. Is
there a blanket option to configure the build so that all dependencies
are statically linked by default, or do I need to find options to set
this one library at a time like I did with Boost?Why am I doing this?
I'd like to dip my toe in contributing to OpenSCAD, and ideally I
would like to use a dev container for my local development builds in
order to isolate the development environment and keep my host clean.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 18.04.25 15:54, Paul Richards wrote:
I've thought about it some more, and I actually think I don't need to
be running the binary outside of the container. This perhaps
sidesteps the issue entirely.
Yep that helps. Nowadays there is even waypipe which basically does
the same as X forwarding while I remember this was supposed to be
impossible for a long time :-).
Also if you would like to chat directly (with humans ;-) the IRC
channel #openscad is pretty low traffic and has both users and
developers.
ciao,
Torsten.
I have raised a pull request containing the dev container configuration:
https://github.com/openscad/openscad/pull/5836
I’m not sure what your process is for external contributions, so let me
know if I need to do anything else.
Paul Richards
On Fri, 18 Apr 2025 at 15:00, Torsten Paul via Discuss <
discuss@lists.openscad.org> wrote:
On 18.04.25 15:54, Paul Richards wrote:
I've thought about it some more, and I actually think I don't need to
be running the binary outside of the container. This perhaps
sidesteps the issue entirely.
Yep that helps. Nowadays there is even waypipe which basically does
the same as X forwarding while I remember this was supposed to be
impossible for a long time :-).
Also if you would like to chat directly (with humans ;-) the IRC
channel #openscad is pretty low traffic and has both users and
developers.
ciao,
Torsten.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org