[Bug jit/64089] New: libgccjit.so.0.0.1 linkage failure on darwin

[Bug jit/64089] New: libgccjit.so.0.0.1 linkage failure on darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

            Bug ID: 64089
           Summary: libgccjit.so.0.0.1 linkage failure on darwin
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: jit
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: howarth at bromo dot med.uc.edu

Building the new jit language support in gcc trunk fails on darwin at the
linkage of libgccjit.so.0.0.1 with the error...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/bin/ -nostdinc++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/include/x86_64-apple-darwin14.1.0

-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/include
 -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20141126/libstdc++-v3/libsupc++
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.1.0/libstdc++-v3/libsupc++/.libs
  -g -O2  -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie -o
libgccjit.so.0.0.1 -shared \
     attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-recording.o
jit/jit-playback.o jit/jit-builtins.o libbackend.a libcommon-target.a
libcommon.a \
     ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a -lintl -L/sw/lib -liconv 
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a   -L/sw/lib -lisl -L/sw/lib -L/sw/lib -lmpc
-lmpfr -lgmp   -lz \
     -Wl,--version-script=../../gcc-5-20141126/gcc/jit/libgccjit.map \
     -Wl,-soname,libgccjit.so.0
ld: unknown option: --version-script=../../gcc-5-20141126/gcc/jit/libgccjit.map
collect2: error: ld returned 1 exit status
../../gcc-5-20141126/gcc/jit/Make-lang.in:78: recipe for target
'libgccjit.so.0.0.1' failed
make[3]: *** [libgccjit.so.0.0.1] Error 1
make[3]: Leaving directory
'/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc'
Makefile:4368: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
Makefile:20616: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
Makefile:906: recipe for target 'all' failed
make: *** [all] Error 2

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #1 from howarth at bromo dot med.uc.edu ---
Failing build configured with...

 ../gcc-5-20141126/configure --prefix=/sw --prefix=/sw/lib/gcc5.0
--mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java,jit --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-5.0

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #2 from howarth at bromo dot med.uc.edu ---
I see that the libgcc build handles this issue by passing the --version-script
linker option selectively using config/t-slibgcc-gld.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #3 from howarth at bromo dot med.uc.edu ---
Note that on darwin libgcc handles its symbol map using...

 -Wl,-exported_symbols_list,$(SHLIB_MAP) 

on SHLIB_LINK.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #4 from howarth at bromo dot med.uc.edu ---
We are testing in gcc/configure for...

configure:14564: checking for -exported_symbols_list linker flag
configure:14584: 
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin14.1.0/sys-include    -o conftest -g -O2 
-I/sw/include -static-libstdc++ -static-libgcc -Wl,-no_pie
-Wl,-exported_symbols_list,conftest.sym conftest.c  >&5
configure:14584: $? = 0
configure:14594: result: yes

