gcc ports should not include a C++ runtime

[jeremyhu (Jeremy Huddleston Sequoia)]

The gcc ports ship libstdc++. They should not ship this runtime; they should instead use the hosts's runtime.

[su-v]

Cc Me!

[help@…]

Reposting my comment from #34288:

Several libstdc++ do not coexist well inside one process. I get backtraces like that when compiling with macports gcc46:

malloc: *** error for object 0x10151e500: pointer being freed was not allocated

#0  0x00007fff8eddf588 in malloc_error_break ()
#1  0x00007fff8ede0942 in free ()
#2  0x00007fff90154cf5 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
#3  0x00007fff9015898e in std::basic_streambuf<char, std::char_traits<char> >::xsputn ()
#4  0x00000001014a8b45 in std::__ostream_insert<char, std::char_traits<char> > ()
#5  0x00007fff7d9a7b80 in vtable for std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> > ()
#6  0x00007fff90155c8e in std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream ()
#7  0xed851f90058d48fb in ?? ()

0x00007fff addresses are from system /usr/lib/libstdc++.dylib and 0x00000001 are from gcc's libstdc++. Two things are wrong here - they call each others functions and they try to free each others objects/memory regions. Basicly it's completely broken behaviour. It's a wonder that crashes happen so rarely. Since there are system frameworks/libraries that are linked against /usr/lib/libstdc++ (and libc++, and libobjc), macports compilers should use system libstdc++ too and not include their own version of C++ runtime library.

[help@…]

Cc Me!

