October 2015 - macports-tickets - lists.macosforge.org

[MacPorts] #48886: gcc47 @4.7.4_5: fails bootstrap comparison
by MacPorts 02 Oct '15

02 Oct '15

#48886: gcc47 @4.7.4_5: fails bootstrap comparison ------------------------+------------------- Reporter: dstrubbe@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: gcc47 ------------------------+------------------- This seems like a related issue to ticket #47410, though clang is not being used in this build, but rather /usr/bin/gcc-4.2. I am using XCode 3.2.6 on OSX 10.6.8. {{{ :info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/build' :info:build Comparing stages 2 and 3 :info:build warning: gcc/cc1-checksum.o differs :info:build warning: gcc/cc1obj-checksum.o differs :info:build warning: gcc/cc1objplus-checksum.o differs :info:build warning: gcc/cc1plus-checksum.o differs :info:build Bootstrap comparison failure! :info:build x86_64-apple-darwin10/libstdc++-v3/src/c++98/basic_file.o differs :info:build make[2]: *** [compare] Error 1 }}} main.log is attached. -- Ticket URL: <https://trac.macports.org/ticket/48886> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 02 Oct '15

02 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by mojca@…): Just a bit of teasing: After years of no activity on the Qt5 front and a year and a half of having conflicting Qt4/5 ports (basically: useless Qt5 port as long as one needed Qt4 somewhere) it is nice to see that a small and "stupid" incompatibility in 10.11 can finally start make the things moving ... ;) Truth to be told, it would be extremely helpful if we had more time to prepare for this event, but from what I understand all Qt dependents (both Qt4 and Qt5) are currently broken on 10.11, so fixing anything is of a relatively high priority. We probably cannot afford to spend months testing all the Qt dependents, so the scenario will probably be as follows(?): - warn all users (and developers) to avoid upgrades for the next X days if they are not willing to cope with consequences - do the radical changes in `qt4-mac` and `qt5-mac` (maybe we could even call those ports `qt4` and `qt5` and leave the old ports there during the transition period; then remove them) - ask everyone to fix as many dependent ports as quick as possible Or do you have better ideas about how to go on with all the shifting of Qt4 files? It takes days (certainly more than 24 hours) on my old mac to compile anything Qt-related, so testing multiple different installation options is an extremely painful process for me. But given how much effort René already put into trying to get things fixed also for KDE, it would be extremely helpful to take a careful look into his patches. If keeping some kind of consistent structure is important for KDE, I would be in favour of trying to obey at least some general guidelines and similarities with GNU/Linux to simplify compatibility. Having to have another copy of qt4-kde just for the sake of "more consistent" directories would be highly suboptimal and lots of extra work for everyone involved in Qt-related activities. And lots of extra disk space and precious processor time required. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:59> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 02 Oct '15

02 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Annoyingly I'm headed for a busy weekend in which I won't have much time for dev issues ... -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:58> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 02 Oct '15

