[gentoo-dev] status of bugs blocking gcc-4.8.3

[gentoo-dev] status of bugs blocking gcc-4.8.3

[Anthony G. Basile]

Hi everyone,

Regarding blockers against bug  #461954 "(gcc-4.8) GCC 4.8 porting" and  
bug #516152 "(gcc-4.8-stable) sys-devel/gcc-4.8.? stabilization" here is 
the current situation:

bug #516548 - (PR61538) broken atomic on MIPS R10000
-> As far as I can tell, this only effects R10000.  It does not effect 
the fulong or longson (lemote netbooks), nor some other router boards i 
have.

bug #503838 - (PR60465) sys-libs/glibc: building w/gcc-4.8 crashes early 
on ia64
-> This effects only ia64.

bug #500064 - app-emulation/virtualbox-4.3.6 fails to build with gcc 
4.8.x in bundled iPXE
-> Poly-C wants to stabilize these along side gcc-4.8.

bug #465268 - dev-embedded/msp430-gcc-4.6.3_p20120406 with gcc-4.8.0
-> This is working with gcc-4.9 and doesn't need to hold up 4.8.

bug 458706 - PaX: Max. per-task virtual memory too small for llvm asan 
and gcc-4.8 asan
-> AddressSanitizer doesn't work with a PaX hardened kernel. Nor does it 
work on several arches nor on musl.  vapier has done some masking here.

bug 513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so: 
undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
-> This is a problem.  It relates to abi mismatching with libstdc++.  
The bug details how you can hit it in gentoo. Martin von Gagern pushed 
the issue upstream and pretty much got the answer "we're on our own"  So 
we'll have to deal with this as we go forward.
Seehttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758

So except for some minor arch issue and bug 513386, which we're going to 
have to deal with for a while, gcc-4.8.3 looks good.  I went ahead and 
stabilized it on ppc and ppc64.  Its also stable on arm and hppa.  I 
don't want to speak for any other arch teams, but it may be time.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Luca Barbato]

On 24/10/14 19:12, Anthony G. Basile wrote:
> bug 513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so:
> undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> -> This is a problem.  It relates to abi mismatching with libstdc++.

The ABI mismatch is due the library not being versioned properly as "usual"?

> The bug details how you can hit it in gentoo. Martin von Gagern pushed
> the issue upstream and pretty much got the answer "we're on our own"  So
> we'll have to deal with this as we go forward.
> Seehttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758

Not sure if the llvm C++ runtime might help here or it is any better
than the one provided by gnu, but might be a good time to gather
volunteers to provide a mean to use clang as main compiler out of box.

Being on your own is not an answer I like to hear. Nor the whole
approach to the discussion.

lu

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Matthias Maier]

> Not sure if the llvm C++ runtime might help here or it is any better
> than the one provided by gnu, but might be a good time to gather
> volunteers to provide a mean to use clang as main compiler out of box.

libc++ makes stricter ABI guarantees [1]. But from personal experience I
would not consider it a replacement for libstdc++ in the near future.

I have set up some lxc containers with clang/libc++ with promising
results (and I plan to keep up testing with it once in a while).

Best,
Matthias

[1] http://clang-developers.42468.n3.nabble.com/libc-ABI-stability-td2976682.html

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Luca Barbato]

On 25/10/14 13:09, Matthias Maier wrote:
> 
>> Not sure if the llvm C++ runtime might help here or it is any better
>> than the one provided by gnu, but might be a good time to gather
>> volunteers to provide a mean to use clang as main compiler out of box.
> 
> libc++ makes stricter ABI guarantees [1]. But from personal experience I
> would not consider it a replacement for libstdc++ in the near future.

Probably we could join forces with FreeBSD to help pushing fixes to
applications upstream.

> I have set up some lxc containers with clang/libc++ with promising
> results (and I plan to keep up testing with it once in a while).

Could you please blog or add some notes to the wiki about it?

lu

[gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Matthias Maier]

>
> Could you please blog or add some notes to the wiki about it?
>

I've put up a preliminary version for the toolchain part:

  https://gist.github.com/tamiko/7e3a0be806fac11f2a35

Best,
Matthias

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Alexis Ballier]

By the way, any help for maintaining the libc++ stack is very welcome;
as you can see from the age of the current snapshots, it's been some
time I've not been playing with it.


Some notes:
- why not adding a clang subprofile ? there's one for amd64-fbsd; I had
  been able to build a complete stage 3 without too much trouble.
  There's probably nothing bsd specific there, so moving
  generic code from there to profiles/features should work.
- it'd be worth fixing/improving libunwind support, esp. as you write
  here on the clang 'spec' parts; I don't remember if there were other
  issues, but it was a bit pointless if we can't get rid of libgcc_s
  because of clang (maybe there were even symbol collisions?)
- libcxxabi is probably the new way to go instead of libcxxrt; last
  time I checked there was a chicken and egg problem: libcxxabi needed
  clang + libc++ to build, so bootstrapping the stack was a bit
  painful.
- there are a few todos in libcxx ebuild (mainly libsupc++ support, but
  the same could apply to libcxxabi)
