4 ms·

That is completely ridiculous. Pointing out that statically compiling dependencies or shipping them with a game can solve many so called compatibility problems

That is completely ridiculous. Pointing out that statically compiling dependencies or shipping them with a game can solve many so called compatibility problems is directly related to games working on linux.

mackal 8y ago
It is also the solution they currently use on Windows ... And what games are doing on Steam that support Linux. I won't comment on shipping your own glibc, because that probably could cause issues.
_wmd 8y ago
It's a wonderful idea - on paper, but all that's needed is for one of the many mandatory deps for running a GL program to link against the system libcurl or any other replaced dep and you're back in Crashville again, population 1 - cloth-eared developer
- CyberDildonics 8y ago
  Are there mandatory dependencies for running a GL program that can't work without using the system libcurl shared library? How does that make any sense?
  - _wmd 8y ago
    If you distribute and link libcurl v69 dynamically, the dynamic linker symbol table for your process will contain references to v69 symbols. If you then load an e.g. GL driver that in turn links libcurl v42, the GL driver will end up with some combination of v69 and maybe v42 symbols, despite being compiled against v42 headers containing v42 struct sizes and offsets. Now there is an opportunity for silent memory corruption in your program, one that even once detected, which may not happen for years, cannot easily be fixed without completely rearchitecting the build. When using a wide variety of system APIs including at least NSS and OpenGL, there is little control over what dynamic libraries end up loaded, the exact configuration will vary across machines Substitute libcurl for libexpat or libX11 or libstdc++ and the principle continues to apply. I can't think of a good reason something like libcurl would be used by the Nvidia driver or some bizarro embedded board's GL driver, but that doesn't mean the Nvidia driver doesn't now or in the future link it, and if/when that day arrives, the problem lies entirely with the program that mixed random system deps with random self-compiled deps.
    - CyberDildonics 8y ago
      > If you distribute and link libcurl v69 dynamically, This whole thread is about avoiding this.
angry_octet 8y ago
As you can see, both comments were indeed flagged by one of those stackexchange types that is always marking useful questions as off-topic. Probably the same person who thinks using anything but rpm is bad. The thread has then been detached for the crime of discussing voting, so only we can see it. The first rule of HN voting is not to discuss voting.

mackal 8y ago

It is also the solution they currently use on Windows ... And what games are doing on Steam that support Linux. I won't comment on shipping your own glibc, because that probably could cause issues.

_wmd 8y ago

It's a wonderful idea - on paper, but all that's needed is for one of the many mandatory deps for running a GL program to link against the system libcurl or any other replaced dep and you're back in Crashville again, population 1 - cloth-eared developer

CyberDildonics 8y ago
Are there mandatory dependencies for running a GL program that can't work without using the system libcurl shared library? How does that make any sense?
- _wmd 8y ago
  If you distribute and link libcurl v69 dynamically, the dynamic linker symbol table for your process will contain references to v69 symbols. If you then load an e.g. GL driver that in turn links libcurl v42, the GL driver will end up with some combination of v69 and maybe v42 symbols, despite being compiled against v42 headers containing v42 struct sizes and offsets. Now there is an opportunity for silent memory corruption in your program, one that even once detected, which may not happen for years, cannot easily be fixed without completely rearchitecting the build. When using a wide variety of system APIs including at least NSS and OpenGL, there is little control over what dynamic libraries end up loaded, the exact configuration will vary across machines Substitute libcurl for libexpat or libX11 or libstdc++ and the principle continues to apply. I can't think of a good reason something like libcurl would be used by the Nvidia driver or some bizarro embedded board's GL driver, but that doesn't mean the Nvidia driver doesn't now or in the future link it, and if/when that day arrives, the problem lies entirely with the program that mixed random system deps with random self-compiled deps.
  - CyberDildonics 8y ago
    > If you distribute and link libcurl v69 dynamically, This whole thread is about avoiding this.

angry_octet 8y ago

As you can see, both comments were indeed flagged by one of those stackexchange types that is always marking useful questions as off-topic. Probably the same person who thinks using anything but rpm is bad. The thread has then been detached for the crime of discussing voting, so only we can see it. The first rule of HN voting is not to discuss voting.