Opened 6 years ago

Closed 5 years ago

#10272 closed enhancement (fixed)

Incorporation of GCC 4.8

Reported by: korli Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Build System Version: R1/Development
Keywords: Cc: anevilyak
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

Provisioning ticket for GCC 4.8 to track activities and see if it works well.

Attachments (9)

0001-Fix-build-with-gcc48-except-apps-Installer.patch (5.7 KB ) - added by mt 6 years ago.
0001-Fix-build-with-gcc48.patch (6.2 KB ) - added by mt 6 years ago.
0001-Fix-debugserver-build-with-gcc48.patch (866 bytes ) - added by mt 6 years ago.
0002-Fix-icon-o-matic-build-with-gcc-4.8-x86_64.patch (999 bytes ) - added by mt 6 years ago.
buildlog.txt (21.7 KB ) - added by mt 6 years ago.
buildlog2.txt (8.0 KB ) - added by mt 6 years ago.
build with -U_GLIBCXX_USE_INT128
gcclog.txt (6.7 KB ) - added by mt 6 years ago.
gcc -v -m32 on Haiku x86_64
gcc4.8.2-for-x86-test-only-2.patch (103.3 KB ) - added by mt 6 years ago.
Patch from my current gcc 4.8.2 tree
HaikuLauncher-43356-debug-06-02-2014-11-14-11.report (14.0 KB ) - added by pulkomandy 6 years ago.
HaikuLauncher crash, because of stack alignment problem.

Download all attachments as: .zip

Change History (65)

comment:1 by korli, 6 years ago

Owner: changed from bonefish to nobody
Status: newassigned

comment:2 by mt, 6 years ago

Hi, I'm trying to build with gcc 4.8, but I can't solve apps/Installer issue. any ideas?

C++ /home/haiku/haiku/haiku/generated-gcc48/objects/haiku/x86/release/apps/installer/CopyEngine.o 
In file included from /home/haiku/haiku/haiku/src/apps/installer/CopyEngine.cpp:6:0:
/home/haiku/haiku/haiku/src/apps/installer/CopyEngine.h: In member function 'void CopyEngine::_WriteThread()':
/home/haiku/haiku/haiku/src/apps/installer/CopyEngine.h:79:17: error: 'buffer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      free(buffer);
                 ^
/home/haiku/haiku/haiku/src/apps/installer/CopyEngine.cpp:544:11: note: 'buffer' was declared here
   Buffer* buffer;
           ^
cc1plus: all warnings being treated as errors

comment:3 by mt, 6 years ago

Has a Patch: set

in reply to:  2 ; comment:4 by korli, 6 years ago

Replying to mt:

Hi, I'm trying to build with gcc 4.8, but I can't solve apps/Installer issue. any ideas?

Please try to initialize buffer to NULL.

in reply to:  4 ; comment:5 by korli, 6 years ago

Replying to korli:

Replying to mt:

Hi, I'm trying to build with gcc 4.8, but I can't solve apps/Installer issue. any ideas?

Please try to initialize buffer to NULL.

here /home/haiku/haiku/haiku/src/apps/installer/CopyEngine.cpp:544

in reply to:  5 comment:6 by mt, 6 years ago

Replying to korli:

Replying to korli:

Replying to mt:

Hi, I'm trying to build with gcc 4.8, but I can't solve apps/Installer issue. any ideas?

Please try to initialize buffer to NULL.

here /home/haiku/haiku/haiku/src/apps/installer/CopyEngine.cpp:544

Thanks korli, now I can build with gcc4.8 (jam @release-vmware).

comment:7 by korli, 6 years ago

Applied in hrev46550.

comment:8 by mt, 6 years ago

Hi, I add debugserver build fix for gcc 4.8.

comment:9 by korli, 6 years ago

Cc: anevilyak added

anevilyak, could you review (and eventually apply) this debug server patch? Looks OK to me but the lines 793-794 might then be superfluous.

