llvm dev - Oct 2016 - unable to compile llvm with gcc 4.7.4

On Wed, Oct 12, 2016 at 07:15:39PM +0100, Renato Golin
wrote:
> On 12 October 2016 at 18:37,  <sylvain.bertrand at gmail.com> wrote:
> > Suggestion is not clear answer. How such a decision taken? Is there a
board of
> > people which have to vote to valid the choice of minimal gcc (and
clang) version
> > effective?
> 
> We don't have such process, unfortunately. :)
> 
> 
> > If gcc 4.7 (last 1-step C boostrap-able c++-ish compiler) is phased
out, then,
> > to bootstrap llvm from a C compiler/runtime, gcc(4.7.4) +
gcc(version>=4.8)
> > will have to be setup first.
> 
> I want to understand your constraints, as I think this is a unique
> case that I wasn't considering.
It's my custom distro. My goal is to make it boostrap-able with tinycc (or
any
little C compiler alternative) as a one-man reasonable job. With the removal of
gcc 4.7 support now official, I would need to have a 3 step bootstrap, adding a
modern gcc (which is guaranted to compile with iso c++98-ish gcc 4.7.4, feature
that clang cannot guaranted anymore).

I'm targetting llvm only for its AMDGPU backend (AMD southern island GPU
architecture). Hacking the build system made me manage to compile llvm libs
with gcc 4.7.4:
	- I removed libLTO, all tools except llvm-config.
	- all tools except llvm-config.
Till mesa compiles and runs fine, I don't care about the rest of llvm.

----

BTW, the llvm build system is kind of weird. libLTO and tools are llvmbuild.txt
components, I though I could deal only with llvmbuild.txt files to disable them,
but
I had to deal with CMakefile.txt files too. Expected?

-- 
Sylvain

On 13 October 2016 at 12:56,  <sylvain.bertrand at gmail.com>
wrote:
> It's my custom distro. My goal is to make it boostrap-able with tinycc
(or any
> little C compiler alternative) as a one-man reasonable job. With the
removal of
> gcc 4.7 support now official, I would need to have a 3 step bootstrap,
adding a
> modern gcc (which is guaranted to compile with iso c++98-ish gcc 4.7.4,
feature
> that clang cannot guaranted anymore).
Hi Sylvain,

I have to say, after a while thinking about your use case, I cannot
come up with a better solution than a 3-stage build. :(

Maybe you need to step back a bit and ask yourself: what would be the
system changes to adopt GCC 4.8 natively instead of tinycc.

What distributions do is to compile the base GCC they'll use first,
making sure all the correct libraries in all the correct versions are
bundles in the right places, then use that toolchain for *everything*.

You seem comfortable enough building GCC 4.7, I assume as a side
package, like BSD ports. I'm also assuming you already need GCC (for
packages other than LLVM), then why not make GCC your system compiler?

The dependencies will already be there anyway, and I don't think GCC
4.8's libraries are much bigger than 4.7, so it does seem like an
overall gain.

Of course, it'll mean you'll have to test your packages with GCC 4.8,
but assuming they already use tinycc or GCC 4.7, I hope you'll have
very little additional problems.

Would any of that help?

cheers,
--renato

Hi,

The problem is modern c++. I can have a reasonable system boostrape-ed
with (tinycc/alternative C compiler), but only in the gcc world since
a modern c++ compiler is only bootsrape-able from near any C compiler
there. clang and llvm are unable to do it. That why I would need to
get 2 gccs: "any C compiler" -> gcc 4.7.4 -> gcc recent_version
->
llvm.

On Fri, Oct 14, 2016 at 4:02 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 13 October 2016 at 12:56,  <sylvain.bertrand at gmail.com> wrote:
>> It's my custom distro. My goal is to make it boostrap-able with
tinycc (or any
>> little C compiler alternative) as a one-man reasonable job. With the
removal of
>> gcc 4.7 support now official, I would need to have a 3 step bootstrap,
adding a
>> modern gcc (which is guaranted to compile with iso c++98-ish gcc 4.7.4,
feature
>> that clang cannot guaranted anymore).
>
> Hi Sylvain,
>
> I have to say, after a while thinking about your use case, I cannot
> come up with a better solution than a 3-stage build. :(
>
> Maybe you need to step back a bit and ask yourself: what would be the
> system changes to adopt GCC 4.8 natively instead of tinycc.
>
> What distributions do is to compile the base GCC they'll use first,
> making sure all the correct libraries in all the correct versions are
> bundles in the right places, then use that toolchain for *everything*.
>
> You seem comfortable enough building GCC 4.7, I assume as a side
> package, like BSD ports. I'm also assuming you already need GCC (for
> packages other than LLVM), then why not make GCC your system compiler?
>
> The dependencies will already be there anyway, and I don't think GCC
> 4.8's libraries are much bigger than 4.7, so it does seem like an
> overall gain.
>
> Of course, it'll mean you'll have to test your packages with GCC
4.8,
> but assuming they already use tinycc or GCC 4.7, I hope you'll have
> very little additional problems.
>
> Would any of that help?
>
> cheers,
> --renato