- it'd be interesting to have stand-alone ebuilds for gcc's crt files;
  or better, find BSD-like alternatives

Alexis.

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Peter Stuge]

Alexis Ballier wrote:
> - why not adding a clang subprofile ? there's one for amd64-fbsd; I had
>   been able to build a complete stage 3 without too much trouble.
>   There's probably nothing bsd specific there, so moving
>   generic code from there to profiles/features should work.

I'd try to test that at some point.


//Peter

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[M. Ziebell]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Does clang compile glibc already?
At the last GNU Cauldron the speaker said that clang fails because
of:[1]
- nested functions
- VLAIS 

How did you avoid that problem?


Marco

[1]
http://www.youtube.ca/watch?v=mmiDwKgn6Ho&list=PLOGTP9W1DX5U53pPxtWdKkyiqe3GAn6Nd

Am Mon, 27 Oct 2014 11:20:00 +0100
schrieb Peter Stuge <peter@stuge.se>:

> Alexis Ballier wrote:
> > - why not adding a clang subprofile ? there's one for amd64-fbsd; I
> > had been able to build a complete stage 3 without too much trouble.
> >   There's probably nothing bsd specific there, so moving
> >   generic code from there to profiles/features should work.
> 
> I'd try to test that at some point.
> 
> 
> //Peter
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Alexis Ballier]

On Mon, 27 Oct 2014 12:07:25 +0100
"M. Ziebell" <ziebell_marco@posteo.de> wrote:

> Does clang compile glibc already?
> At the last GNU Cauldron the speaker said that clang fails because
> of:[1]
> - nested functions
> - VLAIS 
> 
> How did you avoid that problem?


by using freebsd's libc :)


only problem I can recall is openssl which has been fixed recently afaik

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[M. Ziebell]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Am Mon, 27 Oct 2014 12:10:51 +0100
schrieb Alexis Ballier <aballier@gentoo.org>:

> On Mon, 27 Oct 2014 12:07:25 +0100
> "M. Ziebell" <ziebell_marco@posteo.de> wrote:
> 
> > Does clang compile glibc already?
> > At the last GNU Cauldron the speaker said that clang fails because
> > of:[1]
> > - nested functions
> > - VLAIS 
> > 
> > How did you avoid that problem?
> 
> 
> by using freebsd's libc :)
> 
> 
> only problem I can recall is openssl which has been fixed recently
> afaik
> 

So glibic is a show stopper or we talk about switching the libc too?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Alexis Ballier]

On Mon, 27 Oct 2014 12:29:40 +0100
"M. Ziebell" <ziebell_marco@posteo.de> wrote:

> Am Mon, 27 Oct 2014 12:10:51 +0100
> schrieb Alexis Ballier <aballier@gentoo.org>:
> 
> > On Mon, 27 Oct 2014 12:07:25 +0100
> > "M. Ziebell" <ziebell_marco@posteo.de> wrote:
> > 
> > > Does clang compile glibc already?
> > > At the last GNU Cauldron the speaker said that clang fails because
> > > of:[1]
> > > - nested functions
> > > - VLAIS 
> > > 
> > > How did you avoid that problem?
> > 
> > 
> > by using freebsd's libc :)
> > 
> > 
> > only problem I can recall is openssl which has been fixed recently
> > afaik
> > 
> 
> So glibic is a show stopper or we talk about switching the libc too?


it is, but you are the one talking about glibc, I was talking about
gentoo/freebsd :)

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Matthias Maier]

Am 27. Oct 2014, 12:07 schrieb "M. Ziebell" <ziebell_marco@posteo.de>:

> Does clang compile glibc already?
> At the last GNU Cauldron the speaker said that clang fails because
> of:[1]
> - nested functions
> - VLAIS 
>
> How did you avoid that problem?

