GCC 5 is coming with a massive rebuild

headkase · 2015-02-24 16:37:58

Scimmia wrote:

...chromium-pepper-flash...

Chromium Pepper Flash would be a big problem for myself. And perhaps even the official repo old-Flash might be affected too. I have Arch on my parents computers and they use it for playing Facebook Flash games. Grr.

Allan · 2015-02-24 16:45:16

> readelf -d /usr/lib/PepperFlash/libpepflashplayer.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

I don't see this as an issue - isn't flash run as a separate process these days?

progandy · 2015-02-24 16:45:52

headkase wrote:

Scimmia wrote:
...chromium-pepper-flash...
Chromium Pepper Flash would be a big problem for myself. And perhaps even the official repo old-Flash might be affected too. I have Arch on my parents computers and they use it for playing Facebook Flash games. Grr.

Since Fedora 23 will most likely use the new GCC 5, I believe that google will publish a working version for the new libraries. In the worst case it will include all necessary libraries in the package.

headkase · 2015-02-24 17:05:43

@Allan, are you saying that it isn't an issue? I'm not familiar enough with readelf to parse its output.

@progandy, I hope that that just works in the worst case. Because without Flash my parents computers either don't get updated or I have to put them back to Windows 7.

Scimmia · 2015-02-24 17:26:41

He's saying that as long as the process that's running flash doesn't load the new symbols, it will be fine. If something tries to load both the old and new symbols, it will cause problems.

Please correct me if I'm wrong.

Allan · 2015-02-24 17:32:19

That is what I was saying.

headkase · 2015-02-24 17:49:40

Ok, thank you Scimmia and Allan, I hope there are no issues with Pepper Flash. It is integral to my parents systems for their uses.

smirky · 2015-02-24 22:58:18

#offtopic
Can someone explain to me what is "Stage 4" for which GCC 5 is in right now according to news and gcc.gnu.org itself? As far as the documentation says, there are three stages and "Stage 3" is for closing the feature pushing and accepting only bug fixes for polishing before going stable. I don't see anything anywhere about "Stage 4".
#end_offtopic

I'm not sure for which to be more excited, GCC 5 getting close to being released or having all the clang compatibility kernel patches mainlined soon which would be quite interesting...

Last edited by smirky (2015-02-24 22:59:19)

MK13 · 2015-02-24 23:03:48

Also:
jdk
jmtpfs
phototonic
plexmediaserver
spotify
xpdf

bstaletic · 2015-02-24 23:18:02

I only have two aur packages requiring rebuld:
fbpdf-git
palemoon-beta

Jristz · 2015-02-24 23:55:46

codecs
grub-customizer
jdk
topmenu-qt-git

grub-customizer and topmenu-qt-git are rebuildables, codecs... no and jdk, I have no idea

aaroncaffrey · 2015-02-25 06:57:05

headkase wrote:

So, GCC 5 is coming. And everything that depends on its libraries will need to be rebuilt. So, when GCC 5 hits the repo pretty-well every package will be rebuilt and therefore be "new" to pacman. I am far from an expert in such things but, how will this be handled? There will no doubt be .pacnew files aplenty to deal with. To my untrained eye something to ease the transition would be to have a "package freeze" for about 1 week before GCC 5 hits to give everyone time to get their systems fully up-to-date including dealing with those .pacnew files. Then, when the switch is flipped, everyone could update their entire system, rebuild their affected AUR packages, and just delete all the .pacnew files as their configurations will already be valid.
That's what I suggest, anyone care to enlighten how the GCC 5 transition will actually happen? Especially in regards to files that the user must configure for their specific systems.

Pacbuilder , replace $packagename with $(pacman -Qqs)

mar04 · 2015-02-26 10:45:57

I remember reading on kernelnewbies that linux gained support for compiling with gcc5 in version 3.18. So what will happen to linux-lts? Will it be patched or dropped?

