Static Linux version of my program
A day before i send my Linux version of my program and it don't runs.
If i want to send in many people, and all these people have no idea about functionals, they are simple users, how should my program run?
It goes without saying that the executable must have no dependencies.
That's why I want to make it static.
with -static flag on GCC compiler says...
/usr/bin/ld: cannot find -lGL:
/usr/bin/ld: cannot find -lEGL:
/usr/bin/ld: cannot find -lwayland-egl:
/usr/bin/ld: cannot find -lwayland-client:
/usr/bin/ld: cannot find -lxkbcommon:
/usr/bin/ld: cannot find -lgtk-3:
/usr/bin/ld: cannot find -lgdk-3:
/usr/bin/ld: cannot find -lpangocairo-1.0:
/usr/bin/ld: cannot find -latk-1.0:
/usr/bin/ld: cannot find -lgdk_pixbuf-2.0:
/usr/bin/ld: cannot find -lpangoft2-1.0:
/usr/bin/ld: cannot find -lpango-1.0:
If no use -static program runs just fine.
I don't know what i must do.
Thank you
Jim.
If i want to send in many people, and all these people have no idea about functionals, they are simple users, how should my program run?
It goes without saying that the executable must have no dependencies.
That's why I want to make it static.
with -static flag on GCC compiler says...
/usr/bin/ld: cannot find -lGL:
/usr/bin/ld: cannot find -lEGL:
/usr/bin/ld: cannot find -lwayland-egl:
/usr/bin/ld: cannot find -lwayland-client:
/usr/bin/ld: cannot find -lxkbcommon:
/usr/bin/ld: cannot find -lgtk-3:
/usr/bin/ld: cannot find -lgdk-3:
/usr/bin/ld: cannot find -lpangocairo-1.0:
/usr/bin/ld: cannot find -latk-1.0:
/usr/bin/ld: cannot find -lgdk_pixbuf-2.0:
/usr/bin/ld: cannot find -lpangoft2-1.0:
/usr/bin/ld: cannot find -lpango-1.0:
If no use -static program runs just fine.
I don't know what i must do.
Thank you
Jim.
Those errors mean that the required libraries are not available on your system – as "static" libraries.
The "problem" with Linux is that every Linux distribution (and every version of a distribution) is pretty much a distinct operating system. They are all based on the Linux kernel, but they use different versions of the Linux kernel and – even more important – they ship with different libraries (and different library versions), they use different configurations, and they use different packing systems. This makes creating "binary" files that will run on every Linux-based system very hard, if not impossible. You probably will have to discard that idea.
For this reasons, Linux software is almost always distributed either as source code with a
For example, if you decide that you want to support Debian (and derivatives) only, you could distribute your software as deb packages:
https://en.wikipedia.org/wiki/Deb_(file_format)
Static linking may be a solution for very simple programs, but as soon as you have a more complex program with a lot of library dependencies, this usually will lead to a dead end, because a lot of libraries simply are not available (or not supposed to be used) as "static" libraries. For example, the GNU C Library (glibc), which is the "standard" C library on most Linux distributions, does not properly support static linking! You may be able to switch to a different C library, such as musl libc, but that adds even more hassle to the build process.
https://musl.libc.org/about.html
One possible way to distribute your software as packages that work "out-of-the-box" on pretty much all Linux-based systems is Flatpak:
https://flatpak.org/
…but, of course, the Flatpak runtime must still be installed. Usually via the distribution-specific package manager.
Snap has a similar concept to Flatpak, but it is mostly popular on Ubuntu:
https://snapcraft.io/about
The "problem" with Linux is that every Linux distribution (and every version of a distribution) is pretty much a distinct operating system. They are all based on the Linux kernel, but they use different versions of the Linux kernel and – even more important – they ship with different libraries (and different library versions), they use different configurations, and they use different packing systems. This makes creating "binary" files that will run on every Linux-based system very hard, if not impossible. You probably will have to discard that idea.
For this reasons, Linux software is almost always distributed either as source code with a
Makefile (often together with a configure script), so that everybody can build the software from sources on (and for) their own specific system; or as distribution-specific "binary" packages that run on the specific distribution (and specific version of the distribution) that they were made for, but not anywhere else!For example, if you decide that you want to support Debian (and derivatives) only, you could distribute your software as deb packages:
https://en.wikipedia.org/wiki/Deb_(file_format)
Static linking may be a solution for very simple programs, but as soon as you have a more complex program with a lot of library dependencies, this usually will lead to a dead end, because a lot of libraries simply are not available (or not supposed to be used) as "static" libraries. For example, the GNU C Library (glibc), which is the "standard" C library on most Linux distributions, does not properly support static linking! You may be able to switch to a different C library, such as musl libc, but that adds even more hassle to the build process.
https://musl.libc.org/about.html
One possible way to distribute your software as packages that work "out-of-the-box" on pretty much all Linux-based systems is Flatpak:
https://flatpak.org/
…but, of course, the Flatpak runtime must still be installed. Usually via the distribution-specific package manager.
Snap has a similar concept to Flatpak, but it is mostly popular on Ubuntu:
https://snapcraft.io/about
Last edited on
| ship with different libraries (and different library versions) |
That has further with static executables. The list of missing libraries is mostly GUI/Window components. If one has one version in the of the libraries in the executable and very different on the system where one runs the program, what is the chance that the two parts can interact? Similarly, some libraries talk to the kernel, so that interface must be compatible.
The
configure script generates a Makefile that makes use of the tools that are available on the system, where the script is run and the program will be build. It is part of GNU Build System. An alternative build system is based on CMake https://cmake.org/The Flatpak and Snap are some sort of containers, aren't they? Docker was the first container implementation that got popular. Containers succeed virtualization, being "lighter" than whole VMs. Personally, I do prefer built-for-distro, but I do understand the convenience for the developer to create and distribute a container.
| The Flatpak and Snap are some sort of containers, aren't they? |
Yes. But while Docker is mainly targeted at CLI and server applications, Flatpak and Snap work better with GUI applications.
They all are container technologies. Because they create a "virtual" environment in which your application will run, you can easily create and distribute an "all-in-one" image that contains everything (libraries, tools, configuration files, etc.) that is needed to run the application.
Usually those images are built by extending a "base" (parent) image, such as Alpine Linux – a minimal Linux suitable for containers.
Last edited on
Topic archived. No new replies allowed.