Even without this issues there remains the fact that glibc is quite
closely coupled to gcc's support libraries (e.g.
$ grep "dlopen.*gcc_" **/*.c, or pthread's usage of support
libraries...). And this is something that won't change anytime
soon. After all, glibc is part of the GNU eco system and as such it is
perfectly valid to depend on respective compiler.

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Luca Barbato]

On 27/10/14 12:07, M. Ziebell wrote:
> Does clang compile glibc already?
> At the last GNU Cauldron the speaker said that clang fails because
> of:[1]
> - nested functions
> - VLAIS
>
> How did you avoid that problem?

musl is known to work fine.

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Marco Ziebell]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

Am Wed, 29 Oct 2014 13:39:33 +0100
schrieb Luca Barbato <lu_zero@gentoo.org>:

> On 27/10/14 12:07, M. Ziebell wrote:
> > Does clang compile glibc already?
> > At the last GNU Cauldron the speaker said that clang fails because
> > of:[1]
> > - nested functions
> > - VLAIS
> >
> > How did you avoid that problem?
> 
> musl is known to work fine.
> 
> 

True. A good point for the (sub)profile idea.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

[Matthias Maier]

Am 27. Oct 2014, 11:14 schrieb Alexis Ballier <aballier@gentoo.org>:

> By the way, any help for maintaining the libc++ stack is very welcome;
> as you can see from the age of the current snapshots, it's been some
> time I've not been playing with it.
>
>
> Some notes:
> - why not adding a clang subprofile ? there's one for amd64-fbsd; I had
>   been able to build a complete stage 3 without too much trouble.
>   There's probably nothing bsd specific there, so moving
>   generic code from there to profiles/features should work.

Yes, it looks fairly generic. This is definitely worth a try.

> - it'd be worth fixing/improving libunwind support, esp. as you write
>   here on the clang 'spec' parts; I don't remember if there were other
>   issues, but it was a bit pointless if we can't get rid of libgcc_s
>   because of clang (maybe there were even symbol collisions?)
> - libcxxabi is probably the new way to go instead of libcxxrt; last
>   time I checked there was a chicken and egg problem: libcxxabi needed
>   clang + libc++ to build, so bootstrapping the stack was a bit
>   painful.

The Toolchain behavior on GNU/Linux is fairly tailored to using gcc at
the moment (just grep for gcc_ on
tools/clang/lib/Driver/{Tools|Toolchain}.cpp).

In order to really pull off a clang/libc++ toolchain independent of gcc
assistance would involve quite a bunch of (preferably upstream) work...

> - there are a few todos in libcxx ebuild (mainly libsupc++ support, but
>   the same could apply to libcxxabi)
> - it'd be interesting to have stand-alone ebuilds for gcc's crt files;
>   or better, find BSD-like alternatives
>
> Alexis.

Best,
Matthias

Re: [gentoo-dev] Clang toolchain

[Matthias Maier]

> - libcxxabi is probably the new way to go instead of libcxxrt; last
>   time I checked there was a chicken and egg problem: libcxxabi needed
>   clang + libc++ to build, so bootstrapping the stack was a bit
>   painful.

I give libcxxabi a try.

Does anybody has a bit insight in the current status of the llvm's
bundled libunwind in libcxxabi, i.e. is it trivially portable?

If yes, this might clean up the dependency chain quite a bit.

Best,
Matthias

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Jan Kundrát]

On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote:
> The ABI mismatch is due the library not being versioned properly as "usual"?

Please note that this would be a "hard thing to do". This is not just a 
matter of calling an appropriate version of a given function; there are no 
guarantees about the internal layout of the data structures, etc. 
Furthermore, portions of C++ code might be inlined, so whenever you have a 
library compiled with different GCC versions, these cannot exchange any 
data which embed a C++11 data type inside. That's quite a bummer -- 
std::string and std::list have both changed in C++11 (forbidden 
ref-counting of std::string and O(1) size of std::list::size()). The 
upstream's promise is that the ABI will eventually ebcome stable when they 
remove the "experimental" label on their C++11 support.

I suspect that the only solution would be a full ABI version number change 
at that time, though, and people want to avoid doing this because that will 
of course break all C++ programs out there. It would be terrific if the GCC 
guys provided a reasonable roadmap, because saying "we support C++11" while 
also saying "don't combine code built by 4.7 and 4.8, that's totally 
unsupported" is a bit strange. Yes, limited time and limited manpower and 
what not, but it's still something which makes using all of the C++11 
features a very risky business.

Cheers,
Jan

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Luca Barbato]

On 30/10/14 15:06, Jan Kundrát wrote:
> On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote:
>> The ABI mismatch is due the library not being versioned properly as
>> "usual"?
>
> Please note that this would be a "hard thing to do". This is not just a
> matter of calling an appropriate version of a given function; there are
> no guarantees about the internal layout of the data structures, etc.
> Furthermore, portions of C++ code might be inlined, so whenever you have
> a library compiled with different GCC versions, these cannot exchange
> any data which embed a C++11 data type inside. That's quite a bummer --
> std::string and std::list have both changed in C++11 (forbidden
> ref-counting of std::string and O(1) size of std::list::size()). The
> upstream's promise is that the ABI will eventually ebcome stable when
> they remove the "experimental" label on their C++11 support.
>
> I suspect that the only solution would be a full ABI version number
> change at that time, though, and people want to avoid doing this because
> that will of course break all C++ programs out there. It would be
> terrific if the GCC guys provided a reasonable roadmap, because saying
> "we support C++11" while also saying "don't combine code built by 4.7
> and 4.8, that's totally unsupported" is a bit strange. Yes, limited time
> and limited manpower and what not, but it's still something which makes
> using all of the C++11 features a very risky business.

And obviously providing libstdc++ and libstdc++11 (and matching headers) 
is not an option =\

_quite_ annoying indeed

lu - hoping rust won't have such issues.

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

[Rich Freeman]

On Fri, Oct 31, 2014 at 12:25 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
>
> lu - hoping rust won't have such issues.
>

Funny - I first heard of this earlier this week.  Biggest issue I see
with rust is that it seems like it has joined the
every-language-needs-its-own-package-manager club, and it seems to me
that it really encourages static linking.  The build system doesn't
seem particularly distro-friendly, let alone source-based
distro-friendly.

However, I have only spent about an hour learning about rust, so I'm
certainly interested if others know better.

I really like the concept though.  ADA has always been on my list of
things I'd love to spend time on someday, and Rust seems to be a more
modern take on the concept.

--
Rich