4 ms·

I was also disappointed by the recent removal of static linking support in GTK [1]. It worked for a long time and now was made impossible. The reason given wa

by nh2 5y ago

I was also disappointed by the recent removal of static linking support in GTK [1]. It worked for a long time and now was made impossible. The reason given was "don't want to support it". That would make sense if it was a maintenance-intensive topic, here the only thing required is to use Meson's default options. I don't really buy the argument of "preventing to use internal APIs"; no FOSS developer in their right mind will link to internal symbols anyway. In my opinion, an application developer should be able to choose how to link their program; toolkit developers should not forbid one way if there isn't a good technical reason. [1] https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_1099438 https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109943...

zxzax 5y ago
Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.
- nh2 5y ago
  Projects in other programming languages for which Meson is not a choice also want to link statically (thus need the `.a` file installed).
  - zxzax 5y ago
    Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson. If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
    - 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

Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.

nh2 5y ago
Projects in other programming languages for which Meson is not a choice also want to link statically (thus need the `.a` file installed).
- zxzax 5y ago
  Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson. If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is needed there. In my experience this is going to be one additional line needed in the package manifest.
  - 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...