Hi! On Tue, 28 Oct 2014 13:23:50 +0100, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Oct 28, 2014 at 11:47:31AM +0000, Phil Muldoon wrote: > > I think I have a solution. Though my automake fu is very weak. Does > > this patch work for you? I'm really not sure how to deal with the > > three possible versions of libiberty any other way. > > That is insufficient, > a) you don't filter away -fsanitize=address, which would make it > unusable in gdb > b) without the -Wc, stuff, you get the ugly libtool warnings > c) the LTLDFLAGS mess is needed for libtool not eating the -Wc, stuff
> So I'm proposing my patch (which is modeled after lto-plugin changes by
> myself and others), [...]
(Maybe we should now turn that into generic infrastructure?)
> 2014-10-28 Jakub Jelinek <ja...@redhat.com>
>
> * Makefile.am (CXXFLAGS, LDFLAGS): Filter out -fsanitize=address.
> (libiberty_normal, libiberty_noasan, libiberty_pic, libiberty_dep):
> New variables.
> (libiberty): Set to -Wc, followed by the first existing noasan/,
> pic/ or . libiberty.a.
> (libcc1plugin_la_DEPENDENCIES, libcc1plugin_la_LINK,
> libcc1_la_DEPENDENCIES, libcc1_la_LINK, LTLDFLAGS): New variables.
> * Makefile.in: Regenerated.
;-) To re-use your words: »That is insufficient«, d) in a configuration
where there is no lto-plugin built, we now try to link the shared libcc1
against a static libiberty:
/bin/bash ./libtool --tag=CXX --mode=link g++ -m64 [...] -module
-export-symbols [...]/source-gcc/libcc1/libcc1.sym -Xcompiler
'-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath
/lib/../lib64 findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo
marshall.lo -Wc,../libiberty/libiberty.a
libtool: link: g++ -m64 [...] -shared -nostdlib [...]/crti.o
[...]/crtbeginS.o .libs/findcomp.o .libs/libcc1.o .libs/names.o
.libs/callbacks.o .libs/connection.o .libs/marshall.o [...] -lstdc++ -lm -lc
-lgcc_s [...]/crtendS.o [...]/crtn.o -m64 [...] -static-libstdc++
-static-libgcc ../libiberty/libiberty.a -Wl,-soname -Wl,libcc1.so.0
-Wl,-retain-symbols-file -Wl,[...]/source-gcc/libcc1/libcc1.sym -o
.libs/libcc1.so.0.0.0
[...]/ld: ../libiberty/libiberty.a(regex.o): relocation R_X86_64_32S
against `.rodata' can not be used when making a shared object; recompile with
-fPIC
../libiberty/libiberty.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[3]: *** [libcc1.la] Error 1
make[3]: Leaving directory `[...]/build-gcc/libcc1'
make[2]: *** [all] Error 2
make[2]: Leaving directory `[...]/build-gcc/libcc1'
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory `[...]/build-gcc'
make: *** [all] Error 2
Here is a patch that I'm testing; OK? I didn't understand what the
conditions are that libcc1 might not be built as a shared library: is it
always built as one -- but is that really supported on all systems? If
that's indeed true, then this could be further simplified, and
--enable-shared passed to the host libiberty unconditionally.
--- configure.ac
+++ configure.ac
@@ -1865,7 +1865,6 @@ if test -d ${srcdir}/gcc; then
new_enable_languages=,c,
# If LTO is enabled, add the LTO front end.
- extra_host_libiberty_configure_flags=
if test "$enable_lto" = "yes" ; then
case ,${enable_languages}, in
*,lto,*) ;;
@@ -1873,10 +1872,8 @@ if test -d ${srcdir}/gcc; then
esac
if test "${build_lto_plugin}" = "yes" ; then
configdirs="$configdirs lto-plugin"
- extra_host_libiberty_configure_flags=--enable-shared
fi
fi
- AC_SUBST(extra_host_libiberty_configure_flags)
missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e
s/,c,/,/ `
potential_languages=,c,
@@ -2190,6 +2187,17 @@ then
esac
fi
+# Sometimes we have special requirements for the host libiberty.
+extra_host_libiberty_configure_flags=
+case " $configdirs " in
+ *" lto-plugin "* | *" libcc1 "*)
+ # When these are to be built as shared libraries, the same applies to
+ # libiberty.
+ extra_host_libiberty_configure_flags=--enable-shared
+ ;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
# Produce a warning message for the subdirs we can't configure.
# This isn't especially interesting in the Cygnus tree, but in the individual
# FSF releases, it's important to let people know when their machine isn't
Grüße,
Thomas
pgpGV3unSIXFJ.pgp
Description: PGP signature
