[llvm-dev] unable to compile llvm with gcc 4.7.4

Wed Oct 12 15:51:07 PDT 2016

Stable releases don't upgrade the toolchain because the whole system is
guaranteed to be stable under a single combination of the compiler,
libraries, tools, headers, secondary libraries, etc.

Validation of a new toolchain means releasing a whole new distro, with old
packages, but they're busy validating new releases, too.

The gcc abi 5 issue is on recent event that you could have a read to
understand what kinds of problems can happen.

Windows just duplicates all libraries and each app is independent. You can
use different compilers, but you end up with a big list of dlls all over
the place, and compatibility is never guaranteed.

How Steam has hacked Linux support is a good example of Windows style on
Linux, and the quality you get is a good reason not to follow that path.

They're just different models, with different constraints. If we were a
distro, trying to change the status quo would be fun. We don't have that
bandwidth, so we just do what everyone else is doing. :-)

Cheers,
Renato

On 12 Oct 2016 11:40 p.m., "Pete Cooper" <peter_cooper at apple.com> wrote:

>
> On Oct 12, 2016, at 3:33 PM, Renato Golin <renato.golin at linaro.org> wrote:
>
> Hi Peter,
>
> We don't ship proper toolchains for distros, we ship toys that worked on
> one developer's machine, and that includes our binaries as well.
>
> Ok, thats fair.  Having never actually downloaded one, I didn’t know the
> state of it.
>
> Out of interest, are newer toolchains available from apt-get and other
> similar package managers?  The only part of supporting linux/BSD in this
> way I question is that we end up stuck with whatever shipped with the OS,
> not what may be available via their package managers.  If the available
> packages are also old GCC versions then fair enough, but I just want to
> understand the ecosystem.
>
> Distro validation is a huge deal, especially toolchain, and we're in no
> way equipped to even try to do a bad job at that.
>
> Unix is a different world than that of Windows and Mac, and it makes no
> sense to force the same requirements, either way.
>
> I guess I already alluded to this, but if a package is available in the
> same way that a new Xcode/MSVC is available, then i’m not sure why we
> should treat it differently.
>
> I don't opine on msvc or xcode topics or design decisions because I don't
> know enough to have any reasonable opinion, and I most certainly won't try
> to make them more like Unix.
>
> You should.  We need plenty of voices to make sure we make the best
> decisions we can.  Incidentally, i’ve built GCC in a past life on the
> PlayStation 2 Linux environment.  I’m somewhat aware of the pain, although
> that was quite a time ago.
>
> These things are what they are for good reasons and I think we should just
> leave it at that.
>
> Cheers,
> Renato
>
> PS: I don't mean disrespect either, but we have this discussion every time
> someone mentions upgrading gcc.
>
> None taken.
>
> Maybe we should write some documentation to avoid repeating the same
> arguments. :-)
>
> SGTM.  I’m willing to admit my almost complete ignorance in all things
> linux/BSD, so to have it written down somewhere and avoid the next person
> like me asking would be good.
>
> Cheers,
> Pete
>
>
>
> On 12 Oct 2016 11:19 p.m., "Pete Cooper via llvm-dev" <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> On Oct 11, 2016, at 1:46 PM, Michael Kuperstein via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> To the best of my understanding - because we want to be able to bootstrap
>> clang with the system compiler that ships with various linux and BSD
>> distributions.
>> Windows has no equivalent concept.
>>
>> I mean no offense to linux/BSD developers, but should we have a
>> discussion (in another thread perhaps) about whether its reasonable to
>> treat them specially in this regard?
>>
>> Both macOS and Windows developers need to download compilers separately
>> to be LLVM developers.  Why shouldn’t linux/BSD developers?
>>
>> Given that we ship prebuilt binaries for many distros, it seems like its
>> easy to get a new enough compiler.  This way we won’t be faced with the
>> problem of old GCCs holding us back in future.
>>
>> Pete
>>
>>
>> (This is probably not a good enough reason to keep GCC 4.7 support, but
>> it apparently is for GCC 4.8).
>>
>> Michael
>>
>> On Tue, Oct 11, 2016 at 10:28 AM, Martin J. O'Riordan via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Why is it more important to be backward compatible with ancient versions
>>> of GCC than relatively more recent versions of Visual Studio?  We are
>>> removing support for VS2013 because of defects in that product, yet GCC
>>> v4.7.x is more ancient than VS2013, so why should the answer be any
>>> different?
>>>
>>> Devil's Advocate,
>>>
>>>         MartinO
>>>
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>>> Renato Golin via llvm-dev
>>> Sent: 11 October 2016 18:01
>>> To: Sylvain Bertrand <sylvain.bertrand at gmail.com>
>>> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Peter Collingbourne <
>>> pcc at google.com>
>>> Subject: Re: [llvm-dev] unable to compile llvm with gcc 4.7.4
>>>
>>> On 11 October 2016 at 17:35,  <sylvain.bertrand at gmail.com> wrote:
>>> > Those bots should have been the first to be set up. Hope you can fix
>>> this soon.
>>>
>>> We had 4.7 bots for a long time, but migrations happen, and we probably
>>> (separately) didn't expect to be the last 4.7 ones. This was a coordination
>>> problem.
>>>
>>> Now, there are talks to upgrade the GCC version from 4.7, but we can't
>>> do 4.9 because many stable distributions still 4.8, but we can do 4.8,
>>> which has enough buildbots (and will for the long term).
>>>
>>> I'm not saying this is a "fix" for your problem, but your problem would
>>> happen any time soon when we move the GCC version up anyway.
>>>
>>> Can you upgrade to 4.8?
>>>
>>> cheers,
>>> --renato
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/633db07b/attachment-0001.html>