02 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Replying to [comment:52 michaelld@…]: > What are the primary/major differences between your setup and the current on in MP? The one currently in MP being the "exclusive" version? The main difference with that install layout is the fact that libraries and executables are moved into ${prefix}/libexec/qt4. Everything that was already under a qt4 directory (share/qt4, doc/qt4) remained there (with maybe a few things moving around, but as little as possible). > -> Maybe: Send me a private email naming each new patch file & new variant and briefly what it addresses / does? I'm really not sure how to approach all of your changes! Erm, I think I have already done that a long time ago, about the time when I considered this port "done". > -> You know that I'm not going to just use what you provide out of the box. Why do you think I provide this as a "-devel" port? Yes, over time lots of changes have accumulated (and they should all be documented at least in the naming of patch files). I would in fact invite you to build this baby and see what comes out of that, and my offer stands to help out with any issues that arise from my work. port:qt4-mac is '''openmaintainer''', and if I'd had commit powers I'd have pushed qt4-mac-devel a long time ago already. > -> NOTE: I don't want a formal diff (e.g., "svn diff") between the current Portfile and yours; just too many changes to be able to parse what is what. I just included one because I was certain someone was going to insist on having it (and then telling me it's unreadable) :) > Nor do I care about the qt_dir install prefix, or parallel install, or transitional / exclusive or anything along those lines. Transitional was always just that, and easy to strip. I'm not even sure to what extent I myself still have ports that are built against the exclusive version. > We're going to move qt4-mac into ${prefix}/libexec/qt4-; period. If you mean that you plan to move anything into libexec/qt4-mac then I fear the only thing left that we might agree on is the possibility of a qt4-kde port analogous to port:qt5-kde I submitted the other day, which I'd maintain. I'm not interested in having to find out what issues I ran into with that all-in approach, but I'm sure it had to do with my KDE4 ports. > -> For example, I notice quite a number of patches added to yours, and some extra variants. Do these fix bugs in open MP (or other) ticket and/or add usable functionality? Do they allow for better building across more compilers / OSs (e.g., KDE, X11, Aqua)? I have not sought to address open MP tickets unless pointed to them specifically. But yes, every bit I added was to improve something: - the sqlite3 plugin was rolled back into the main port as it's required by some of the applications the main port installs (suggestion from Bradley Giesbrecht) - the default is to build without internal support for C++ exceptions except for the few modules which actually use them. That provides a leaner build with less overhead - an LTO variant provides a build with link-time optimisation. This again gives a leaner build with snappier performance. (This and the previous item were achieved with guidance from Thiago Macieira) - installation of the >200Mb of html docs is moved to a variant - a KDE variant addresses a number of issues that KDE4 apps/users (can) run into (much) more frequently (than pure Qt apps). - qprocess-nozombies.patch prevents zombie processes that could otherwise be left by QProcess - qt4-prevent-mousevent-for-deleted-object.diff : does what it says; this could lead to crashes in KDE4 apps due to pending events delivered to deleted objects - *exceptions* and *lto* patches have to do with the no-exceptions and LTO builds - patch-tools-build_qtconfig.diff : builds the qtconfig utility - patch-improve-fontweight-support2.diff, patch-fontpanel.diff : implement somewhat improved support for font weights other than regular/bold/italic /bold-italic - qt4-deactivate-menurole-heuristics.patch (+KDE) : disables part of the text-heuristics based guessing which menu QAction should become the About or Preferences menuitem, That shortcut is rather flaky which has led to annoying misses in KDE4 apps; the patch is included in the KDE variant only. - debug-negative-qtimerint.patch (+KDE): gives more useful feedback when a QTimer is started with a negative interval, something I've seen happen in KDE4 apps Other patches in the KDE variant prevent null-pointer dereference in QAction::isEnabled() (undoubtedly again due to pending event handling), make QFileSystemWatcher less verbose and add a means to keep track of the number of open file descriptors when using that class (relevant for KDevelop). If I missed anything just ask. I see that I left in a reference to qt4-mac-devel-x11 . That's a remnant of attempts to experiment with QPA support which clearly isn't finalised in Qt4. So no Qt4-X11 support I'm afraid. I also haven't had any reason to experiment with other compilers; I have done so with my Qt5 ports however, so maybe some of that knowledge can be applied here. If there's a reason... -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:57> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 02 Oct '15

02 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Replying to [comment:55 michaelld@…]: > Also true. Bottom line is that this patch allows Qt4 to build on 10.11 without resorting to using the 10.10 SDK; it seems to work correctly too. So, no matter the performance, this is a win at least for 10.11 users Of course, but wrapping it in a conditional in the Portfile also isn't a huge deal. And something the Qt devs couldn't do with their build system ;) -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:56> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 02 Oct '15

