On Fri, 2014-10-17 at 21:52 +0000, Joseph S. Myers wrote:
> Does libgccjit.so end up getting linked with -static-libstdc++
> -static-libgcc?
(sorry for belated reply)
It does when built with a bootstrap, but doesn't with
--disable-bootstrap. In the former case, the builddir's gcc/Makefile in
the final stage has:
LDFLAGS = -static-libstdc++ -static-libgcc
and we use $(LDFLAGS) in the src's gcc/jit/Make-lang.in in the rule for
$(LIBGCCJIT_FILENAME).
As far as I can tell, this comes from these lines:
if test "$poststage1_libs" = ""; then
poststage1_ldflags="-static-libstdc++ -static-libgcc"
fi])
in the top-level configure.ac's code for:
AC_ARG_WITH(boot-ldflags,
> If so, that could be problematic (are static libstdc++
> and libgcc necessarily built as PIC so it's even possible to embed them
> into a shared library?).
It works (on this machine at least); the built libgccjit.so library
successfully runs the test suite.
Looking at the build logs, I see:
-fPIC
within the xgcc args in the libgcc build logs, and
-prefer-pic
within the libtool args in the libstdc++ build, which according to the
libtool docs means "try to build only PIC objects".
Hence I believe although we're currently statically-linking libgcc and
libstdc++ into libgccjit.so, they're position-independent.
> 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
selecting appropriate configuration flags (though it's not quite clear
to me what the incantation is; presumably $poststage1_libs needs to be
non-empty to avoid triggering this clause:
if test "$poststage1_libs" = ""; then
poststage1_ldflags="-static-libstdc++ -static-libgcc"
fi
, right ?)
Or maybe I could turn off that clause if the "--enable-host-shared" has
been specified, so it defaults to shared linkage for that setting?
Do you have thoughts on how I should address this? Also, given that the
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)
Thanks
Dave
> The dump file handling appears to have no I/O error checking (no
> checking
> for error on fopen, nothing obvious to prevent fwrite to a NULL m_file
> if
> fopen did have an error, no checking for error on fclose (or fwrite)).
(already addressed in a different reply)
