On Thu, 30 Oct 2014, David Malcolm wrote: > Looking at the build logs, I see: > -fPIC > within the xgcc args in the libgcc build logs, and
That seems to depend on t-libgcc-pic, but that appears to cover most likely hosts (including any where I can be confident PIC is actually needed for shared libraries). > > It's certainly not clear that the > > -static-libstdc++ -static-libgcc default for building the compiler > > executables is the right one for building libgccjit.so. > > Agreed, but it's unclear to me what the default should be, and how to go > about fixing it. > > That said, it appears that people who want the libgccjit.so to > dynamically-link against libgcc and libstdc++ can already do so, by Can do so for libgccjit.so but not the compiler executables? (There are no doubt cases where it makes sense for the compiler executables to be dynamically linked with the shared libraries, but also I think cases for linking only libgccjit.so with the shared libraries.) > Do you have thoughts on how I should address this? Also, given that the No. > code works as-is, is resolving this a blocker for merging the jit > branch? (I've been rebasing, and plan to repost the fixed-up patches > for review shortly) I don't see it as a blocker, but I would not be surprised if having the libraries statically linked into libgccjit.so causes problems (is it safe to have two completely separate copies of libstdc++ in the same process? I don't know.). -- Joseph S. Myers jos...@codesourcery.com