comment:10 by anevilyak, 6 years ago

The patch looks fine to me, feel free to apply. I'd rather keep 793-794 to be sure, rather than relying on that function call not touching those variables. I can revisit that this weekend though.

comment:11 by korli, 6 years ago

Applied in hrev46557.

comment:12 by mt, 6 years ago

Hi, I add icon-o-matic build fix for gcc48 (x86_64).

Note: In x86_64, cstdlib int128 error like this occurs, perhaps due to my mistake of building buildtools.

In file included from /home/haiku/haiku/haiku/generated-gcc64/cross-tools-x86_64/lib/gcc/x86_64-unknown-haiku/4.8.2/../../../../x86_64-unknown-haiku/include/c++/4.8.2/bits/stl_algo.h:59:0,
                 from /home/haiku/haiku/haiku/generated-gcc64/cross-tools-x86_64/lib/gcc/x86_64-unknown-haiku/4.8.2/../../../../x86_64-unknown-haiku/include/c++/4.8.2/algorithm:62,
                 from /home/haiku/haiku/haiku/src/system/boot/platform/bios_ia32/interrupts.cpp:12:
/home/haiku/haiku/haiku/generated-gcc64/cross-tools-x86_64/lib/gcc/x86_64-unknown-haiku/4.8.2/../../../../x86_64-unknown-haiku/include/c++/4.8.2/cstdlib:178:10: error: expected unqualified-id before '__int128'
   inline __int128
          ^

in reply to:  12 ; comment:13 by korli, 6 years ago

Replying to mt:

Note: In x86_64, cstdlib int128 error like this occurs, perhaps due to my mistake of building buildtools.

Does the gcc command line includes -m32? Are you building on a 64-bit platform?

in reply to:  13 ; comment:14 by mt, 6 years ago

Replying to korli:

Replying to mt:

Note: In x86_64, cstdlib int128 error like this occurs, perhaps due to my mistake of building buildtools.

Does the gcc command line includes -m32? Are you building on a 64-bit platform?

Hi, I'm building x86_64 Haiku on 32-bit platform (../configure --build-cross-tools x86_64 ../../buildtools/ -j4 --include-gpl-addons --include-patented-code --use-gcc-pipe) and gcc commandline includes -m32, but int128 errors occur in bellow files in /system/boot/, so I think -m32 is not problem.

/system/boot/kernel_vsprintf.cpp /system/boot/loader/file_systems/fat/Stream.cpp /system/boot/loader/file_systems/packagefs/BlockBufferPoolImpl.cpp /system/boot/loader/file_systems/packagefs/PackageDataReader.cpp /system/boot/loader/file_systems/packagefs/PackageFileHeapAccessorBase.cpp /system/boot/loader/file_systems/packagefs/PackageFileHeapReader.cpp /system/boot/loader/file_systems/packagefs/PackageReaderImpl.cpp /system/boot/loader/file_systems/packagefs/ReaderImplBase.cpp /system/boot/loader/heap.cpp /system/boot/loader/kernel_args.cpp /system/boot/loader/menu.cpp /system/boot/loader/pager.cpp /system/boot/loader/PathBlacklist.cpp /system/boot/loader/safemode_settings.cpp /system/boot/loader/stdio.cpp /system/boot/platform/bios_ia32/interrupts.cpp /system/boot/platform/bios_ia32/long.cpp

in reply to:  14 comment:15 by korli, 6 years ago

Replying to mt:

Hi, I'm building x86_64 Haiku on 32-bit platform (../configure --build-cross-tools x86_64 ../../buildtools/ -j4 --include-gpl-addons --include-patented-code --use-gcc-pipe) and gcc commandline includes -m32, but int128 errors occur in bellow files in /system/boot/, so I think -m32 is not problem.

-m32 is certainly a problem as we didn't build gcc with multilibs support.

comment:16 by mt, 6 years ago

Hi, I build with -v option, it seems gcc can't find 32-bit headers (32/bits and 32/ext).