02 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by michaelld@…): Replying to [comment:54 rjvbertin@…]: > Replying to [comment:53 michaelld@…]: > > Well, this is the way the Qt folks do it in Qt5; I just back-ported it to Qt4. I don't care if it is more or less efficient. If it's good enough for Qt5 then it's good enough for Qt4 (IMHO). > You may be right, but Qt5 has lots of other changes under the hood which may make this particular code path much less of a bottleneck that it *maybe* is in Qt4 Also true. Bottom line is that this patch allows Qt4 to build on 10.11 without resorting to using the 10.10 SDK; it seems to work correctly too. So, no matter the performance, this is a win at least for 10.11 users (who will be numerous shortly, since Apple just gives away the OS). I also doubt that the performance is very different between the original and this version, as the primary change is in "QCoreGraphicsPaintEngine::clearColorSpace", which, really, isn't likely to be used very often (do a grep though the qt4 source & you'll find a few references to this; grep those & you find almost no references). This method was removed in Qt5 sometime; apparently it really isn't used much if at all. Thus, I don't worry about performance, either. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:55> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49053: qca-ossl fails to build on El Capitan
by MacPorts 02 Oct '15

02 Oct '15

#49053: qca-ossl fails to build on El Capitan --------------------+-------------------------------- Reporter: bas@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: qca-ossl --------------------+-------------------------------- qca-ossl 2.0.0-beta3_4.darwin_15.x86_64 fails to build with error :info:configure Error: need OpenSSL! -- Ticket URL: <https://trac.macports.org/ticket/49053> MacPorts <https://www.macports.org/> Ports system for OS X

1 4

[MacPorts] #49061: Fltk does not build under 10.11
by MacPorts 02 Oct '15

02 Oct '15

#49061: Fltk does not build under 10.11 ---------------------------+-------------------------------- Reporter: jguillaumes@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: fltk ---------------------------+-------------------------------- Compilation fails with this message: info:build /System/Library/Frameworks/CoreFoundation.framework/Headers/CFAvaila bility.h:110:45: note: expanded from macro '__CF_NAMED_ENUM' :info:build #define __CF_NAMED_ENUM(_type, _name) _type _name; enum :info:build ^ :info:build fl_line_style.cxx:115:15: error: elaborated type refers to a typedef :info:build static enum CGLineJoin Join[4] = { kCGLineJoinMiter, kCGLineJoinMiter, :info:build ^ :info:build /System/Library/Frameworks/CoreGraphics.framework/Headers/CGPath.h:25:26: note: declared here :info:build typedef CF_ENUM(int32_t, CGLineJoin) { :info:bu For reference, it has also been reported in homebrew: https://github.com/Homebrew/homebrew/issues/41581 -- Ticket URL: <https://trac.macports.org/ticket/49061> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 02 Oct '15

02 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Replying to [comment:53 michaelld@…]: > Well, this is the way the Qt folks do it in Qt5; I just back-ported it to Qt4. I don't care if it is more or less efficient. If it's good enough for Qt5 then it's good enough for Qt4 (IMHO). You may be right, but Qt5 has lots of other changes under the hood which may make this particular code path much less of a bottleneck that it *maybe* is in Qt4 -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:54> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #45291: defect: valgrind 3.10 does not built on Snow Leopard/Mac OS X 10.5.8 because libcoregrind_amd64_darwin_a-syswrap-darwin.o has no symbols
by MacPorts 02 Oct '15

02 Oct '15

#45291: defect: valgrind 3.10 does not built on Snow Leopard/Mac OS X 10.5.8 because libcoregrind_amd64_darwin_a-syswrap-darwin.o has no symbols ------------------------------+---------------------- Reporter: Peter_Dyballa@… | Owner: raimue@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: valgrind | ------------------------------+---------------------- Comment (by dstrubbe@…): Success on 10.6.8 for me. -- Ticket URL: <https://trac.macports.org/ticket/45291#comment:10> MacPorts <https://www.macports.org/> Ports system for OS X

1 0