Incorporation of GCC 4.8

[korli]

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

[mt]

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

[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.

[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

[mt]

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).

[korli]

Applied in hrev46550.

[mt]

Hi, I add debugserver build fix for gcc 4.8.

[korli]

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

[anevilyak]

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.

[korli]

Applied in hrev46557.

[mt]

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
          ^

[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?

[mt]

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

[korli]

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.

[mt]

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

[korli]

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

[mt]

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

[mt]

build with -U_GLIBCXX_USE_INT128

[korli]

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

[korli]

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

[mt]

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).

[mt]

gcc -v -m32 on Haiku x86_64

[korli]

mt, it should be fixed with hrev46682.

[mt]

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.

[korli]

icon-o-matic patch is applied in hrev46688.

[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?

[mt]

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

[mt]

Patch from my current gcc 4.8.2 tree

[korli]

I'll check next week. Thanks.

[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.

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

[bonefish]

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.

[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?). 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."

[bonefish]

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.

[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.

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...

[korli]

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.

[pulkomandy]

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

[bonefish]

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.

[bonefish]

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.

[korli]

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();
}

[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.

[korli]

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/

[waddlesplash]

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?

[korli]

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).

[korli]

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.

[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.

[pulkomandy]

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?

[korli]

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++.

[bonefish]

@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.

[korli]

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.

[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)

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?

[pulkomandy]

HaikuLauncher crash, because of stack alignment problem.

[korli]

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.

[pulkomandy]

Ok, reported in #10509.

[korli]

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?

[anevilyak]

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.

[anevilyak]

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

[waddlesplash]

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

[korli]

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)

[zooey]

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