by mt, 6 years ago

Attachment: buildlog.txt added

comment:17 by korli, 6 years ago

Please try to add "-U _GLIBCXX_USE_INT128" here and here.

in reply to:  17 comment:18 by mt, 6 years ago

Replying to korli:

Please try to add "-U _GLIBCXX_USE_INT128" here and here.

Hi, I tried it, but it failed. I think we might add include bellow 32-bit header path to ArchitectureRules when using -m32.

  • cross-tools-x86_64/x86_64-unknown-haiku/include/c++/4.8.2/x86_64-unknown-haiku/32/bits
  • cross-tools-x86_64/x86_64-unknown-haiku/include/c++/4.8.2/x86_64-unknown-haiku/32/ext

by mt, 6 years ago

Attachment: buildlog2.txt added

build with -U_GLIBCXX_USE_INT128

comment:19 by korli, 6 years ago

As a workaround, can you try to add "#undef _GLIBCXX_USE_INT128" at the top of interrupts.cpp?

comment:20 by korli, 6 years ago

mt, you might be right with the need to include arch includes for libstd. I haven't come yet to testing this though.

comment:21 by mt, 6 years ago

Hi, I checked Haiku x86_64 (gcc 4.7.3), our complier can't find 32-bit headers and does not have 32-bit headers. we might add new ticket (ex. [x86_64] gcc can't find 32bit headers with -m32 option).

by mt, 6 years ago

Attachment: gcclog.txt added

gcc -v -m32 on Haiku x86_64

comment:22 by korli, 6 years ago

mt, it should be fixed with hrev46682.

in reply to:  22 comment:23 by mt, 6 years ago

Replying to korli:

mt, it should be fixed with hrev46682.

Thanks korli!, I can build (with icon-o-matic patch which I attached in this ticket) and boot.

comment:24 by korli, 6 years ago

icon-o-matic patch is applied in hrev46688.

comment:25 by korli, 6 years ago

mt, I've still problems to link shared libraries. If you manage to build as is, I must have missed something during the merge. Could you provide a Haiku diff with GCC 4.8.2?

in reply to:  25 comment:26 by mt, 6 years ago

Replying to korli:

mt, I've still problems to link shared libraries. If you manage to build as is, I must have missed something during the merge. Could you provide a Haiku diff with GCC 4.8.2?

Hi, here is my old patch. I will make new patch later. http://www.jade.dti.ne.jp/~murai/haiku/gcc4.8.2-for-x86-test-only.patch

by mt, 6 years ago

Patch from my current gcc 4.8.2 tree

comment:27 by korli, 6 years ago

I'll check next week. Thanks.

comment:28 by korli, 6 years ago

It seems that GCC 4.8 changed the visibility of symbols in the static libgcc, which we happen to use to build libroot. For the time being, as a workaround, I reactivated the visibility and will probably submit a bug report to trace this specific problem.

The graphite build is still broken, it seems since the PM merge. But this doesn't stop us from upgrading now.

in reply to:  28 ; comment:29 by bonefish, 6 years ago

Replying to korli:

It seems that GCC 4.8 changed the visibility of symbols in the static libgcc, which we happen to use to build libroot. For the time being, as a workaround, I reactivated the visibility and will probably submit a bug report to trace this specific problem.

I think, it's time to stop linking libgcc into libroot. That might require us to change the build process a bit (build a stub libroot, so we can build a shared libgcc), but I can't think of any negative side effects ATM.

in reply to:  29 ; comment:30 by korli, 6 years ago

Replying to bonefish:

I think, it's time to stop linking libgcc into libroot. That might require us to change the build process a bit (build a stub libroot, so we can build a shared libgcc), but I can't think of any negative side effects ATM.

A few questions arise (What about hybrid builds? What would the migration path?). When fixed, the commit to be reverted is this one. I'll open a ticket.

4.8.2 integrated in btrev43069. GCC with graphite fixed in hrev46783. m68k build fixed in btrev43070.

