Our gcc is rather old and we should really look at upgrading it to a newer version.
It's probably best to update binutils at the same time. They tend to influence each other.
Might also want to consider bug 4410 whilst we're poking at gcc anyway.
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.
Upgraded to 4.6.4 in 29792. Keeping bug open, since I'm considering later versions as well.
Before closing this bug, we should run the test cases on https://www.cendio.com/bugzilla/show_bug.cgi?id=3411 .
(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 :-)
(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.
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.
(In reply to comment #8) > glibc no longer builds: Fixed in 30000.
Tested the Windows thread test programs and they work fine on both Win32 and Win64.
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.*
Probably just needs to add makeinfo/texinfo as a dependency.
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.
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.
This is the minimal test case needed to provoke the bug: $ cat fail.sh (false); \ (true && echo "OK") || echo "FAIL"
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.
(In reply to comment #12) > Probably just needs to add makeinfo/texinfo as a dependency. r30211.
The bash fix also got committed in that revision by mistake.
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.
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.
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
(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.
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
(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.
(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.
It is now possible to build all of cenbuild. The rest of the testing will be indirect via all other tests.
