Closed gillins closed 8 years ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
Cool, thanks @gillins
Thanks @gillins. I really appreciate you taking the lead on this issue. Are there any more cases that we know of that need to switch?
Also LGTM. 😄
libtiff
(has a C++ extension), gdal
, qt
(and maybe pyqt4
- I haven't checked) are the ones I know about. But I'm sure there will be others....
Looks like Windows Python 2.7 64-bit is failing. Not sure that why this change would cause that. Is this a known issue? Do we need to open one?
Same thing in kealib
(https://github.com/conda-forge/kealib-feedstock/pull/4). Sounds like @msarahan has it under control :smile:
Thanks for the list. Thanks for the cross-ref too.
Yeah, Qt uses C++ so anything using Qt directly (PyQt, PySide, etc.) will also be in C++.
Though it is important to note that the issue is when C++ objects cross the boundary between a libstdc++
-based library and a libc++
-based library (Windows anyone?). If we have libraries linking to Qt that are linking to libraries using libc++
, then we definitely have a problem. If not, we don't have any issue.
I checked - Qt links against libstdc++
only. So my guess is that it won't work well with these other libs now that we have moved them to libc++
.
So, passing C objects across boundaries is ok though. This is what would be happening between Python and Qt. I expect we should be ok, but more investigation is certainly welcome.
Qt4 doesn't use ICU, but Qt5 will. Since Qt5 links against libc++, so this change is welcomed :-)
However, Boost uses ICU. But I think it's linking againts libc++ now, or is that not the case?
Glad to have you in the discussion, @ccordoba12. Was thinking of pinging you, but realized you are already watching the repo. 😄
Qt4 doesn't use ICU, but Qt5 will.
That was my recollection. Sorry, my comments above were a bit vague.
Since Qt5 links against libc++, so this change is welcomed :-)
Ah, ok. That's great news.
Just for my own curiosity, is there a reason libc++
is preferred?
However, Boost uses ICU. But I think it's linking againts libc++ now, or is that not the case?
That is correct. 😄
Just for my own curiosity, is there a reason libc++ is preferred?
Qt 5.6 needs C++11 support to compile one of its modules (QWebEngine), and the very ancient gcc
that comes with XCode (4.2.1, I think) doesn't support it. So we had to use clang to compile it and so Qt 5 is now linked against libc++ :-)
Yep, that makes perfect sense. Thank for the details.
Sounds like we are happy with this change, correct? Should we wait to fix AppVeyor somehow or should we go ahead with this as is and rerun AppVeyor later?
Also, looks like this affects libxml2
and cairo
directly.
Thanks @ocefpaf for restarting.
LGTM. Any objections on merging?
Guessing there are no complaints. Thanks @gillins.
Oops, forgot to ask that when unpin conda-build
, which is causing this issue ( https://github.com/conda-forge/icu-feedstock/issues/9 ). Sorry about that. See this PR ( https://github.com/conda-forge/icu-feedstock/pull/10 ).
I have changed the OS X package build number 3's label on the icu
package from "main" to "broken". It does not download by default any more, but is still available for inspection.
This adds support for the
toolchain
which fixes incorrect linking to the C++ runtime libs on OSX.ping @jakirkham