<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 11.03.2015 17:01, Francisco Jerez wrote: </div> <blockquote cite="mid:87vbi71q1p.fsf@riseup.net" type="cite"> <pre wrap="">Vivek Dasmohapatra <a class="moz-txt-link-rfc2396E" href="mailto:vivek@collabora.co.uk"><vivek@collabora.co.uk></a> writes: </pre> <blockquote type="cite"> <pre wrap="">Hi - </pre> </blockquote> <pre wrap=""> Hi, </pre> <blockquote type="cite"> <pre wrap="">As you probably already know, there can only be one version of libstdc++.so in your runtime link chain </pre> </blockquote> <pre wrap=""> That's a common misconception, in principle several versions of libstdc++.so with different DT_SONAME (i.e. with mutually incompatible ABIs) can be loaded at the same time, the GNU C++ runtime uses library and symbol versioning to achieve this. Of course two different versions with the same DT_SONAME cannot coexist, but that's not supposed to pose a problem because applications linked to the earlier version are expected to be forwards-compatible with more recent minor versions of the standard library. See [1]. </pre> <blockquote type="cite"> <pre wrap="">This is usually not a problem, but when things are linked against the Steam runtime (for example), they can end up with two - one from the steam runtime, and one pulled in via the mesa dri libs from the OS/distribution. </pre> </blockquote> <pre wrap="">Last time I looked into this, it seemed to be a logical consequence of the inconsistency of the Steam runtime overriding system libraries: If they go as far as to override the operating system's copy of the C++ standard library and runtime with an outdated version (even though the OS libraries with the same DT_SONAME are expected to be backwards-compatible with Steam's), they should be shipping their own builds of libGL and DRI drivers as well. </pre> <blockquote type="cite"> <pre wrap="">In order to address this, Valve asked Collabora to look at enabling mesa linking with libstdcc+.a/libgcc.a/libgcc_eh.a instead of listdcc++so and libgcc_s.so. I think I've figured out a minimally intrusive way to do this, working around the fact that libtool really, really wants to link those in if C++ is involved. I've broken this up into a couple of pieces: The first patch attached gets libtool to not link in the .so files in question: It's pretty small - it doesn't introduce a configure flag to control this behaviour, but I would be happy to adapt it to do so if that's considered a better approach. </pre> </blockquote> <pre wrap="">Honestly, I think that statically linking the C++ runtime is a hack, and it should be an opt-in based on some configure option if we want to support it at all. </pre> </blockquote> The problem in not forcing this to link statically is, that if a distribution decides to not use this static option, the problem persists on that distribution. On top every lib pulled in by steam from the system would need to be link statically, like mesa. Instead of fixing every lib steam pulls in (how many are there?), fix the steam runtime to a) not ship libstdc++.so and libgcc_s.so and declare older version of these libs as not supported (thats what people do when they face the incompatibility problem with steams versions of these libs: just delete them from the runtime and everything is fine) b) ship own mesa and libdrm drivers <blockquote cite="mid:87vbi71q1p.fsf@riseup.net" type="cite"> <blockquote type="cite"> <pre wrap="">The second and third extend this a little further: Patch #3 is actually to llvm, and builds a parallel libLLVM-X.Y-nostdlib.so which is likewise linked with libstdc++.a et al instead of .so, and patch #2 makes the mesa build system use said library if it is available. So: Would mesa be interested in patches #1 and/or #2? If not, is there something I could do to make the patches more palatable, or some other approach that you'd prefer? ( I'm aware of the configure flags to statically link against libLLVM, but when I tried it with llvm-3.5 and a git checkout of mesa 10.6-dev I got link errors, hence the LLVM patchset. ) </pre> </blockquote> <pre wrap=""> [1] <a class="moz-txt-link-freetext" href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html">https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html</a> </pre> <blockquote type="cite"> <pre wrap="">[...] </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ mesa-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </pre> </blockquote> </blockquote> </body> </html>