Native packages are updated in hrev46788, hrev46789 , hrev46791.

Two notes:

  • -pipe for cross tools build should only be used when --use-gcc-pipe is passed to configure.
  • anevilyak: "the multijob cross-tools build is broken here for 4.8 ; even as little as -j2 results in a failure early on where mkdir complains about cross-tools/x86/include already existing. Without any parallelization, it succeeds. This is on FreeBSD 9.2, and the cross tools build worked fine for -j8 with 4.7.3."

in reply to:  30 comment:31 by bonefish, 6 years ago

Replying to korli:

Replying to bonefish:

I think, it's time to stop linking libgcc into libroot. That might require us to change the build process a bit (build a stub libroot, so we can build a shared libgcc), but I can't think of any negative side effects ATM.

A few questions arise (What about hybrid builds? What would the migration path?).

We could do that only for gcc 4. It should be possible for gcc 2 as well, but it is less relevant, since that compiler won't be updated anyway (safe for minor changes). For the build system it doesn't matter much whether the handling for both compilers is the same. There are only a few places that need the distinction anyway (building the stub libroot, building libroot, rule AddSharedObjectGlueCode). The tricky part might be figuring out how to build the cross gcc with the shared libgcc, since for building the stub libroot we may already need a compiler.

comment:32 by pulkomandy, 6 years ago

I tried building WebKit with the new gcc. Unfortunately, this doesn't work. Apparently the _GLIBCXX_HAS_GTHREADS define doesn't get set, and as a result our libstdc++ lacks std::once_flag and std::call_once (well these are the one I hit in WebKit). It seems the whole std::thread support (C++11) may be missing.

I already had this problem with gcc4.7, and this is preventing us to update our WebKit to version after December 20, 2013. I wanted to look at it myself but my data partition is corrupted, so today I'm backing up files and cleaning it... If someone wants to have a look at this...

in reply to:  32 ; comment:33 by korli, 6 years ago

Replying to pulkomandy:

I tried building WebKit with the new gcc. Unfortunately, this doesn't work. Apparently the _GLIBCXX_HAS_GTHREADS define doesn't get set, and as a result our libstdc++ lacks std::once_flag and std::call_once (well these are the one I hit in WebKit). It seems the whole std::thread support (C++11) may be missing.

For sure, we don't use --enable-threads=posix. Can you manually define _GLIBCXX_HAS_GTHREADS in your CXXFLAGS?

I already had this problem with gcc4.7, and this is preventing us to update our WebKit to version after December 20, 2013. I wanted to look at it myself but my data partition

First time I hear from this problem at least.

comment:34 by pulkomandy, 6 years ago

I'll try that, once I've sorted out my FS issues (this backup is taking longer than I expected...)

comment:35 by bonefish, 6 years ago

Back in the earlier gcc 4 days I had a quick look at the Haiku specific thread support and found that it could use improvement. Our pthread support is better these days than when the code was introduced, so we might actually want to aim for switching to the pthread code instead. A few needed things might still be missing, though (barrier support (?) and IIRC it used some GNU extension(s) we might want add as well). This definitely deserves some review.

in reply to:  33 ; comment:36 by bonefish, 6 years ago

Replying to korli:

For sure, we don't use --enable-threads=posix. Can you manually define _GLIBCXX_HAS_GTHREADS in your CXXFLAGS?

AFAIK that macro is an indicator of how gcc has been configured and is not meant to be defined manually. Doing that will probably either have no effect, cause build failure, or (worst case) result in broken code.

comment:37 by korli, 6 years ago

Adrien, please try the following. It can be applied as is when it works for you.

