Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#35770 closed defect (fixed)

gcc ports should not include a C++ runtime

Reported by: jeremyhu (Jeremy Huddleston Sequoia) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: libstdc++ Cc: mfeiri, jeremyhu (Jeremy Huddleston Sequoia), su-v, help@…, neverpanic (Clemens Lang), cawka (Alex Afanasyev), eborisch (Eric A. Borisch), todmorrison (Tod Morrison), cjones051073 (Chris Jones), zabbarob@…, vic@…, cooljeanius (Eric Gallager), larryv (Lawrence Velázquez)
Port: gcc43 gcc44 gcc45 gcc46 gcc47 gcc48

Description

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

Attachments (2)

libstdcxx.patch (11.0 KB) - added by jeremyhu (Jeremy Huddleston Sequoia) 12 years ago.
libstdcxx.patch
libstdcxx-devel-main.log.bz2 (1.6 KB) - added by angelo.graziosi@… 12 years ago.
libstdcxx-devel main.log

Download all attachments as: .zip

Change History (74)

comment:1 Changed 12 years ago by su-v

Cc: suv-sf@… added

Cc Me!

comment:2 Changed 12 years ago by 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.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:3 Changed 12 years ago by help@…

Cc: help@… added

Cc Me!

comment:4 Changed 12 years ago by neverpanic (Clemens Lang)

Cc: cal@… added

Cc Me!

comment:5 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Status: newassigned

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.

comment:6 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

gcc4X are fixed with r97657

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by cawka (Alex Afanasyev)

Cc: alexander.afanasyev@… added

Cc Me!

comment:9 Changed 12 years ago by eborisch (Eric A. Borisch)

Cc: eborisch@… added

Cc Me!

comment:10 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: assignedclosed

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

comment:11 Changed 12 years ago by 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
Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:12 Changed 12 years ago by 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.

comment:13 Changed 12 years ago by todmorrison (Tod Morrison)

Resolution: fixed
Status: closedreopened

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.

comment:14 Changed 12 years ago by 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.

comment:15 Changed 12 years ago by todmorrison (Tod Morrison)

Cc: todmorrison@… added

Cc Me!

comment:16 in reply to:  12 Changed 12 years ago by 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.

comment:17 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: reopenedclosed

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

comment:19 Changed 12 years ago by help@…

Resolution: fixed
Status: closedreopened

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.

comment:20 in reply to:  19 Changed 12 years ago by 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.

comment:21 Changed 12 years ago by help@…

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

I personally want gcc46 for OpenMP support.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:22 in reply to:  21 Changed 12 years ago by 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.

comment:23 in reply to:  19 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: reopenedclosed

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.

comment:24 Changed 12 years ago by 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.

comment:25 in reply to:  24 Changed 12 years ago by 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.

comment:26 Changed 12 years ago by 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.

comment:27 Changed 12 years ago by cjones051073 (Chris Jones)

Cc: jonesc@… added

Cc Me!

comment:28 in reply to:  26 Changed 12 years ago by 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.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:29 Changed 12 years ago by 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.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:30 Changed 12 years ago by 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...

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:31 in reply to:  29 Changed 12 years ago by 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.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:32 Changed 12 years ago by 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?

comment:33 in reply to:  32 Changed 12 years ago by 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" ... ?

comment:34 Changed 12 years ago by 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).

comment:35 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: libstdcxx.patch added

libstdcxx.patch

comment:36 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

comment:37 Changed 12 years ago by help@…

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

Last edited 12 years ago by help@… (previous) (diff)

comment:38 Changed 12 years ago by zabbarob@…

Cc: zabbarob@… added

Cc Me!

comment:39 Changed 12 years ago by vic@…

Cc: vic@… added

Cc Me!

comment:40 in reply to:  description Changed 12 years ago by 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?

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:41 in reply to:  35 ; Changed 12 years ago by 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.

comment:42 in reply to:  41 Changed 12 years ago by 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.

comment:43 Changed 12 years ago by 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.

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:44 Changed 12 years ago by 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   


comment:45 Changed 12 years ago by 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).

comment:46 Changed 12 years ago by 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)...

comment:47 in reply to:  45 Changed 12 years ago by 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...

comment:48 Changed 12 years ago by 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.

Last edited 12 years ago by neverpanic (Clemens Lang) (previous) (diff)

comment:49 Changed 12 years ago by 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

comment:50 Changed 12 years ago by 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

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:51 Changed 12 years ago by 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

Changed 12 years ago by angelo.graziosi@…

libstdcxx-devel main.log

comment:52 Changed 12 years ago by 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

comment:53 Changed 12 years ago by 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.

comment:54 Changed 12 years ago by cjones051073 (Chris Jones)

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

comment:55 Changed 12 years ago by 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) ?

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:56 in reply to:  54 ; Changed 12 years ago by 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.

comment:57 in reply to:  56 Changed 12 years ago by 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 ?

comment:58 in reply to:  55 Changed 12 years ago by 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

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:59 in reply to:  53 Changed 12 years ago by 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

comment:60 Changed 12 years ago by cjones051073 (Chris Jones)

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

comment:61 Changed 12 years ago by 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.

comment:62 in reply to:  60 Changed 12 years ago by 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

comment:63 Changed 12 years ago by 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.

comment:64 in reply to:  63 ; Changed 12 years ago by 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)?

comment:65 in reply to:  64 Changed 12 years ago by 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, ...

Last edited 12 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:66 Changed 12 years ago by 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

comment:67 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:68 in reply to:  66 Changed 12 years ago by 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.

comment:69 Changed 12 years ago by cjones051073 (Chris Jones)

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

comment:70 Changed 12 years ago by 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).

comment:71 Changed 12 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:72 Changed 11 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

Note: See TracTickets for help on using tickets.