Opened 4 years ago

Closed 3 years ago

#12532 closed enhancement (fixed)

Incorporation of GCC 5

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

Description

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

Current release is 5.3

Attachments (1)

kernel_debugger-596-debug-10-04-2016-10-56-04.report (6.8 KB ) - added by bonefish 4 years ago.
kernel_debugger debug report

Download all attachments as: .zip

Change History (13)

comment:1 by korli, 4 years ago

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.

by bonefish, 4 years ago

kernel_debugger debug report

comment:2 by bonefish, 4 years ago

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

comment:3 by bonefish, 4 years ago

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.

comment:4 by korli, 4 years ago

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
Last edited 4 years ago by korli (previous) (diff)

comment:5 by korli, 4 years ago

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.

comment:6 by bonefish, 4 years ago

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.

comment:7 by korli, 4 years ago

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.

in reply to:  7 comment:8 by bonefish, 4 years ago

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

comment:9 by korli, 3 years ago

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

comment:10 by bonefish, 3 years ago

Great, thanks!

comment:12 by korli, 3 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.