Can we leverage this test to append the correct linker flags for
libgccjit.so.0.0.1 on darwin?

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #5 from dmalcolm at gcc dot gnu.org ---
(In reply to howarth from comment #1)
> Failing build configured with...
> 
>  ../gcc-5-20141126/configure --prefix=/sw --prefix=/sw/lib/gcc5.0
> --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
> --enable-languages=c,c++,fortran,lto,objc,obj-c++,java,jit --with-gmp=/sw
> --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
> --program-suffix=-fsf-5.0

BTW, if configuring with the jit enabled, --enable-host-shared is also required
(or we won't have position-independent code, and the link will fail, or, at
least, it will on Linux; am guessing the same will happen on Darwin).

The configure script should probably enforce that, but it doesn't yet.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #6 from howarth at bromo dot med.uc.edu ---
(In reply to dmalcolm from comment #5)
> (In reply to howarth from comment #1)
> > Failing build configured with...
> > 
> >  ../gcc-5-20141126/configure --prefix=/sw --prefix=/sw/lib/gcc5.0
> > --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
> > --enable-languages=c,c++,fortran,lto,objc,obj-c++,java,jit --with-gmp=/sw
> > --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
> > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
> > --program-suffix=-fsf-5.0
> 
> BTW, if configuring with the jit enabled, --enable-host-shared is also
> required (or we won't have position-independent code, and the link will
> fail, or, at least, it will on Linux; am guessing the same will happen on
> Darwin).
> 
> The configure script should probably enforce that, but it doesn't yet.

I don't believe this can be an issue on darwin as we always default to
producing PIC oode.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #7 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to howarth from comment #6)
> I don't believe this can be an issue on darwin as we always default to
> producing PIC oode.
Ah, ok.

Thanks for filing this bug.

I'm wondering what other problems libgccjit has on darwin.  If you hack in the
required options into jit/Makefile.in, to what extent do "make" and "make
check-jit" work?

I notice this blog post from a couple of months ago:
  http://adek.io/2014/10/04/gcc-jit-on-osx/
which talks about an issue with:
  dyld: Library not loaded: libgccjit.so.0

Perhaps on darwin we need to be setting DYLD_LIBRARY_PATH in the various places
where we're currently setting LD_LIBRARY_PATH?  (perhaps that should be a
separate bug, perhaps under a "libgccjit on darwin" tracker bug?).

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(In reply to Jack Howarth from comment #3)
> Note that on darwin libgcc handles its symbol map using...
> 
>  -Wl,-exported_symbols_list,$(SHLIB_MAP) 
> 
> on SHLIB_LINK.

So I tried this, replacing $(SHLIB_MAP) with $(srcdir)/jit/libgccjit.map (since
SHLIB_MAP seemed to not be defined), and it gave me the following warning:

ld: warning: missing line-end at end of file "../../gcc/jit/libgccjit.map"

...followed by a bunch of undefined symbol errors (which were the real
problem). So instead I had to just remove the mapfile line entirely, as in the
patch in the blog post linked to from here:

(In reply to David Malcolm from comment #7)
> (In reply to howarth from comment #6)
> > I don't believe this can be an issue on darwin as we always default to
> > producing PIC oode.
> Ah, ok.
> 
> Thanks for filing this bug.
> 
> I'm wondering what other problems libgccjit has on darwin.  If you hack in
> the required options into jit/Makefile.in, to what extent do "make" and
> "make check-jit" work?
> 
> I notice this blog post from a couple of months ago:
>   http://adek.io/2014/10/04/gcc-jit-on-osx/
> which talks about an issue with:
>   dyld: Library not loaded: libgccjit.so.0
> 
> Perhaps on darwin we need to be setting DYLD_LIBRARY_PATH in the various
> places where we're currently setting LD_LIBRARY_PATH?  (perhaps that should
> be a separate bug, perhaps under a "libgccjit on darwin" tracker bug?).

So anyways, besides what I wrote above, for some reason I also had to add
"-Wl,-undefined,dynamic_lookup" due to the "environ" symbol being missing,
which makes no sense to me, because it should be there... But that got it to
build for me though.

And as for running "make check-jit", well, that testsuite didn't even run due
to it failing with:

ERROR: tcl error sourcing
/Users/ericgallager/gcc-git/gcc/testsuite/jit.dg/jit.exp.
ERROR: sh: /Users/ericgallager/gcc-git/libstdc++-v3/scripts/testsuite_flags: No
such file or directory

...which seems wrong to me. Shouldn't the testsuite_flags script be generated
in the builddir instead of in the srcdir? But anyways, that's digressing, and
unrelated to the linkage failure that the ticket was originally about.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #9 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(In reply to Eric Gallager from comment #8)
> So anyways... for some reason I also had to add
> "-Wl,-undefined,dynamic_lookup" due to the "environ" symbol being missing,
> which makes no sense to me, because it should be there... But that got it to
> build for me though.
> 

Actually disregard that part; turns out that that was bug 63758...

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

--- Comment #10 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
FWIW, homebrew has a formula for building libgccjit on OS X:
 https://github.com/Homebrew/homebrew/blob/master/Library/Formula/gcc.rb

Currently it applies this patch:

diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
index 44d0750..4df2a9c 100644
--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -85,8 +85,7 @@ $(LIBGCCJIT_FILENAME): $(jit_OBJS) \
             $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \
             $(CPPLIB) $(LIBDECNUMBER) $(LIBS) $(BACKENDLIBS) \
             $(EXTRA_GCC_OBJS) \
-            -Wl,--version-script=$(srcdir)/jit/libgccjit.map \
-            -Wl,-soname,$(LIBGCCJIT_SONAME)
+            -Wl,-install_name,$(LIBGCCJIT_SONAME)

 $(LIBGCCJIT_SONAME_SYMLINK): $(LIBGCCJIT_FILENAME)
        ln -sf $(LIBGCCJIT_FILENAME) $(LIBGCCJIT_SONAME_SYMLINK)

along with this patch:
  https://gcc.gnu.org/ml/jit/2015-q3/msg00148.html
which is in:
  trunk as r226882.
  gcc-5-branch as r226883.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[mrs at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #11 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
I'd endorse that step forward.  The export list I think is also doable in some
fashion, but we can leave that for another day.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
                 CC|                            |egallager at gcc dot gnu.org
             Status|ASSIGNED                    |RESOLVED

--- Comment #23 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #22)
> (In reply to Eric Gallager from comment #20)
> > (In reply to mrs@gcc.gnu.org from comment #19)
> > > I'm fine with Backporting for affected branches.
> > 
> > So... that's still 6 and 7 at this point?
> 
> Er well just 7 now, since 6 is closed

7 is closed now, too, so I think that's all affected branches closed, meaning
this ought to be fixed on all open branches... closing as FIXED.