Vivek Dasmohapatra <vi...@collabora.co.uk> writes: > Hi -
Hi, > As you probably already know, there can only be one version of > libstdc++.so in your runtime link chain 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]. > 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. > 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. > 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. > 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. > 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. ) [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html >[...]
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
