qt4-x11 doesn't support 10.6 yet

[snc@…]

qt4-x11 bails during build, citing an unsupported version of 10.6. Might be an upstream issue? Setting to low priority as 10.6 is not out yet.

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_qt4-x11/work/qt-x11-opensource-src-4.4.3/include/QtCore/../../src/corelib/global/qglobal.h:290:6: error: #error "This version of Mac OS X is unsupported"

[macsforever2000@…]

Snow Leopard is out now.

[ruud@…]

Cc Me!

[jungwook.shin@…]

Cc Me!

[macports@…]

Cc Me!

[asymptotic.freedom@…]

Cc Me!

[macsforever2000@…]

Cc Me!

[Markus.Ueberall@…]

Cc Me!

[macports@…]

Cc Me!

[ryandesign@…]

Perhaps it just needs to be updated.

[ih-mon@…]

Cc Me!

[ryandesign@…]

Has duplicate #23833.

[johannes.simon@…]

Cc Me!

[ryandesign@…]

Has duplicate #25536.

[michaelld@…]

Cc Me!

[michaelld@…]

As per ticket #20986, and as of r69277, qt4-x11 uses 'select'. Next, working towards updating to 4.6.3 and 4.7.0b1, and including both debug and release versions. I believe updating to the 4.6 series will resolve this ticket. That said, doing this upgrade won't be trivial, so be patient.

[julien-mac@…]

As a sidenote, a way to mark the port as BROKEN would be good in order to avoid any process of the port or its dependencies.

[snc@…]

We don't have a means of testing every combination of hardware/software to discover what works.

[michaelld@…]

As of r72571, qt4-mac has a stub variant for +x11. I'll be filling in the details shortly. Question to everyone on this ticket: Are there ports that you know that are qt4-x11 specific, in such a way that qt4-mac and qt4-x11 should remain separate? What I'd like to do (and, am doing right now since I haven't heard better otherwise) is to incorporate +x11 into qt4-mac and then allow the user to switch back and forth between them. Most user need just qt4-mac, but I also don't want to estrange those who need both qt4-mac and qt4-x11. So, I'm listening ...

[johannes.simon@…]

My intention was to use qt4-mac and qt4-x11 side-by-side. After all, qt4-mac is what I'll always need, but for some bigger Qt projects it is helpful for me (as a developer) to be able to test the X11 version as well, as the UI is always slightly different. It's not possible to test X11 styles with qt4-mac. This is - to be honest - not a super high priority. But it is one of these nice-to-have things.

[_b_b_@…]

Cc Me!

[_b_b_@…]

is anyone still working on this? I really need qt4-x11 for my project as it relies on pythonOCC (pythonocc.org) which uses the X11 interface of qt4 (not aqua). Plus, i think for most developers it would be useful to have a x11 version alongside for debugging purposes, as johannes mentioned already.

[michaelld@…]

Nominally I'm working on it. Reality is that Qt47 just isn't designed to compile for X11 on Darwin / OSX, and so I haven't figured out that "correct combination" of tweaks to QMake build files yet. I've also been working on other ports and not very much on this one -- it would help if Qt47 didn't take -hours- to compile, just to test out a single tweak. And, yes, that's even with doing "port -o" and using ccache (both of which help). It'll happen sooner or later. Please feel free to submit patches that do what you need / want for qt4-x11 or qt4-mac +x11; doing so would certainly speed up the process!

[_b_b_@…]

Thanks for the fast reply! Well, I'd like to help, really, but I think I'm not familiar enough with all this -just recently started using MacPorts- and don't quite know where to begin with...

[michaelld@…]

Check out the patchfile "patch-darwin-g++.diff"; it's my current effort towards tweaking the QMake build files to work with Darwin / X11 / g++. I think what you're looking for are places where Frameworks are necessary versus where they are not. You'll need to get used to the QMake script language, but it's not that difficult. Best way I've found for testing is to copy the original file (from FOO to FOO.orig), then edit that file -- generally to add in or change macx and x11 clauses. Then re-do configure & build. When it fails, figure out why, correct the mistake, and repeat. If you're lucky & have a big fast Mac, you can get a single iteration into ~20-30 minutes; on my MacBook Pro 2.6 GHz it typically takes 30-60 minutes depending on the change.

[_b_b_@…]

hey! sorry for the delay. thanks for your hints where to start looking at! i played around a bit with what you mentioned. no success so far, but ok. i'll keep trying and will report back here. although i have to add that i'm quite busy right now - and no, i don't have a big fast mac, so it's taking it's time :) - so i don't know when we can get it to work. right now as a workaround i just installed linux on another partition so i can debug my stuff, but that's kinda stupid. i'd really like to get this done under mac os. well, let's see.

[arve@…]

Is it possible to set the portfile to bail out early with an error if on Mac OS 10.6 or later? I waited for installations of both (!) mysql and postgresql before finding that my OS cannot use this module...

[snc@…]

What's wrong with having those built until qt4-x11 is ready? It'll be less to build in the future.

The best "early fail" we can do is just to prevent operations within qt4-x11 from commencing:

pre-extract {
    if {${os.major} > 9} {
        ui_err "{$name} does not yet work with your OS version."
        return -code error "OS version not supported"
    }
}

If Snow Leopard can't handle qt4-x11, can Lion?

[vincent.acary@…]

Hi, I have still the same problem to build qt4-x11 on snow leopard. I also realy need it for pythonocc and i am wondering if there is a way to circumvent the problem