diff --git a/build/scripts/build_cross_tools_gcc4 b/build/scripts/build_cross_tools_gcc4
index 346c9da..af370ef 100755
--- a/build/scripts/build_cross_tools_gcc4
+++ b/build/scripts/build_cross_tools_gcc4
@@ -199,7 +199,7 @@ CFLAGS="-O2 -pipe" CXXFLAGS="-O2" "$gccSourceDir/configure" \
        --prefix="$installDir" $buildHostSpec --target=$haikuMachine \
        --disable-nls --disable-shared --with-system-zlib \
        --enable-languages=c,c++ --enable-lto --enable-frame-pointer \
-       --with-sysroot="$sysrootDir" \
+       --with-sysroot="$sysrootDir" --enable-threads=posix \
        $gccConfigureArgs \
        || exit 1

I've tested in cross-compilation: it builds OK and compiled successfully the following sample (with -std=c++11).

#include <iostream>
#include <thread>
#include <mutex>
 
std::once_flag flag;
 
void do_once()
{
    std::call_once(flag, [](){ std::cout << "Called once" << std::endl; });
}
 
int main()
{
    std::thread t1(do_once);
    std::thread t2(do_once);
    std::thread t3(do_once);
    std::thread t4(do_once);
 
    t1.join();
    t2.join();
    t3.join();
    t4.join();
}

comment:38 by waddlesplash, 6 years ago

While we're on the subject of threads, does Haiku's GCC4 have OpenMP now? I have some software that I'd like to port that all it needs now is OpenMP, all the other deps are satisfied.

in reply to:  38 comment:39 by korli, 6 years ago

Replying to waddlesplash:

While we're on the subject of threads, does Haiku's GCC4 have OpenMP now? I have some software that I'd like to port that all it needs now is OpenMP, all the other deps are satisfied.

It's there for a while: http://gcc.gnu.org/projects/gomp/

comment:40 by waddlesplash, 6 years ago

Running "g++ -fopenmp" on a non-Haiku system produces the "no input files" error. Running the same command on Haiku (after running "setarch x86" of course) produces:

g++: error: unrecognized command line option '-pthread'

Does configuring GCC with "--enable-threads=posix" fix this problem too?

in reply to:  40 comment:41 by korli, 6 years ago

Replying to waddlesplash:

Does configuring GCC with "--enable-threads=posix" fix this problem too?

No, but btrev43071 should do (it does for the cross-compiler).

in reply to:  36 comment:42 by korli, 6 years ago

Replying to bonefish:

AFAIK that macro is an indicator of how gcc has been configured and is not meant to be defined manually. Doing that will probably either have no effect, cause build failure, or (worst case) result in broken code.

Sure. Anyway, to support C++ threads and enable-libstdcxx-time, it seems we might need to differentiate libsupc++ for user and kernel, as pthread symbols are not available when linking against the kernel. This is a bit more involved than expected, in fact at the moment only x86-64 does the differentiation.

comment:43 by bonefish, 6 years ago

Alternatively (or additionally) we could add the minimum required pthread support to the kernel. We probably won't really use much of the functionality in the kernel anyway, so most functions could be stubbed.

comment:44 by pulkomandy, 6 years ago

I have finally built WebKit with the suggested fix. I rebuilt gcc on haiku using haikuporter and updated my system with the new package.

I fixed some other issues in WebKit code and got it to compile. But, I have a problem running it now: runtime_loader: /Donnees/Dev/Haiku/webkit/WebKitBuild/Release/lib/x86/libWebKit.so.1.2.3: Could not resolve symbol 'once_proxy'

I noticed that the libstdc++.so file in /system/develop/tools/x86/lib has the symbol, but the one in /system/develop/lib/x86 doesn't. Copying the one from the tools folder to the 'lib' folder next to HaikuLauncher gets this running. It crashes when trying to open a web page, but this is likely related to other problems with merging the new WebKit version.

I guess this missing symbol is just because I built the package with Haikuporter. Do that still end up putting the current system libstdc++ in the package, instead of the new compiled one, similar to the problem we had before PM?

Version 0, edited 6 years ago by pulkomandy (next)

in reply to:  43 comment:45 by korli, 6 years ago

Replying to bonefish:

