Incorporation of GCC 5

[korli]

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

Current release is 5.3

[korli]

I'm now ready to push the merge of GCC 5.3 in our buildtools branch. This implies providing updated syslibs though. I've built x86 and x86_64 packages to be pushed at the same time. x86_gcc2 package should be ready by tomorrow. So far in my tests I haven't met problems (Beam, Webpositive continue to work). Packages depending on an exact version of GCC should be rebuilt (I think llvm does).

I've planned to upgrade on Friday, if nothing comes in between.

[bonefish]

kernel_debugger debug report

[bonefish]

Alas kernel_debugger crashes now in malloc() called by the libsupc++ initialization.

[bonefish]

The cause appears to be that libsupc++ doesn't link against libroot, but uses malloc() already in static initialization code. So, if a program links against libsupc++ before libroot, the memory allocator has not been initialized at that point yet.

[korli]

The relevant lines of the GCC recipe:

        # Build a shared libsupc++ from libsupc++.a (hacking the gcc build system
        # to build a shared libsupc++ yields pretty much the same result, so we
        # use this simpler approach).
        cd $objectsDir/$effectiveTargetMachineTriple/libstdc++-v3/libsupc++
        gcc -nodefaultlibs -shared -o .libs/libsupc++.so -Xlinker --whole-archive .libs/libsupc++.a

[korli]

I can fix the GCC recipe to link against libroot, but I wonder if providing libsupc++ as a shared library should simply be avoided: it's tightly linked to libstdc++, so libstdc++ should include libsupc++, and libsupc++.a should be used by kernel_debugger. I don't remember well what leads to the current setup.

[bonefish]

Having separate shared libsupc++ and libstdc++ is the standard set-up AFAIK. The former is significantly smaller, so programs that don't use the STL don't have to link against the larger library, thus saving some memory and start-up time. I'm not aware of any other reason for keeping the libraries separate.

[korli]

OK, though GCC doesn't provide a shared libsupc++ by default, not so standard set-up in my book.

Our use of libsupc++ is somewhat questionable, for instance, libdevice links against libbe and libsupc++. libbe links against libstdc++. this leads to two copies of libsupc++ in memory (the one in libstdc++ and the one in libsupc++). Or do I miss something? IMO linking against libsupc++ makes only sense for apps as kernel_debugger.

[bonefish]

Replying to korli:

OK, though GCC doesn't provide a shared libsupc++ by default, not so standard set-up in my book.

OK, that seems to have changed since the earlier gcc 4 versions. At least on Linux a shared libsupc++ was available back then. That no longer seems to be the case, though.

Our use of libsupc++ is somewhat questionable, for instance, libdevice links against libbe and libsupc++. libbe links against libstdc++. this leads to two copies of libsupc++ in memory (the one in libstdc++ and the one in libsupc++). Or do I miss something?

No, you're right. Consequently the shared libstdc++ would link against the shared libsupc++ instead of including it, so that there wouldn't be such a duplication. But I don't think doing it this way (unlike everyone else) is worth the hassle. I'd just drop the shared libsupc++ and change the Haiku build system to linking against libstdc++. In case external packages use the shared libsupc++, a symlink to libstdc++ could be provided temporarily (only in lib/, though, not develop/lib/).

[korli]

I made the change in the build system: hrev50251. Hopefully what you had in mind. Will change the gcc_syslibs package next.

[bonefish]

Great, thanks!

[korli]

Port fail to build: ​lame fails to build with gcc5

[korli]

Closing, what doesn't yet build with gcc5 can also be left out.