3 ms·

Many programming languages do not use Meson as a build system (examples: Go, Rust, Haskell). Some C or C++ projects may use autoconf or CMake, in which case you

by nh2 5y ago

Many programming languages do not use Meson as a build system (examples: Go, Rust, Haskell). Some C or C++ projects may use autoconf or CMake, in which case you cannot use Meson subprojects either. Distros use `-Ddefault_library=both` or `=static`, and let Meson install the built archive files; this is what is broken in that issue. It is surprising that this flag does nothing for GTK when it works as expected for all other Meson projects. You could copy the archive file behind the Meson install action's back, but the maintainers' point on the issue is: "GTK isn't meant to be built as a static library" and "why do you think you need a static build of GTK4?". If they do not want to support it, there's no guarantee the .a file will still be there tomorrow. That's what "upstream support" means.

zxzax 5y ago
For Go, Rust, Haskell, autoconf, CMake, you would invoke the meson and ninja commands as part of your build process. You can't use them in the same exact way as meson subprojects, but these are just shell commands. It's the standard way to build any project with an external build tool. Am I misunderstanding a requirement? For a static build deployed in a specialized situation, you would likely need a customized gtk build to begin with. I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do. I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.
- nh2 5y ago
  I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs. Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`. > if they could keep that libgtk_static around Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious. > I'd be interested to hear if static linking GTK even has that many benefits One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere. Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed. This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so. [1] https://github.com/nh2/static-haskell-nix/releases/tag/c-static-gtk3-apps-button-example-2020-11-23 https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

by nh2 5y ago

zxzax 5y ago

For Go, Rust, Haskell, autoconf, CMake, you would invoke the meson and ninja commands as part of your build process. You can't use them in the same exact way as meson subprojects, but these are just shell commands. It's the standard way to build any project with an external build tool. Am I misunderstanding a requirement? For a static build deployed in a specialized situation, you would likely need a customized gtk build to begin with. I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do. I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.

nh2 5y ago
I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs. Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`. > if they could keep that libgtk_static around Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious. > I'd be interested to hear if static linking GTK even has that many benefits One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere. Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed. This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so. [1] https://github.com/nh2/static-haskell-nix/releases/tag/c-static-gtk3-apps-button-example-2020-11-23 https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...