Re: [PATCH 5/5] add libcc1

[Jeff Law <law@redhat.com>]

On 10/28/14 06:23, 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
>
> I've in the mean time successfully bootstrapped/regtested my patch on
> i686-linux (--with-build-config=bootstrap-ubsan), that was build without
> ada, on x86_64-linux the build failed because of some recent ada vs.
> bootstrap-ubsan incompatibilities unrelated to libcc1 (but libcc1 built
> fine).
>
> So I'm proposing my patch (which is modeled after lto-plugin changes by
> myself and others), with the -Werror stuff handled separately as follow-up.
> Ok for trunk?
>
> 2014-10-28  Jakub Jelinek  <jakub@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.
Ick.    But OK I guess.

jeff