WorMzy · 2015-02-26 11:01:59

abiword-3.x-gtk2
aqemu-git
chromium-pepper-flash
comodo
easytag-gtk2
gsimplecal-git
palemoon-beta
pavucontrol-gtk2
rar
slim-git
slimlock-git
vworkspace-conector

Most of these aren't a problem and can simply be rebuilt. I wouldn't hold my breath on comodo releasing a gcc5-compatible binary though, I'm not sure if they're even aware that they still offer a Linux build (it's been exactly two years since the last release). vworkspace-conector might be problematic, but I rarely use that.

smirky · 2015-02-26 11:02:51

It definitely won't be dropped... Also, I don't see why it won't be able to compile with GCC5. As long as it's compiled with a compatible standard, the version shouldn't matter...

Allan · 2015-02-26 12:52:26

mar04 wrote:

I remember reading on kernelnewbies that linux gained support for compiling with gcc5 in version 3.18. So what will happen to linux-lts? Will it be patched or dropped?

Patched rather than dropped. Backporting patches for build fixes is allowable in Arch land.

clfarron4 · 2015-02-26 13:13:05

Allan wrote:

mar04 wrote:
I remember reading on kernelnewbies that linux gained support for compiling with gcc5 in version 3.18. So what will happen to linux-lts? Will it be patched or dropped?
Patched rather than dropped. Backporting patches for build fixes is allowable in Arch land.

Woop! I would have tried to myself if it wasn't going to be done.

Also, it would have been interesting to see Arch without a linux-lts package.

EDIT: Oh wait, that means that I'll have to do it for 3.12 and 3.10... XD *facepalm*

EDIT2 (response to below comment): I think the original query by @mar04 was about linux-lts in [core], not the lts31x packages I maintain.

Last edited by clfarron4 (2015-02-26 16:10:19)

smirky · 2015-02-26 13:23:21

No you wont. The AUR package maintainers would probably do that for you since those versions are there.

EDIT: Darn... I just saw that the maintainer is above me

Last edited by smirky (2015-02-26 13:24:17)

Awebb · 2015-02-26 13:25:51

smirky wrote:

No you wont. The AUR package maintainers would probably do that for you since those versions are there.
EDIT: Darn... I just saw that the maintainer is above me

Check the links in the signature for clarification.

chaonaut · 2015-02-27 13:50:31

interesting.
i'm trying to rebuild base & base-devel groups with gcc5 (using linux API headers 4.0-rc1) right now.
will write a few sentences here when it's done (either successfully or not).

UPDATE: no luck, glibc build fails.

MOAR UPDATE: but musl build succeeds

Last edited by chaonaut (2015-02-27 15:46:41)

Allan · 2015-02-27 20:17:23

chaonaut wrote:

UPDATE: no luck, glibc build fails.

Feel like providing details. Are they just new warnings failing due to Werror?

chaonaut · 2015-03-03 16:16:43

Allan wrote:

Feel like providing details. Are they just new warnings failing due to Werror?

well, it fails here:

gcc printf-parsewc.c -c -std=gnu99 -fgnu89-inline  --param=ssp-buffer-size=4 -O2 -Wall
 -Winline -Wundef -Wwrite-strings -fdiagnostics-color=always -fmerge-all-constants -frounding-math
 -march=x86-64 -mtune=native -pipe -Wstrict-prototypes  -fomit-frame-pointer -fPIC        -I../include
 -I/build/pkging/glibc/src/glibc-build/stdio-common  -I/build/pkging/glibc/src/glibc-build
 -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64 
 -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl
 -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
 -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64 
 -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch 
 -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu 
 -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/ldbl-96 
 -I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32 
 -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc
 -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/5.0.137066.c905381/include -isystem
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.0.137066.c905381/include-fixed -isystem /usr/include 
 -D_LIBC_REENTRANT -include /build/pkging/glibc/src/glibc-build/libc-modules.h -DMODULE_NAME=libc
 -include ../include/libc-symbols.h  -DPIC -DSHARED     -D_IO_MTSAFE_IO
 -o /build/pkging/glibc/src/glibc-build/stdio-common/printf-parsewc.os -MD -MP -MF
 /build/pkging/glibc/src/glibc-build/stdio-common/printf-parsewc.os.dt -MT
 /build/pkging/glibc/src/glibc-build/stdio-common/printf-parsewc.os
../sysdeps/gnu/siglist.c:72:1: internal compiler error: in address_matters_p, at symtab.c:1908
 versioned_symbol (libc, __new_sys_sigabbrev, sys_sigabbrev, GLIBC_2_3_3);

glibc 2.21, gcc 5.0.137066.c905381 20150227

Allan · 2015-03-03 21:45:58

That is gcc crashing...

smirky · 2015-03-04 08:27:25

https://www.mail-archive.com/gcc-patche … 04814.html
I followed this mailing list down to this. I guess it should be fixed in current gcc-multilib-git?

EDIT: I just compiled gcc-multilib-git, after that glibc and both successfully (and yes, I updated gcc before building glibc). Cheers!

EDIT #2: gcc-multilib-git 5.0.137154.840573b-1 (just for the record)

Last edited by smirky (2015-03-04 09:55:51)

chaonaut · 2015-03-04 13:11:10

Allan wrote:

That is gcc crashing...

thanks for clarifying that.
gcc rebuilt from newer snapshot compiled glibc succesfully.

Arch Linux

#26 2015-02-24 16:37:58

Re: GCC 5 is coming with a massive rebuild

#27 2015-02-24 16:45:16

Re: GCC 5 is coming with a massive rebuild

#28 2015-02-24 16:45:52

Re: GCC 5 is coming with a massive rebuild

#29 2015-02-24 17:05:43

Re: GCC 5 is coming with a massive rebuild

#30 2015-02-24 17:26:41

Re: GCC 5 is coming with a massive rebuild

#31 2015-02-24 17:32:19

Re: GCC 5 is coming with a massive rebuild

#32 2015-02-24 17:49:40

Re: GCC 5 is coming with a massive rebuild

#33 2015-02-24 22:58:18

Re: GCC 5 is coming with a massive rebuild

#34 2015-02-24 23:03:48

Re: GCC 5 is coming with a massive rebuild

#35 2015-02-24 23:18:02

Re: GCC 5 is coming with a massive rebuild

#36 2015-02-24 23:55:46

Re: GCC 5 is coming with a massive rebuild

#37 2015-02-25 06:57:05

Re: GCC 5 is coming with a massive rebuild

#38 2015-02-26 10:45:57

Re: GCC 5 is coming with a massive rebuild

#39 2015-02-26 11:01:59

Re: GCC 5 is coming with a massive rebuild

#40 2015-02-26 11:02:51

Re: GCC 5 is coming with a massive rebuild

#41 2015-02-26 12:52:26

Re: GCC 5 is coming with a massive rebuild

#42 2015-02-26 13:13:05

Re: GCC 5 is coming with a massive rebuild

#43 2015-02-26 13:23:21

Re: GCC 5 is coming with a massive rebuild

#44 2015-02-26 13:25:51

Re: GCC 5 is coming with a massive rebuild

#45 2015-02-27 13:50:31

Re: GCC 5 is coming with a massive rebuild

#46 2015-02-27 20:17:23

Re: GCC 5 is coming with a massive rebuild

#47 2015-03-03 16:16:43

Re: GCC 5 is coming with a massive rebuild

#48 2015-03-03 21:45:58

Re: GCC 5 is coming with a massive rebuild

#49 2015-03-04 08:27:25

Re: GCC 5 is coming with a massive rebuild

#50 2015-03-04 13:11:10

Re: GCC 5 is coming with a massive rebuild

Board footer