This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 5/5] add libcc1


On Tue, 28 Oct 2014 13:23:50 +0100, Jakub Jelinek <> 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  <>
> 	* (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.
> 	* 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 -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, -Wl,-retain-symbols-file -Wl,[...]/source-gcc/libcc1/libcc1.sym -o .libs/
    [...]/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]: *** [] 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.

@@ -1865,7 +1865,6 @@ if test -d ${srcdir}/gcc; then
   # 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
     if test "${build_lto_plugin}" = "yes" ; then
       configdirs="$configdirs lto-plugin"
-      extra_host_libiberty_configure_flags=--enable-shared
-  AC_SUBST(extra_host_libiberty_configure_flags)
   missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e s/,c,/,/ `
@@ -2190,6 +2187,17 @@ then
+# Sometimes we have special requirements for the host libiberty.
+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
+    ;;
 # 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


Attachment: pgpP3aRYa5YYy.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]