[neverpanic (Clemens Lang)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

apple-gcc42 done in r97627. Note that it didn't actually suffer from this problem because the dylib had id /usr/lib/libstdc++. The gcc4X ports will follow after I do some testing with them.

[jeremyhu (Jeremy Huddleston Sequoia)]

gcc4X are fixed with r97657

[cawka (Alex Afanasyev)]

Are you sure it is a right way to go? What about all new standard library extensions and c++11 support in latest gcc? The whole point (for me) to install a new gcc is to use those extensions...

I was having similar errors and the problem was always with mixing compilers. Though it is annoying sometimes, I would say that not mixing compiler version is a better choice.

[cawka (Alex Afanasyev)]

Cc Me!

[eborisch (Eric A. Borisch)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

If you want C++ 11 on OS X, you should be using libc++ with clang++.

It's not feasible to mix multiple C++ runtimes in the same process.

Feel free to provide a separate libstdc++ port which provides a single C++ runtime from GNU, and you will need to merge in Apple's changes to have it use libc++abi.dylib ...

[wtakuo@…]

Hi. The symbolic link command

    ln -s /usr/lib/libstdc++.6/dylib ${destroot}${prefix}/lib/${name}/libstdc++.6.dylib

found in changeset:97657 may cause broken symlinks. I think this should be the following (the fourth slash should be dot).

    ln -s /usr/lib/libstdc++.6.dylib ${destroot}${prefix}/lib/${name}/libstdc++.6.dylib

[jstrane@…]

Why do people install gcc 4.7 over gcc 4.2? Do they just want some minor performance improvements? If I want to get a performance boost by just changing a compiler, I would better choose icc or something, not gcc 4.7. I think, without those useful and time saving extensions, there is no reason to spend a couple of hours in compiling gcc 4.7. It doesn't make sense at all spending that much of time to just get some performance improvements.

[todmorrison (Tod Morrison)]

I'm not entirely sure what the extent of the fallout from this change will be, but so far I know "octave-devel" won't build and most of the heavily numerical apps I have installed have needed a lot work to get running/built again.

[help@…]

Just tried building with updated gcc46 port - it fails on linking stage. As far as I understand, GCC still uses its own C++ headers which do not match API/ABI provided by system libstdc++ which results in missing symbols. So just removing dylib isn't enough, more work should be done to make it work.

[todmorrison (Tod Morrison)]

Cc Me!

[todmorrison (Tod Morrison)]

Replying to jstrane@…:

Why do people install gcc 4.7 over gcc 4.2? Do they just want some minor performance improvements? If I want to get a performance boost by just changing a compiler, I would better choose icc or something, not gcc 4.7. I think, without those useful and time saving extensions, there is no reason to spend a couple of hours in compiling gcc 4.7. It doesn't make sense at all spending that much of time to just get some performance improvements.

gfortran support for one.

[jeremyhu (Jeremy Huddleston Sequoia)]

Well, FWIW, they're all building fine here. If you're having issues, please open a new ticket.

[jeremyhu (Jeremy Huddleston Sequoia)]

buildbot built them fine:

​http://build.macports.org/builders/buildports-snowleopard-x86_64/builds/10734/steps/compile/logs/progress

​http://build.macports.org/builders/buildports-lion-x86_64/builds/4330/steps/compile/logs/progress

[help@…]

You misunderstood me, I didn't say gcc46 failed to build, I said building _with_ it is broken. Here's simple example:

test.cpp:

#include <iostream>
#include <vector>

int main()
{
  std::vector<int> a;
  a.push_back(2);
  for(int i=0; i < a.size(); i++)
    std::cout << a[i] << std::endl;
}

running g++-mp-4.6 -O1 test.cpp gives this output:

Undefined symbols for architecture x86_64:
  "std::ctype<char>::_M_widen_init() const", referenced from:
      _main in cc5ncHdO.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

Optimization levels -O2 and -O3 fail too.

This is not a separate bug, as I said just removing dylib isn't enough, you have to make sure that compiler uses C++ headers that actually match the library version you want it to link against.

[angelo.graziosi@…]

Indeed!!! I don't understand why an user should install a new version of GCC (4.5,6,7) if, at the end, what it really will use, the true engine, will be an older version... :-(

On different GNU Linux distributions and Cygwin I have multiple version of GCC and each uses its own runtime libraries.

Ciao, Angelo.

Replying to help@…:

You misunderstood me, I didn't say gcc46 failed to build, I said building _with_ it is broken. Here's simple example:

test.cpp:

#include <iostream>
#include <vector>

int main()
{
  std::vector<int> a;
  a.push_back(2);
  for(int i=0; i < a.size(); i++)
    std::cout << a[i] << std::endl;
}

running g++-mp-4.6 -O1 test.cpp gives this output:

Undefined symbols for architecture x86_64:
  "std::ctype<char>::_M_widen_init() const", referenced from:
      _main in cc5ncHdO.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

Optimization levels -O2 and -O3 fail too.

This is not a separate bug, as I said just removing dylib isn't enough, you have to make sure that compiler uses C++ headers that actually match the library version you want it to link against.

[help@…]

See my previous comment (comment:2) why removal of libstdc++ is needed.

I personally want gcc46 for OpenMP support.

[angelo.graziosi@…]

For completeness...

"jeremyhu" have you seen the ticket #36092? Now PDFTK fail to build in a manner very similar to the test case produced by "help"...

The build of PDFTK was long time broken and only when was added the gcc47 variant the build was fixed. Now it is newly broken...

Perhaps the way to solve the your problem with OpenMP is wrong... See the test case of "help": it have to work is if GCC47 development allow for it...

Replying to help@…:

See my previous comment (#2) why removal of libstdc++ is needed.

I personally want gcc46 for OpenMP support.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to help@…:

You misunderstood me, I didn't say gcc46 failed to build, I said building _with_ it is broken.

This is not a separate bug, as I said just removing dylib isn't enough, you have to make sure that compiler uses C++ headers that actually match the library version you want it to link against.

I understand where you're coming from since that is very much where *I* was coming from when I brought this to the engineers here at Apple who work on the C++ runtime.

I was told that most of the C++ API is actually implemented as templates in the headers, so even newer versions of the C++ headers should work with the older runtimes. This seemed suspicious to me, but it was what I went with.

Based on your comment, it seems that libstdc++ seems to have changed in an incompatible way which makes that not necessarilary the case. If you really want libstdc++ over libc++ as your runtime, you will need to provide a new port to provide a single libstdc++ runtime rather than one per compiler. Furthermore, this runtime will need to be compatible with the host's runtime which means it will need to use libc++abi.dylib. You will need to look at the changes that Apple made to libstdc++.dylib in Lion and Mountain Lion and merge those changes into GCC.

As GCC is GPL-3, I will not be doing any of that work.

*This* issue is closed. Please open a new one if you wish to do the work of creating a libstdc++ port.

[help@…]

libstdc++ port isn't what I have in mind. I wanted a way for gcc46 to use system libstdc++. I tried just now to replace /opt/local/include/gcc46/c++/ content with /usr/include/c++/4.2.1/, but gcc failed to understand them correctly and exited with some error about _is_pod in cpp_type_traits.h. So incompatibility is both ways :( Unless you have something more up your sleeve, it basicly means that these gcc ports currently do not work reliably and therefore more or less useless.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to help@…:

libstdc++ port isn't what I have in mind. I wanted a way for gcc46 to use system libstdc++. I tried just now to replace /opt/local/include/gcc46/c++/ content with /usr/include/c++/4.2.1/, but gcc failed to understand them correctly and exited with some error about _is_pod in cpp_type_traits.h. So incompatibility is both ways :( Unless you have something more up your sleeve

What I have "up my sleeves" is libstdc++ STL on top of libc++abi. That has been done by Apple for gcc-4.2's libstdc++ as shipped in Lion and Mountain Lion. If you want newer libstdc++, you will need to merge those changes into newer gcc and create a new port for them. As I mentioned, the license of newer gcc prevents me from doing this work, but hopefully someone able to work on GPL3 will be willing to touch it.

, it basicly means that these gcc ports currently do not work reliably and therefore more or less useless.

So... basically things are still broken, but they're now broken differently (and perhaps more obviously). I prefer obvious breakage over invisible breakage, so I'll take this as progress.

[cjones051073 (Chris Jones)]

I totally disagree things are better now., the previous situation seemed much better to me. At least we could actually compile using the gcc compilers... Maybe there was some theoretical instability mixing libstdc++ versions, but I never had any.

Things changes have caused various ports to stop working. For instance all the gcc variants the root port provide. root provides a interactive C++ environment so the user really may have a reason for wanting a particular gcc version. Not to mention fortran support.

Please considering reverting this, until you have the better solution ready.

[cjones051073 (Chris Jones)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

I totally disagree things are better now., the previous situation seemed much better to me. At least we could actually compile using the gcc compilers... Maybe there was some theoretical instability mixing libstdc++ versions, but I never had any.

comment:2 above shows that it's not a theoretical instability.

Things changes have caused various ports to stop working. For instance all the gcc variants the root port provide. root provides a interactive C++ environment so the user really may have a reason for wanting a particular gcc version. Not to mention fortran support.

Please considering reverting this, until you have the better solution ready.

I will try adding a libstdc++ port based on libc++sup as an interim solution, but in order to really fix this, someone will need to port it to libc++abi to be compatible with the host runtime.

[cawka (Alex Afanasyev)]

I also vote to return to the previous state, at least until there is a separate libstc++ port.

I agree that the instability from comment:2 is not theoretical and I can easily reproduce it. At the same time, I can easily solve the problem by stopping mixing the compilers when I compile my code. Long time ago there was already a ticket for "pointer being freed was not allocated" error, where the a suggested solution. While the solution is not really working, the key point is not mixing stuff.

Those who is not using gc4[4-8] have no problem. Those who are using, just need to accept the fact that there is an incompatibility if compilers are mixed. The removal of std++ solve solvable problem for a subset of developers using gcc, but creates unsolvable problem for others who rely on c++11 and other new features of standard library.

[cjones051073 (Chris Jones)]

Replying to jeremyhu@…:

Replying to jonesc@…:

I totally disagree things are better now., the previous situation seemed much better to me. At least we could actually compile using the gcc compilers... Maybe there was some theoretical instability mixing libstdc++ versions, but I never had any.

comment:2 above shows that it's not a theoretical instability.

OK, point taken. Poor choice of words. What I mean't was the old mode of 'breakage' did not seem to be causing that much trouble. Yes, we should work to fix it, but don't change to an even more broken situation as we have now (i.e., compilers that cannot, hmm, compile) ..

Things changes have caused various ports to stop working. For instance all the gcc variants the root port provide. root provides a interactive C++ environment so the user really may have a reason for wanting a particular gcc version. Not to mention fortran support.

Please considering reverting this, until you have the better solution ready.

I will try adding a libstdc++ port based on libc++sup as an interim solution, but in order to really fix this, someone will need to port it to libc++abi to be compatible with the host runtime.

Thanks but can I also request that the changes are reverted until this is done, if it is going to take a bit of time. The current situation with totally broken compilers, that users cannot use to build the simplest standalone code, is really not ideal...

[cjones051073 (Chris Jones)]

Replying to alexander.afanasyev@…:

I also vote to return to the previous state, at least until there is a separate libstc++ port.

I agree that the instability from comment:2 is not theoretical and I can easily reproduce it. At the same time, I can easily solve the problem by stopping mixing the compilers when I compile my code. Long time ago there was already a ticket for "pointer being freed was not allocated" error, where the a suggested solution. While the solution is not really working, the key point is not mixing stuff.

Those who is not using gc4[4-8] have no problem. Those who are using, just need to accept the fact that there is an incompatibility if compilers are mixed. The removal of std++ solve solvable problem for a subset of developers using gcc, but creates unsolvable problem for others who rely on c++11 and other new features of standard library.

Exactly my point. Please remember that the gcc4X compilers are *not* just there to provide alternative options to build ports, but people also use them to build their own code. If I install the latest gcc4X, it might well be because I really do want the new features that come with that new compiler.

[angelo.graziosi@…]

At this point it is obvious that the changes in GCCs are totally wrong... I have seen anywhere that an "hybrid" (GCC47 and friends + libstd++ from GCC42) will work.

So, the minimum, is reverting the changes until the ideas become more clear...

Ryan, what do you think about this?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Thanks but can I also request that the changes are reverted until this is done, if it is going to take a bit of time. The current situation with totally broken compilers, that users cannot use to build the simplest standalone code, is really not ideal...

Reverting the changes is a waste of time, IMO. I don't want to force users to rebuild again and then change it back and have them rebuild yet again. I'm already working on the libstdc++ port based on libc++sup. That's a fairly straightforward thing to implement. The *real* fix is going to be moving this to libc++abi, but until that is done, this libstdc++ will be no more broken than the old way.

After it's in place, I'll bump the gcc ports again to have them depend on it and setup their symlink to point to it instead of /usr/lib/libstdc++.

Replying to jonesc@…:

Exactly my point. Please remember that the gcc4X compilers are *not* just there to provide alternative options to build ports, but people also use them to build their own code. If I install the latest gcc4X, it might well be because I really do want the new features that come with that new compiler.

Unfortunately the gcc4X ports are not useful for actually shipping code to end users. They're simply hobbyist compilers as they are now. I'm trying to help get them to a more usable state.

Replying to angelo.graziosi@…:

At this point it is obvious that the changes in GCCs are totally wrong... I have seen anywhere that an "hybrid" (GCC47 and friends + libstd++ from GCC42) will work.

So, the minimum, is reverting the changes until the ideas become more clear...

What ideas do you want to "become more clear" ... ?

[jeremyhu (Jeremy Huddleston Sequoia)]

FWIW, I expect to check in something in the next hour or so which should solve this (modulo the need to libc++sup vs libc++abi issue).

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, I have a solution, but svn is down, so I can't commit...

[jeremyhu (Jeremy Huddleston Sequoia)]

libstdcxx.patch

[jeremyhu (Jeremy Huddleston Sequoia)]

r97687

[help@…]

Am I missing something or you forgot to commit libstdcxx port itself? Edit: ah, got it, nevermind.

[zabbarob@…]

Cc Me!

[vic@…]

Cc Me!

[vic@…]

Replying to jeremyhu@…:

The gcc ports ship libstdc++. They should not ship this runtime; they should instead use the hosts's runtime.

This might very well fix my octave-devel problem 36103, but I don't understand how to apply the patch to gcc45. How does one apply it? I see the schema

  %% patch -p0 < ~/Downloads/Portfile-postfix.diff

Would something like this work with the g45 patch?

[gnw3]

Replying to jeremyhu@…:

Ok, I have a solution, but svn is down, so I can't commit...

After updating, I have /opt/local/lib/gcc4?/libstdc++.6.dylib symlinks, but the configure script for octave-devel complains that it can't find libstdc++.dylib in the check for the size of an integer. Adding /opt/local/lib/gcc4?/libstdc++.dylib symlinks seems to be needed.

[jeremyhu (Jeremy Huddleston Sequoia)]

This morning, I noticed that base complains about the + in the depspec, so I pushed r97700 which should address this particular issue.

Replying to gnwiii@…:

Replying to jeremyhu@…:

Ok, I have a solution, but svn is down, so I can't commit...

After updating, I have /opt/local/lib/gcc4?/libstdc++.6.dylib symlinks, but the configure script for octave-devel complains that it can't find libstdc++.dylib in the check for the size of an integer. Adding /opt/local/lib/gcc4?/libstdc++.dylib symlinks seems to be needed.

You should have:

$ port contents libstdcxx-devel
Port libstdcxx-devel contains:
  /opt/local/lib/.libstdcxx
  /opt/local/lib/libstdc++.6.dylib
  /opt/local/lib/libstdc++.dylib

or similar for libstdcxx. The symlinks in the gcc directories should point to /opt/local/lib/libstdc++.6.dylib.

lib/gcc4?/libstdc++.dylib will be used at linktime to ensure that the compiler uses *this* libstdc++.dylib rather than the one in /usr. lib/gcc4?/libstdc++.6.dylib will be used at runtime to redirect binaries linked with the older versions of the gcc ports to find the common runtime.

[cjones051073 (Chris Jones)]

Can I ask, how long is reasonable to expect before an should update come though ? I ask since revision 4 is stilll the latest I get for gcc47

macmini ~ > sudo port sync ; sudo port outdated
--->  Updating the ports tree
The following installed ports are outdated:
gcc47                          4.7.1_2 < 4.7.1_4         
gcc48                          4.8-20120826_0 < 4.8-20120909_2   

even though a update to gcc47 revision 6 was committed a while back now.

Chris.

[cjones051073 (Chris Jones)]

that should be

macmini ~ > sudo port sync ; sudo port outdated
Password:
--->  Updating the ports tree
The following installed ports are outdated:
gcc47                          4.7.1_2 < 4.7.1_4         
gcc48                          4.8-20120826_0 < 4.8-20120909_2   

[jeremyhu (Jeremy Huddleston Sequoia)]

Well it's in svn, so you can get it now if you use svn as your dports source ... just 'port sync' ... if you use rsync, you'll need to wait for the mirrors to catch up or just go download it directly (click Browse Source above).

[cjones051073 (Chris Jones)]

I just use whatever the default 'sudo port sync' provides, like any other general macports user, which seems stuck on revision 4 for gcc47 (4.7.1)...

[angelo.graziosi@…]

Replying to jeremyhu@…:

Well it's in svn, so you can get it now if you use svn as your dports source ... just 'port sync' ... if you use rsync, you'll need to wait for the mirrors to catch up or just go download it directly (click Browse Source above).

I seriously doubt that it is just a matter of mirror updating... Usually I find a commitment a few minutes (if not seconds) after it has been done...

[neverpanic (Clemens Lang)]

The rsync mirror seems to be outdated. Thanks for the report, I have taken this to our admins: ​http://lists.macosforge.org/pipermail/macports-dev/2012-September/020370.html.

JFYI: The rsync mirror usually updates every other half hour.

[cjones051073 (Chris Jones)]

I agree something seems not right here, as I am also not seeing the latest updates e.g..

macmini ~ > sudo port sync ; sudo port outdated
Password:
--->  Updating the ports tree
The following installed ports are outdated:
gcc47                          4.7.1_2 < 4.7.1_4         
gcc48                          4.8-20120826_0 < 4.8-20120909_2

so revision 4 for gcc47 is still the latest available via svn, as of right now, even though Jeremy updated things while back.

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

It may be a mirroring issue considering the infrastructure changes that went into effect yesterday. Respond to the thread about it on macports-dev if you're still having issues.

You can also just grab the Portfile yourself from browser:trunk/dports/lang/gcc47/Portfile​

[cjones051073 (Chris Jones)]

Thanks. Personally, I am not interested in doing anything 'Average-Joe-User' wouldn't do, so I will wait until the infrastructure issues are fixed. cheers Chris

[angelo.graziosi@…]

libstdcxx-devel main.log

[angelo.graziosi@…]

Now the infrastructure works, but there still is a problem between gcc48 and libstdcxx-devel:

$ sudo port selfupdate; sudo port outdated
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.1.2 installed,
MacPorts base version 2.1.2 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
The following installed ports are outdated:
gcc45                          4.5.4_3 < 4.5.4_4         
gcc46                          4.6.3_6 < 4.6.3_7         
gcc47                          4.7.1_4 < 4.7.1_6         
gcc48                          4.8-20120909_2 < 4.8-20120909_4


$ sudo port upgrade outdated
--->  Computing dependencies for libstdcxx
--->  Fetching archive for libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_6.darwin_11.x86_64.tbz2 from http://packages.macports.org/libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_6.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_6.darwin_11.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libstdcxx
--->  Fetching distfiles for libstdcxx
--->  Verifying checksum(s) for libstdcxx
--->  Extracting libstdcxx
--->  Applying patches to libstdcxx
--->  Configuring libstdcxx
--->  Building libstdcxx
--->  Staging libstdcxx into destroot
--->  Installing libstdcxx @4.7.1_6
--->  Activating libstdcxx @4.7.1_6
--->  Cleaning libstdcxx
--->  Computing dependencies for gcc45
--->  Fetching archive for gcc45
--->  Attempting to fetch gcc45-4.5.4_4.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc45
--->  Attempting to fetch gcc45-4.5.4_4.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/gcc45
--->  Attempting to fetch gcc45-4.5.4_4.darwin_11.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gcc45
--->  Fetching distfiles for gcc45
--->  Verifying checksum(s) for gcc45
--->  Extracting gcc45
--->  Applying patches to gcc45
--->  Configuring gcc45
--->  Building gcc45
--->  Staging gcc45 into destroot
--->  Installing gcc45 @4.5.4_4
--->  Cleaning gcc45
--->  Computing dependencies for gcc45
--->  Deactivating gcc45 @4.5.4_3
--->  Cleaning gcc45
--->  Activating gcc45 @4.5.4_4
--->  Cleaning gcc45
--->  Computing dependencies for gcc46
--->  Fetching archive for gcc46
--->  Attempting to fetch gcc46-4.6.3_7.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc46
--->  Attempting to fetch gcc46-4.6.3_7.darwin_11.x86_64.tbz2 from http://lil.fr.packages.macports.org/gcc46
--->  Attempting to fetch gcc46-4.6.3_7.darwin_11.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/gcc46
--->  Fetching distfiles for gcc46
--->  Verifying checksum(s) for gcc46
--->  Extracting gcc46
--->  Configuring gcc46
--->  Building gcc46
--->  Staging gcc46 into destroot
--->  Installing gcc46 @4.6.3_7
--->  Cleaning gcc46
--->  Computing dependencies for gcc46
--->  Deactivating gcc46 @4.6.3_6
--->  Cleaning gcc46
--->  Activating gcc46 @4.6.3_7
--->  Cleaning gcc46
--->  Computing dependencies for gcc47
--->  Fetching archive for gcc47
--->  Attempting to fetch gcc47-4.7.1_6.darwin_11.x86_64.tbz2 from http://packages.macports.org/gcc47
--->  Attempting to fetch gcc47-4.7.1_6.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/gcc47
--->  Installing gcc47 @4.7.1_6
--->  Cleaning gcc47
--->  Computing dependencies for gcc47
--->  Deactivating gcc47 @4.7.1_4
--->  Cleaning gcc47
--->  Activating gcc47 @4.7.1_6
--->  Cleaning gcc47
--->  Computing dependencies for libstdcxx-devel
--->  Fetching archive for libstdcxx-devel
--->  Attempting to fetch libstdcxx-devel-4.8-20120909_4.darwin_11.x86_64.tbz2 from http://packages.macports.org/libstdcxx-devel
--->  Attempting to fetch libstdcxx-devel-4.8-20120909_4.darwin_11.x86_64.tbz2.rmd160 from http://packages.macports.org/libstdcxx-devel
--->  Installing libstdcxx-devel @4.8-20120909_4
--->  Activating libstdcxx-devel @4.8-20120909_4
Error: org.macports.activate for port libstdcxx-devel returned: Image error: /opt/local/lib/.libstdcxx is being used by the active libstdcxx port.  Please deactivate this port first, or use 'port -f activate libstdcxx-devel' to force the activation.
Please see the log file for port libstdcxx-devel for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc48/libstdcxx-devel/main.log
Error: Problem while installing libstdcxx-devel
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

Attached the main.log

[jeremyhu (Jeremy Huddleston Sequoia)]

It's telling you what to do:

Error: org.macports.activate for port libstdcxx-devel returned: Image error: /opt/local/lib/.libstdcxx is being used by the active libstdcxx port.  Please deactivate this port first, or use 'port -f activate libstdcxx-devel' to force the activation.
Please see the log file for port libstdcxx-devel for details:

If you want to use gcc48, you need to use libstdcxx-devel rather than libstdcxx.

[cjones051073 (Chris Jones)]

So it is no longer possible to have both gcc47 and gcc48 installed at the same time ?

[cjones051073 (Chris Jones)]

In ticket #36093 Angelo has reported that root now builds with gcc47, but at run time we get

Error Loading libTrackMathCoreDictdyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

Based on comment:52 above, I believe the installation used the binary tarballs for darwin 11, so I am wondering if there is a mis-match here if the user has a different /usr/lib/libSystem.B.dylib to that on the build bot ?

Angelo, could you try reinstalling gcc47 and libstdcxx, forcing a build from source (port -s) ?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

So it is no longer possible to have both gcc47 and gcc48 installed at the same time ?

No, you just need to use libstdcxx-devel. gcc47 will accept either.

let's not use this ticket as a ticket for everything related to libstdc++. I'll followup on that other comment in its own ticket.

[cjones051073 (Chris Jones)]

let's not use this ticket as a ticket for everything related to libstdc++. I'll followup on that other comment in its own ticket.

Fair enough. Is there a ticket for this already, or would you like me to create on ?

[angelo.graziosi@…]

Replying to jonesc@…:

In ticket #36093 Angelo has reported that root now builds with gcc47, but at run time we get

Error Loading libTrackMathCoreDictdyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: ___emutls_get_address
  Referenced from: /opt/local/lib/libstdc++.6.dylib
  Expected in: /usr/lib/libSystem.B.dylib

Based on comment:52 above, I believe the installation used the binary tarballs for darwin 11, so I am wondering if there is a mis-match here if the user has a different /usr/lib/libSystem.B.dylib to that on the build bot ?

Angelo, could you try reinstalling gcc47 and libstdcxx, forcing a build from source (port -s) ?

I am afraid but I can try the rebuild only tomorrow (24 hours) when I will have a connection which allow me for the use of "port" :-(

Angelo

[angelo.graziosi@…]

Replying to jeremyhu@…:

It's telling you what to do:

Error: org.macports.activate for port libstdcxx-devel returned: Image error: /opt/local/lib/.libstdcxx is being used by the active libstdcxx port.  Please deactivate this port first, or use 'port -f activate libstdcxx-devel' to force the activation.
Please see the log file for port libstdcxx-devel for details:

If you want to use gcc48, you need to use libstdcxx-devel rather than libstdcxx.

Leaving aside the confusion which all this generates, how can an user know "a priori" that he have to use libstdcxx-devel? No, there is something not clear here...

Angelo

[cjones051073 (Chris Jones)]

Probably better anyway to do follow Jeremy's suggestions of things to try anyway...

[vic@…]

The recent upgrade of gcc45 appears to have solved an "undefined symbols" problem with octave-devel 36103, but the octave-devel build still breaks down with a malloc error. I have no idea if this is related to gcc.

[angelo.graziosi@…]

Replying to jonesc@…:

Probably better anyway to do follow Jeremy's suggestions of things to try anyway...

Hmm.. If I understand, libstdcxx and libstdcxx-devel are two ports which conflict each other, this means that, since gcc47 and gcc48 depend on these two ports, they conflict too...

Why should one violate the MacPorts rule that two conflicting ports cannot be installed at the same time? Doing otherwise would be a messy solution. So I will uninstall gcc48 if it conflicts with gcc47.

This is the first case I meet in which two version of GCC cannot be installed on the same system (also the first case in which something goes in a .../.libstdcxx directory).

The suggested fix (installing *only* libstdcxx-devel) is a workaround and non the main way to fix a problem.

BTW, just a new ticket, #36127, has been open regarding this problem...

Angelo

[jeremyhu (Jeremy Huddleston Sequoia)]

Angelo, installing just the -devel version is not the workaround. It is the solution. I designed it this way. The devel version of gcc needs the devel libstdcxx. All others will work with the devel or stable version.

[seanfarley (Sean Farley)]

Replying to jeremyhu@…:

Angelo, installing just the -devel version is not the workaround. It is the solution. I designed it this way. The devel version of gcc needs the devel libstdcxx. All others will work with the devel or stable version.

... ? Why can't you do a prefix install in this case (in alignment with the rest of macports)?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to sean.michael.farley@…:

Replying to jeremyhu@…:

Angelo, installing just the -devel version is not the workaround. It is the solution. I designed it this way. The devel version of gcc needs the devel libstdcxx. All others will work with the devel or stable version.

... ? Why can't you do a prefix install in this case (in alignment with the rest of macports)?

I'm not sure what your question is here. This is consistent with the rest of MP. It's just like pixman-devel conflicting with pixman, cairo-devel vs cairo, ffmpeg-devel vs ffmpeg, ...

[cjones051073 (Chris Jones)]

Sorry to come back to this otherwise finished thread.... but it looks like there is an issue with libstdcxx versus libstdcxx-devel.

As I understand it, gcc47 and older require libstdcxx, whereas gcc48 needs libstdcxx-devel. However, if libstdcxx-devel is installed, gcc47 and older will happily use it ?

This though, doesn't seem to work with the current versions. I have gcc48 and libstdcxx-devel installed, but if I try and install gcc46 it still tries to bring libstdcxx in, which fails.

macmini ~/Projects/MacPorts/portfiles > sudo port installed | grep libstdcxx
  libstdcxx-devel @4.8-20120909_101 (active)
macmini ~/Projects/MacPorts/portfiles > sudo port installed | grep gcc
  gcc48 @4.8-20120909_4 (active)
  gcc_select @0.1_7 (active)
macmini ~/Projects/MacPorts/portfiles > sudo port install gcc47
--->  Computing dependencies for gcc47
--->  Dependencies to be installed: libstdcxx
--->  Fetching archive for libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_101.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_101.darwin_12.x86_64.tbz2 from http://lil.fr.packages.macports.org/libstdcxx
--->  Attempting to fetch libstdcxx-4.7.1_101.darwin_12.x86_64.tbz2 from http://packages.macports.org/libstdcxx
--->  Fetching distfiles for libstdcxx
--->  Attempting to fetch gcc-4.7.1.tar.bz2 from http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/gcc47
--->  Attempting to fetch ecj-4.5.jar from http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/gcc47
--->  Verifying checksum(s) for libstdcxx
--->  Extracting libstdcxx
--->  Applying patches to libstdcxx
--->  Configuring libstdcxx
--->  Building libstdcxx
--->  Staging libstdcxx into destroot
--->  Installing libstdcxx @4.7.1_101
--->  Activating libstdcxx @4.7.1_101
Error: org.macports.activate for port libstdcxx returned: Image error: /opt/local/lib/.libstdcxx is being used by the active libstdcxx-devel port.  Please deactivate this port first, or use 'port -f activate libstdcxx' to force the activation.
Error: Failed to install libstdcxx
Please see the log file for port libstdcxx for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/libstdcxx/main.log
Error: The following dependencies were not installed: libstdcxx
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port gcc47 failed

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Chris, please open a new ticket for that issue. That's probably a depspec bug.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jonesc@…:

As I understand it, gcc47 and older require libstdcxx, whereas gcc48 needs libstdcxx-devel. However, if libstdcxx-devel is installed, gcc47 and older will happily use it ?

That is the intention, as I understand it.

This though, doesn't seem to work with the current versions.

Agreed. The depspec would have been correct if the libstdcxx{,-devel} ports had installed a file /opt/local/lib/libstdc++.dylib, but they don't; they install a file /opt/local/lib/libstdc++.6.dylib. I updated the depspecs in the gcc ports in r97901.

It would be nice if the libstdcxx{,-devel} ports would install a symlink /opt/local/lib/libstdc++.dylib so that we could put the depspecs back the way they were.

[cjones051073 (Chris Jones)]

Thanks for the fix. Do you still need another ticket for this or not ?

[jeremyhu (Jeremy Huddleston Sequoia)]

Ah, sorry I missed that.

The subports intentionally don't install a /opt/local/lib/libstdc++.dylib symlink because that would cause clang++ to link against /opt/local/lib/libstdc++ instead of /usr/lib/libstdc++ and thus possibly infect clang++-generated code with the same issues plaguing g++ (libc++abi vs libsupc++ in the same process).

[cooljeanius (Eric Gallager)]

Cc Me!

[larryv (Lawrence Velázquez)]

Cc Me!