gcc48: stable 4.8.0 released

[larryv (Lawrence Velázquez)]

​http://gcc.gnu.org/ml/gcc/2013-03/msg00179.html

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

Despite there being a stable version available now, the most recent update to the gcc48 port (r104293) updated it to another development version... Is there a reason for doing that?

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Despite there being a stable version available now, the most recent update to the gcc48 port (r104293) updated it to another development version... Is there a reason for doing that?

*shrug* Updating is at mww’s discretion. The development version from 2013-03-21 is practically stable anyway.

[cooljeanius (Eric Gallager)]

Also once the gcc48 port is using a stable release we should probably also start offering a gcc49 port: #38568

[burnus@…]

Replying to egall@…:

Despite there being a stable version available now, the most recent update to the gcc48 port (r104293) updated it to another development version... Is there a reason for doing that?

I don't know about the reason of the Port Maintainer. However, snapshots from the release branches (4.6.x, 4.7.x, 4.8.x) are usually very stable as only regression fixes and fixes for serious bugs are allowed.

Linux distributions always take the latest branch version and ignore the releases. (The decrement the version number by one, such that it appears as latest release plus patches). Except that the release manager builds the RC on some systems there is not really a difference between the snapshot build and the using a minor release.

Thus, the pros for staying with a release are mainly: Well defined version, has been tested to build on several systems. The pros for using branch snapshots: Contains more bug fixes and is also stable. (And it only enters MacPorts if it builds.) Especially shortly after a major release like 4.8.0 it might make sense to use the snapshots as this will give quick access to the regressions found in the release. (Things should calm down a bit more after 4.8.1, which will probably be released in about two months.)

[ryandesign (Ryan Carsten Schmidt)]

If and when Markus updates the gcc48 port to a stable release, he must remember to increase the epoch, as usual, because:

$ ~/macports/users/ryandesign/scripts/vercmp 4.8-20130321 4.8.0
MacPorts considers 4.8-20130321 to be greater than 4.8.0.

[cooljeanius (Eric Gallager)]

r104652 is another devel version...

[larryv (Lawrence Velázquez)]

Replying to egall@…:

r104652 is another devel version...

…and? Is there a problem?

[luis.beca@…]

Cc Me!

[cooljeanius (Eric Gallager)]

Replying to larryv@…:

Replying to egall@…:

r104652 is another devel version...

…and? Is there a problem?

Just wondering why mww seems to be ignoring this ticket...

[kurtjaeke@…]

Cc Me!

[acmorrow (Andrew C. Morrow)]

Cc Me!

[larryv (Lawrence Velázquez)]

Has duplicate #38733.

[rob.patro@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

A patch for this has been submitted in #38758.

[jeremyhu (Jeremy Huddleston Sequoia)]

That patch from #38758 does some incorrect things to libstdcxx. Those are not the desired changes for libstdcxx, and the issue they are trying to fix is independent of the version bump.

[howarth@…]

Replying to jeremyhu@…:

That patch from #38758 does some incorrect things to libstdcxx. Those are not the desired changes for libstdcxx, and the issue they are trying to fix is independent of the version bump.

Exactly what is being done incorrectly? The only changes I made were to do a complete bootstrap for both c and c++ in the libstdcxx subport in order to insure that all of the symbols for *emutls* calls were present in the installed libstdc++. I spent numerous hours testing various permutations and the only one that works reliably is to build both c and c++ with a full bootstrap. Otherwise the libstdc++ oddly ended up installed without the *emutls* calls. FSF gcc is a highly complex build and I would avoid using rarely tested aspects of its build unless absolutely necessary. Also a full bootstrap insures your code generation is stable.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to howarth@…:

Replying to jeremyhu@…:

That patch from #38758 does some incorrect things to libstdcxx. Those are not the desired changes for libstdcxx, and the issue they are trying to fix is independent of the version bump.

Exactly what is being done incorrectly?

You are installing the libgcc runtime dylibs as well.

Please keep these comments in a separate ticket. It's difficult tracking your issues across multiple unrelated tickets.

the only one that works reliably is to build both c and c++ with a full bootstrap

Then just try reverting r103047 (#36116). Don't do the other changes.

[howarth@…]

Replying to jeremyhu@…:

Replying to howarth@…:

Replying to jeremyhu@…:

That patch from #38758 does some incorrect things to libstdcxx. Those are not the desired changes for libstdcxx, and the issue they are trying to fix is independent of the version bump.

Exactly what is being done incorrectly?

You are installing the libgcc runtime dylibs as well.

Yes because your current usage of -static-libgcc for linking the libstdc++ shared lib is quite broken. We ran into a very similar issue with the libitm shared library which revealed that the faster c++ weak-symbol coalescing introduced in darwin10 plays havoc with symbol resolution for shared libs that have static libs linked in. Let me explain in more detail. If you have the same non-weak symbols in both libSystem and in the static libgcc, linking a shared library which uses those symbols against the static libgcc insures that the symbols from the static lib are always used). The faster c++ weak symbol coalescing is quicker because it only attempts to find alternative symbols outside of the code module from shared libraries if those symbols are marked as weak in the shared libs. It is pretty hairy stuff and took us a long time to wrap our heads around to fix ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 in FSF gcc 4.8.0. The final solution was effectively the same (avoid linking in static libs).

Please keep these comments in a separate ticket. It's difficult tracking your issues across multiple unrelated tickets.

the only one that works reliably is to build both c and c++ with a full bootstrap

Then just try reverting r103047 (#36116). Don't do the other changes.

I can do it but I know it won't fix the test case that tickles the use of two unwinders. You are still linking in a libgcc_eh.a and trying accessing non-weak symbols from libSystem (which will never be used due to the faster c++ weak coalescing). Just ask Nick Kledzik if you don't believe me. He helped us understand the subtly in this change made at darwin10. I know you want this magically fixed in FSF's libgcc_eh but it ain't gonna happen. The whole issue becomes devilishly complex on darwin because of the fact that many of the calls in libgcc have been subsumed into libSystem. For llvm, life is simpler because the same compiler-rt code used for those calls in clang/llvm are used in libSystem. For FSF gcc, we have a fork and it is better to focus on the quality of the shared libgcc support (where we can use stubs to only provide those calls which libSystem doesn't).

[jeremyhu (Jeremy Huddleston Sequoia)]

File a new ticket. I will not further muddy this ticket by responding to your off-topic comments.

[howarth@…]

Opened ticket:38814 but the proposed fix is actually in ticket:38758 (for the movement of the libstdcxx subport into the gcc48 Portfile and the addition of the libgcc*dylib files into the libstdcxx subport). ticket:38774 contains the gcc47 Portfile changes to adjust to the movement of the libstdcxx subport into the gcc48 packaging and the placement of the libgcc*dylib files in the libstdcxx subport.

[jeremyhu (Jeremy Huddleston Sequoia)]

I plan on tackling the gcc48/gcc49 bump some time in the next few hours unless someone objects.

I'll be addressing #38814 and #38774 in subsequent commits.

[jeremyhu (Jeremy Huddleston Sequoia)]

r105277

[ryandesign (Ryan Carsten Schmidt)]

This ticket was supposed to be for updating gcc48 to a stable version. But since so much has already happened in this ticket, I've opened a new ticket for that: #38817