www.cendio.com
Bug 5256 - upgrade gcc
: upgrade gcc
Status: CLOSED FIXED
: ThinLinc
Build system
: trunk
: PC Unknown
: P2 Normal
: 4.4.0
Assigned To:
:
:
: 4339 4804 5287
: 5257 5430
  Show dependency treegraph
 
Reported: 2014-09-15 09:37 by
Modified: 2015-04-16 11:08 (History)
Acceptance Criteria:


Attachments


Note

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


Description From cendio 2014-09-15 09:37:36
Our gcc is rather old and we should really look at upgrading it to a newer
version.
------- Comment #1 From cendio 2014-11-24 13:55:47 -------
It's probably best to update binutils at the same time. They tend to influence
each other.
------- Comment #2 From cendio 2014-11-24 13:56:58 -------
Might also want to consider bug 4410 whilst we're poking at gcc anyway.
------- Comment #3 From cendio 2014-12-02 16:28:05 -------
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 From cendio 2015-01-14 22:11:02 -------
Upgraded to 4.6.4 in 29792. Keeping bug open, since I'm considering later
versions as well.
------- Comment #5 From cendio 2015-01-19 13:56:23 -------
Before closing this bug, we should run the test cases on
https://www.cendio.com/bugzilla/show_bug.cgi?id=3411 .
------- Comment #6 From cendio 2015-02-06 09:18:49 -------
(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 From cendio 2015-02-11 09:56:32 -------
(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 From cendio 2015-02-17 22:14:27 -------
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 From cendio 2015-02-18 09:08:49 -------
(In reply to comment #8)
> glibc no longer builds:

Fixed in 30000.
------- Comment #10 From cendio 2015-03-25 11:28:52 -------
Tested the Windows thread test programs and they work fine on both Win32 and
Win64.
------- Comment #11 From cendio 2015-03-25 12:30:39 -------
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 From cendio 2015-03-25 12:51:43 -------
Probably just needs to add makeinfo/texinfo as a dependency.
------- Comment #13 From cendio 2015-03-25 15:38:31 -------
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 From cendio 2015-04-01 13:26:05 -------
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 From cendio 2015-04-07 13:58:57 -------
This is the minimal test case needed to provoke the bug:

$ cat fail.sh 
(false); \
(true && echo "OK") || echo "FAIL"
------- Comment #16 From cendio 2015-04-07 14:04:01 -------
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 From cendio 2015-04-07 14:08:30 -------
(In reply to comment #12)
> Probably just needs to add makeinfo/texinfo as a dependency.

r30211.
------- Comment #18 From cendio 2015-04-07 14:10:03 -------
The bash fix also got committed in that revision by mistake.
------- Comment #19 From cendio 2015-04-08 10:00:07 -------
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 From cendio 2015-04-08 12:32:51 -------
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 From cendio 2015-04-09 09:23:40 -------
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 From cendio 2015-04-10 10:13:50 -------
(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 From cendio 2015-04-14 09:21:43 -------
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 From cendio 2015-04-15 10:54:54 -------
(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 From cendio 2015-04-15 10:56:24 -------
(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 From cendio 2015-04-16 11:08:51 -------
It is now possible to build all of cenbuild. The rest of the testing will be
indirect via all other tests.