Bug 5256 - upgrade gcc
Summary: upgrade gcc
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Target Milestone: 4.4.0
Assignee: Peter Åstrand
URL:
Keywords: ossman_tester, prosaic
Depends on: 4339 4804 5287
Blocks: 5257 5430
  Show dependency treegraph
 
Reported: 2014-09-15 09:37 CEST by Pierre Ossman
Modified: 2015-04-16 11:08 CEST (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2014-09-15 09:37:36 CEST
Our gcc is rather old and we should really look at upgrading it to a newer version.
Comment 1 Pierre Ossman cendio 2014-11-24 13:55:47 CET
It's probably best to update binutils at the same time. They tend to influence each other.
Comment 2 Pierre Ossman cendio 2014-11-24 13:56:58 CET
Might also want to consider bug 4410 whilst we're poking at gcc anyway.
Comment 3 Pierre Ossman cendio 2014-12-02 16:28:05 CET
Note that gcc requires a C++ compiler to build these days and not just a C compiler. Might not matter much given that we usually build a C++ compiler anyway, but it's worth to keep in mind.
Comment 4 Peter Åstrand cendio 2015-01-14 22:11:02 CET
Upgraded to 4.6.4 in 29792. Keeping bug open, since I'm considering later versions as well.
Comment 5 Peter Åstrand cendio 2015-01-19 13:56:23 CET
Before closing this bug, we should run the test cases on https://www.cendio.com/bugzilla/show_bug.cgi?id=3411 .
Comment 6 Peter Åstrand cendio 2015-02-06 09:18:49 CET
(In reply to comment #4)
> Upgraded to 4.6.4 in 29792. Keeping bug open, since I'm considering later
> versions as well.

I think we should aim for 4.8.4. The primary reason is that 4.9.X does not work with our existing kernel headers, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955

But in general, since we are targeting many old platforms, it might be good to be at least somewhat conservative. Besides, 4.8.4 is actually 2 months newer than 4.9.2 :-)
Comment 7 Peter Åstrand cendio 2015-02-11 09:56:32 CET
(In reply to comment #6)
> (In reply to comment #4)
> > Upgraded to 4.6.4 in 29792. Keeping bug open, since I'm considering later
> > versions as well.
> 
> I think we should aim for 4.8.4. The primary reason is that 4.9.X does not work
> with our existing kernel headers, see:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
> 
> But in general, since we are targeting many old platforms, it might be good to
> be at least somewhat conservative. Besides, 4.8.4 is actually 2 months newer
> than 4.9.2 :-)

The consensus is that we want 4.9.X, but due to several roadblocks, I'm running out of time.
Comment 8 Peter Åstrand cendio 2015-02-17 22:14:27 CET
glibc no longer builds:

386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h       -DHAVE_INITFINI -o /local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6/build/csu/libc-start.o -MD -MP -MF /local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6/build/csu/libc-start.o.dt -MT /local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6/build/csu/libc-start.o
/tmp/cclgWRyi.s: Assembler messages:
/tmp/cclgWRyi.s:33: Error: CFI instruction used without previous .cfi_startproc
/tmp/cclgWRyi.s:35: Error: CFI instruction used without previous .cfi_startproc
/tmp/cclgWRyi.s:36: Error: CFI instruction used without previous .cfi_startproc
/tmp/cclgWRyi.s:38: Error: .cfi_endproc without corresponding .cfi_startproc
/tmp/cclgWRyi.s:51: Error: CFI instruction used without previous .cfi_startproc
/tmp/cclgWRyi.s:53: Error: CFI instruction used without previous .cfi_startproc
/tmp/cclgWRyi.s:54: Error: CFI instruction used without previous .cfi_startproc
/tmp/cclgWRyi.s:56: Error: .cfi_endproc without corresponding .cfi_startproc
../sysdeps/generic/initfini.c: Assembler messages:
../sysdeps/generic/initfini.c:123: Error: open CFI at the end of file; missing .cfi_endproc directive
../sysdeps/generic/initfini.c:123: Error: open CFI at the end of file; missing .cfi_endproc directive
make[2]: *** [/local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6/build/csu/crti.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [/local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6/build/csu/crtn.o] Error 1
make[2]: Leaving directory `/local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory `/local/home/astrand/cenbuild/repo/rpmbuild/BUILD/glibc-2.3.6'

Tried Google. Common problem with many solution, nothing obvious.
Comment 9 Peter Åstrand cendio 2015-02-18 09:08:49 CET
(In reply to comment #8)
> glibc no longer builds:

Fixed in 30000.
Comment 10 Pierre Ossman cendio 2015-03-25 11:28:52 CET
Tested the Windows thread test programs and they work fine on both Win32 and Win64.
Comment 11 Pierre Ossman cendio 2015-03-25 12:30:39 CET
glibc failed to build:

Processing files: cendio-build-glibc-stage1-i386-2.3.6-1.noarch
error: File not found by glob: /home/tltest/cenbuild/repo/rpmbuild/BUILDROOT/cendio-build-glibc-stage1-i386-2.3.6-1.i386/opt/cendio-build/arch/i386/usr/info/libc.*
Comment 12 Pierre Ossman cendio 2015-03-25 12:51:43 CET
Probably just needs to add makeinfo/texinfo as a dependency.
Comment 13 Pierre Ossman cendio 2015-03-25 15:38:31 CET
bash is broken in the new system somehow. When building flex it misexecutes this line:

  (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make  $local_target) \
  || eval $failcom;

Trace:

+ CDPATH=:
+ eval exit 1

Expected behaviour:

+ CDPATH=:
+ cd lib
+ make all

Dropping in bash from our repo makes the bug go away, so the problem is definitely in the newly built bash somewhere.
Comment 14 Pierre Ossman cendio 2015-04-01 13:26:05 CEST
I can reproduce it by copying the shell code from make into an independent script. It also seems to depend on creating a very long expression as the problem goes away if I remove some strategic "\" continuators.
Comment 15 Pierre Ossman cendio 2015-04-07 13:58:57 CEST
This is the minimal test case needed to provoke the bug:

$ cat fail.sh 
(false); \
(true && echo "OK") || echo "FAIL"
Comment 16 Pierre Ossman cendio 2015-04-07 14:04:01 CEST
This turns out to be a bug in bash. Bash has a whole bunch of legacy code paths that are only used on crappy old systems. As such they are never tested and are full of weird bugs.

The reason we got bit by it now is subtle. The machine we previously built bash on had glibc.i686 installed which has the effect of configure thinking that it isn't a cross compile (it can execute binaries it builds). But on the new system glibc.i686 was missing so configure went into cross compile mode. This disabled a bunch of features in bash, among them job control. And it is the fallback code for job control that has this bug.

With some extra arguments to configure we can make sure we have these features turned on no matter if configure thinks we are cross compiling or not.
Comment 17 Pierre Ossman cendio 2015-04-07 14:08:30 CEST
(In reply to comment #12)
> Probably just needs to add makeinfo/texinfo as a dependency.

r30211.
Comment 18 Pierre Ossman cendio 2015-04-07 14:10:03 CEST
The bash fix also got committed in that revision by mistake.
Comment 19 Pierre Ossman cendio 2015-04-08 10:00:07 CEST
More info file problems with glibc. It doesn't like our version of makeinfo. Seems to simply be a bad test in configure.in. Checking if upstream has any patches.
Comment 20 Pierre Ossman cendio 2015-04-08 12:32:51 CEST
Getting it to use our makeinfo wasn't any better as glibc's info files have too many bugs to be accepted by our modern makeinfo.

I guess we should do what we do for gcc and just consistently turn off info files.
Comment 21 Pierre Ossman cendio 2015-04-09 09:23:40 CEST
pax doesn't build:

fts.c: In function 'pax_fts_set':
fts.c:469:7: error: parameter 'sp' set but not used [-Werror=unused-but-set-parameter]
cc1: all warnings being treated as errors
Comment 22 Pierre Ossman cendio 2015-04-10 10:13:50 CEST
(In reply to comment #20)
> Getting it to use our makeinfo wasn't any better as glibc's info files have too
> many bugs to be accepted by our modern makeinfo.
> 
> I guess we should do what we do for gcc and just consistently turn off info
> files.

r30222.
Comment 23 Pierre Ossman cendio 2015-04-14 09:21:43 CEST
Urgh. Seems like our new gcc makes our old binutils crash in some cases:

  CCLD   libcairo-trace.la
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
Comment 24 Pierre Ossman cendio 2015-04-15 10:54:54 CEST
(In reply to comment #21)
> pax doesn't build:
> 
> fts.c: In function 'pax_fts_set':
> fts.c:469:7: error: parameter 'sp' set but not used
> [-Werror=unused-but-set-parameter]
> cc1: all warnings being treated as errors

r30235.
Comment 25 Pierre Ossman cendio 2015-04-15 10:56:24 CEST
(In reply to comment #23)
> Urgh. Seems like our new gcc makes our old binutils crash in some cases:
> 
>   CCLD   libcairo-trace.la
> collect2: ld terminated with signal 11 [Segmentation fault], core dumped

We don't have time to get to the bottom of this. For now it seems sufficient to disable LTO. r30237.
Comment 26 Pierre Ossman cendio 2015-04-16 11:08:51 CEST
It is now possible to build all of cenbuild. The rest of the testing will be indirect via all other tests.

Note You need to log in before you can comment on or make changes to this bug.