Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#41316 closed defect (fixed)

qt4-mac: Warning about libstdc++ after installation ( r113176 does not work for me )

Reported by: george.sklivanitis@… Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.2.99
Keywords: mavericks Cc: mkae (Marko Käning)
Port: qt4-mac

Description (last modified by neverpanic (Clemens Lang))

I have the qt4-mac port installed on Mavericks. However, I always see the following warning after building ports:

sudo port install gnuradio +all
--->  Computing dependencies for gnuradio
--->  Cleaning gnuradio
--->  Scanning binaries for linking errors: 81.4%
Warning: /opt/local/bin/qmake uses /usr/lib/libstdc++.6.dylib as C++ standard library although macports::cxx_stdlib is set to libc++.
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.

I followed the instructions of r113176 but still I have the same problem

Attachments (1)

qt4-mac-configure-log.txt.bz2 (16.3 KB) - added by george.sklivanitis@… 10 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 10 years ago by neverpanic (Clemens Lang)

Description: modified (diff)

This is a false positive, IMO. I'm not very happy with this warning, since it's essentially in the wrong place. This shouldn't be printed every time rev-upgrade runs, but in a new to-be-written phase after destroot. Porting to libc++ is not a no-brainer, especially for larger projects, and should probably be left for upstream.

comment:2 Changed 10 years ago by michaelld (Michael Dickens)

This warning is just a warning. It is OK that qmake links to libstdc++, so long as internal to Qt the default linkage is to libc++ (which it is).

If you want to get rid of this warning, do:

sudo port -f uninstall qt4-mac
sudo port install qt4-mac

although you might want to wait until I fix #41314, since apparently I broke qt4-mac on 10.9 with the commit you mention. I'm working on it right now.

comment:3 Changed 10 years ago by george.sklivanitis@…

Might this be the problem why I can't run any python module of gnuradio (e.g., benchmark_tx.py)?

comment:4 Changed 10 years ago by michaelld (Michael Dickens)

If you are using 10.9, then you can't use Python because SWIG does not properly support the C++11 parts of std::vector that are required by GNU Radio. I'm working on that too; I don't know which issue is more difficult.

comment:5 Changed 10 years ago by michaelld (Michael Dickens)

I just pushed r113188, which fixed ticket #41314. It takes ~30 minutes for changes to go live, so check back around 4:50 PM/US/ET because you do the qt4-mac reinstall I posted above.

comment:6 in reply to:  5 Changed 10 years ago by george.sklivanitis@…

Michael, even with r113188 I get the same message as described above.

Replying to michaelld@…:

I just pushed r113188, which fixed ticket #41314. It takes ~30 minutes for changes to go live, so check back around 4:50 PM/US/ET because you do the qt4-mac reinstall I posted above.

comment:7 Changed 10 years ago by michaelld (Michael Dickens)

Did you do the uninstall, (re)install I listed above? I didn't do a rev-bump to force this, since this is a relatively minor issue. If you did, then please do the following:

sudo port clean qt4-mac
sudo port configure qt4-mac
cp `port logfile qt4-mac` ~/Desktop/qt4-mac-configure-log.txt
bzip2 ~/Desktop/qt4-mac-configure-log.txt

and then attach the resulting compressed file to this ticket. It is certainly possible there are cases that I missed that need to be addressed.

Changed 10 years ago by george.sklivanitis@…

comment:8 Changed 10 years ago by michaelld (Michael Dickens)

I check tickets when someone posts text to them with much greater probability than when someone just posts a file -- so, sorry for the long delay. A lot has happened in the 3 weeks since you posted the last file: If you're following things, gnuradio now works on 10.9 with full Python / SWIG support. From the file you posted, it looks like you do have the updates that should fix this issue. So .... is this still an issue for you?

comment:9 Changed 10 years ago by michaelld (Michael Dickens)

Cc: michaelld@… removed
Owner: changed from macports-tickets@… to michaelld@…

comment:10 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:11 Changed 10 years ago by michaelld (Michael Dickens)

By now, surely this is no longer an issue? There are now a bunch of ports with this warning, at least for me on 10.9. Also, it does no harm ... just a minor nuisance.

comment:12 Changed 10 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

I'm closing this ticket. The issue does no harm, and it should have been fixed in various revisions by now. AND: There are plenty of other ports with this issue.

comment:13 Changed 10 years ago by neverpanic (Clemens Lang)

The code that printed this warning is gone from trunk.

comment:14 Changed 10 years ago by michaelld (Michael Dickens)

Ah; I didn't know that the code was gone; is this recent? We need a new release (2.2.2? I think 2.3.0 would be better given the number of changes) for all of the changes since the last release to be useful for folks like the OP here (and, I think, at least a few others tickets too). Thanks for the info.

comment:15 Changed 10 years ago by neverpanic (Clemens Lang)

Version: 2.2.12.2.99

The code that printed the warning never was in a released version of MacPorts. The reporter must be running trunk.

Yes, the code was only removed recently by me -- accidentally in the commit that switched to a local copy of Tcl 8.5 because I had it sitting around in my working copy for a while, but we agreed on -dev to leave it that way.

A new 2.3 release would be good yes, and I'm going to be pushing all the necessary people and doing some of the work on my own if I have to.

Note: See TracTickets for help on using tickets.