Alternatively (or additionally) we could add the minimum required pthread support to the kernel. We probably won't really use much of the functionality in the kernel anyway, so most functions could be stubbed.

I see, though libgcc and libsupc++ are also used for the bootloader. A solution that seems to work is switching the thread model to single for kernel libgcc and libsupc++.

comment:46 by bonefish, 6 years ago

@korli: Yeah, separate static versions of libgcc and libsupc++ for boot loader, kernel, and kernel add-ons are probably needed anyway.

@pulkomandy: I believe the libstdc++ issue still exists. The solution requires reorganizing some packages. libsupc++ and libstdc++ should be pulled out of the gcc package into a separate package (probably also with separate devel package; not sure yet, if we need a separate package for either library). The Haiku system package will consequently no longer contain these libraries. The packages will be available as build features (like ICU and zlib) instead.

For gcc 2 the libstdc++ sources are in the Haiku repository. We either remove them and build the library externally as a package, so everything works analogously to gcc 4. Or we keep things as they are, continuing the different handling.

in reply to:  46 comment:47 by korli, 6 years ago

Replying to bonefish:

@korli: Yeah, separate static versions of libgcc and libsupc++ for boot loader, kernel, and kernel add-ons are probably needed anyway.

Pushed my changes in hrev46821 and btrev43072.

Kernel versions of libgcc and libsupc++ aren't built for the native package, nor published on the image. I supposed it's already needed to build natively on x86_64.

comment:48 by pulkomandy, 6 years ago

I have another problem in WebKit: gcc is now using instructions that expect 16-byte tack alignment such as MOVAPS (http://www.rz.uni-karlsruhe.de/rz/docs/VTune/reference/vc181.htm)

Apparently, our stack isn't 16-byte aligned, and this makes this instruction crash. I'm going to work around this by compiling with -mstackrealign.

Attaching the debug report for this crash. Am I right that thread_entry breaks the 16-byte alignment here?

by pulkomandy, 6 years ago

HaikuLauncher crash, because of stack alignment problem.

in reply to:  48 comment:49 by korli, 6 years ago

Replying to pulkomandy:

I have another problem in WebKit: gcc is now using instructions that expect 16-byte tack alignment such as MOVAPS (http://www.rz.uni-karlsruhe.de/rz/docs/VTune/reference/vc181.htm)

This should deserve a ticket as it's not GCC specific. A small testcase would be nice also.

comment:50 by pulkomandy, 6 years ago

Ok, reported in #10509.

comment:51 by korli, 6 years ago

As of hrev46845, -pipe for cross tools build is only used when --use-gcc-pipe is passed to configure.

The native packages need some work to add kernel versions of libgcc/libsupc++, required to build Haiku on Haiku. Multijob cross-tools build still broken on FreeBSD only: @evilyak, any info on that?

in reply to:  51 comment:52 by anevilyak, 6 years ago

Replying to korli:

The native packages need some work to add kernel versions of libgcc/libsupc++, required to build Haiku on Haiku. Multijob cross-tools build still broken on FreeBSD only: @evilyak, any info on that?

Will give it a try again hopefully tonight and capture full output if it still fails.

comment:53 by anevilyak, 6 years ago

@korli: Can't seem to reproduce this problem any more with the last set of changes to buildtools.

comment:54 by waddlesplash, 5 years ago

Since the last issue has been fixed & it's been a few months since GCC4 integration, can this be closed?

in reply to:  54 comment:55 by korli, 5 years ago

Replying to waddlesplash:

Since the last issue has been fixed & it's been a few months since GCC4 integration, can this be closed?

The native packages need some work to add kernel versions of libgcc/libsupc++, required to build Haiku on Haiku (to disable posix threads on x86, and also for the redzone on x86_64)

comment:56 by zooey, 5 years ago

Resolution: fixed
Status: assignedclosed

We now have separate gcc-syslibs packages, which allow building Haiku on Haiku again.

Note: See TracTickets for help on using tickets.