This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 5/5] add libcc1
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Dominique Dhumieres <dominiq at lps dot ens dot fr>, gcc-patches at gcc dot gnu dot org, tromey at redhat dot com, law at redhat dot com
- Date: Tue, 28 Oct 2014 10:06:12 +0100
- Subject: Re: [PATCH 5/5] add libcc1
- Authentication-results: sourceware.org; auth=none
- References: <20141028000500 dot 80D44100 at mailhost dot lps dot ens dot fr> <20141028081301 dot GA10376 at tucnak dot redhat dot com> <544F5737 dot 1080803 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 28, 2014 at 08:43:35AM +0000, Phil Muldoon wrote:
> On 28/10/14 08:13, Jakub Jelinek wrote:
> > On Tue, Oct 28, 2014 at 01:05:00AM +0100, Dominique Dhumieres wrote:
> >>> This patch has now been committed.
> >> It breaks bootstap on x86_64-apple-darwin14:
> >>
> >> ...
> >> make[3]: Entering directory `/opt/gcc/p_build/libcc1'
> >> make all-am
> >> make[4]: Entering directory `/opt/gcc/p_build/libcc1'
> >> make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed by `libcc1.la'. Stop.
> >> make[4]: Leaving directory `/opt/gcc/p_build/libcc1'
> >> make[3]: *** [all] Error 2
> >> make[3]: Leaving directory `/opt/gcc/p_build/libcc1'
> >> make[2]: *** [all-stage1-libcc1] Error 2
> >> make[2]: Leaving directory `/opt/gcc/p_build'
> >> make[1]: *** [stage1-bubble] Error 2
> >> make[1]: Leaving directory `/opt/gcc/p_build'
> >> make: *** [all] Error 2
> > There are other issues related to --with-build-config=bootstrap-{a,ub}san
> > in there too, my current WIP patch is but didn't get to test it yet.
>
> Apologies. I am investigating the issue, though I am not entirely sure of why the issue with libiberty occurs.
I think I have the libiberty issues solved in my patch, just hit another
issue (visibility related) in my -fsanitize=vptr patch which I've been
bootstrapping it with, so had to fix that and am now trying again.
The thing with libiberty is that we have one to 3 versions of libiberty,
e.g. on targets where there is no pic support or where -fpic is on by
default libiberty doesn't build the pic/ version, and the noasan/ version
is built for --with-build-config=bootstrap-asan builds, so that one can
choose libiberty instrumented -fsanitize=address (the normal one or pic if
the latter exists) and pic non-instrumented one (for use in lto-plugin and
supposedly libcc1 too), anything that can be loaded into some other program
than gcc should not be asan instrumented, because it requires the executable
to be linked that way too (e.g. linker or gdb).
Jakub