Bug 1427344 - Add Debian CRT objects to GCC. r=nfroyd
authorMike Hommey <mh+mozilla@glandium.org>
Fri, 29 Dec 2017 17:15:39 +0900
changeset 453320 7c92680e18dbc44de8b2bb5efbb23c686e0fc504
parent 453319 6e4c1669b6bafb90336ce4d9db9d134b081a9553
child 453321 5eb4b2bdb7cd9acd4dac829bc930142d1f3b6d33
push id1648
push usermtabara@mozilla.com
push dateThu, 01 Mar 2018 12:45:47 +0000
treeherdermozilla-release@cbb9688c2eeb [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersnfroyd
bugs1427344
milestone59.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1427344 - Add Debian CRT objects to GCC. r=nfroyd One of the last remaining differences when building Firefox on Debian with all the changes we've done so far is that linking against the system libc statically links some CRT objects. This causes massive differences in the resulting binaries because of slight differences in those objects (because they weren't compiled with the same compiler and because they're not for the exact same glibc version) In practice, their content difference don't cause any problem. If they did, we wouldn't be able to run our builds on newer systems than those we build them on. The only hypothetical risk would be to run on systems with a glibc older than Debian 7's, but those already can't run Firefox anyways (those systems don't have Gtk+3, which is a system requirement). AFAICT, this is only an hypothetical problem anyways, even such systems with Gtk+3 should be able to run those builds. Plus, this is a change that will happen anyways when switching to Debian-based build images, since they would be using the CRT objects from there. We're merely making it happen earlier so that the differences from switching to Debian-based build images are more tractable. Note we only do this when building GCC on Debian, allowing to roll back to CentOS-based toolchains by just switching back the toolchain jobs to use the desktop-build docker image again.
build/unix/build-gcc/build-gcc.sh
--- a/build/unix/build-gcc/build-gcc.sh
+++ b/build/unix/build-gcc/build-gcc.sh
@@ -113,16 +113,38 @@ build_gcc() {
   mkdir $root_dir/gcc-objdir
   pushd $root_dir/gcc-objdir
   ../gcc-$gcc_version/configure --prefix=${prefix-/tools/gcc} --enable-languages=c,c++  --disable-nls --disable-gnu-unique-object --enable-__cxa_atexit --with-arch-32=pentiumpro --with-sysroot=/
   make $make_flags
   make $make_flags install DESTDIR=$root_dir
 
   cd $root_dir/tools
   ln -s gcc gcc/bin/cc
+
+  if [ -f /etc/debian_version ]; then
+    cp -v /usr/lib32/crt*.o /usr/lib32/lib*_nonshared.a gcc/lib32
+    cp -v /usr/lib/x86_64-linux-gnu/crt*.o /usr/lib/x86_64-linux-gnu/lib*_nonshared.a gcc/lib64
+    cat > gcc/lib32/libc.so <<-EOF
+	OUTPUT_FORMAT(elf32-i386)
+	GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED ( ld-linux.so.2 ) )
+	EOF
+    cat > gcc/lib32/libpthread.so <<-EOF
+	OUTPUT_FORMAT(elf32-i386)
+	GROUP ( libpthread.so.0 libpthread_nonshared.a )
+	EOF
+    cat > gcc/lib64/libc.so <<-EOF
+	OUTPUT_FORMAT(elf64-x86-64)
+	GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED ( ld-linux-x86-64.so.2 ) )
+	EOF
+    cat > gcc/lib64/libpthread.so <<-EOF
+	OUTPUT_FORMAT(elf64-x86-64)
+	GROUP ( libpthread.so.0 libpthread_nonshared.a )
+	EOF
+  fi
+
   tar caf $root_dir/gcc.tar.xz gcc/
   popd
 }
 
 build_gcc_and_mingw() {
   mkdir gcc-objdir
   pushd gcc-objdir
   ../gcc-$gcc_version/configure --prefix=$install_dir --target=i686-w64-mingw32 --with-gnu-ld --with-gnu-as --disable-multilib --enable-threads=posix