You do realize that statically linking libstdc++ and libgcc_s while
dynamically linking LLVM won't work around the problem caused by Steam
overriding an older version of libstdc++, because LLVM will still be
dynamically linked against that?
As you'll note from my first submission, I sent a patch
+fi;
+STATIC_STDCPP_LIBS="-l:libgcc.a -l:libgcc_eh.a -l:libstdc++.a";
+STATIC_STDCPP_LDFLAGS="-static-libgcc -static-libstdc++ \
+ -l:libgcc.a -l:libstdc++.a \
Do we need this line considering the STATIC_STDCPP_LIBS above ?
Yes, I can't remember the exact fa
The original reference to the reason I found was in the dicussion of
a libtool bug about this, I can't find the exat place right now but
this looks similar in the details given:
http://www.trilithium.com/johan/2005/06/static-libstdc/
___
mesa-dev ma
That aside did you find any information as to why libtool adds the
explicit links despite -static-libgcc -static-libstdc++ ?
AIUI, exceptions can't cross a DSO boundary (eg from library to caller
outside that library) if there isn't a single dynamic libstdc++ linked
in.
_
Sttaically link gallium modules with libstdc++/libgcc/libgcc_eh
if --enable-static-libstdc++ is passed to ./configure:
---
configure.ac| 38 +
src/gallium/Automake.inc| 1 +
src/gallium/targets/dri/Makefile.am | 1 +
3 fil
Oops... that patch wasn't complete. Fixed version to follow as
soon as I've run it through a build each way. Apologies for
any inconvenience.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
As requested - The previous patch to enable static libstdc++/libgcc
linking but now controlled by a configure option:
---
configure.ac| 29 +
src/gallium/Automake.inc|1 +
src/gallium/targets/dri/Makefile.am |5 +
3 fi
