#54151 closed defect (fixed)
qjackctl @0.45+qt4: variant +qt4 fails to build on Sierra
Reported by: | detlevd (Detlev Droege) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.4.1 |
Keywords: | Cc: | kencu (Ken), michaelld (Michael Dickens) | |
Port: | qjackctl |
Description
The qt4 variant fails to build on my Sierra (10.12.4, XCode 8.3.2) system. Building fails due to a weird architecture option, the main.log says:
:info:build clang: error: invalid arch name '-arch -Xarch_x86_64'
(full main.log attached) I can't discover where that excess -arch
sneaks in. It is in the linker call of clang++. The compile calls have ... -arch x86_64 -Xarch_x86_64 -mmacosx-version-min=10.12 ...
which works fine, but the final linker call has ... -arch x86_64 -arch -Xarch_x86_64 -mmacosx-version-min=10.12 ....
Strange.
Attachments (4)
Change History (25)
Changed 7 years ago by detlevd (Detlev Droege)
comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
I would guess someone has implemented deduplication of arguments without understanding the consequences...
comment:2 Changed 7 years ago by mf2k (Frank Schima)
Cc: | kencu added |
---|
Cc'ing latest patch author. I believe the qt4 variant was for older systems.
comment:3 Changed 7 years ago by kencu (Ken)
hmmm, that is a weird error! I didn't try to touch anything in the build script. This is how it built for me with qt4 on 10.6:
$ port -v installed qjackctl The following ports are currently installed: qjackctl @0.4.5_0+dbus+portaudio+qt4 (active) platform='darwin 10' archs='x86_64' date='2017-05-04T15:57:13-0700'
I'll attach the successful log I just re-built, and perhaps we can see what the difference is. I'll try to qt4 variant on Sierra later on.
Sorry detlevd, I had certainly not wanted to mess up your excellent submission -- just hoped to keep the older machines on the train if possible!
Changed 7 years ago by kencu (Ken)
Attachment: | qjackctl.log added |
---|
qtjackctl +qt4 successful build log on SnowLeopard
comment:4 Changed 7 years ago by kencu (Ken)
Hah. This is a strange one. Turns out the issue is not with the -Xarch_x86_64
flag, which is perfectly fine for clang, but with the dangling -arch
flag before that without a valid architecture to follow it.
This can happen when qt4-mac is not installed +universal
.
Indeed, installing qt4-mac +universal
on Sierra, then qtjackctl +qt4
works fine:
$ port -v installed qjackctl The following ports are currently installed: qjackctl @0.4.5_0+dbus+portaudio+qt4 (active) platform='darwin 16' archs='x86_64' date='2017-05-11T11:10:35-0700'
and here is the link line:
/usr/bin/clang++ -headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o qjackctl.app/Contents/MacOS/qjackctl .obj/qjackctl.o .obj/qjackctlAlsaConnect.o .obj/qjackctlConnect.o .obj/qjackctlConnectAlias.o .obj/qjackctlInterfaceComboBox.o .obj/qjackctlJackConnect.o .obj/qjackctlPatchbay.o .obj/qjackctlPatchbayFile.o .obj/qjackctlPatchbayRack.o .obj/qjackctlSession.o .obj/qjackctlSetup.o .obj/qjackctlSystemTray.o .obj/qjackctlAboutForm.o .obj/qjackctlConnectionsForm.o .obj/qjackctlMainForm.o .obj/qjackctlMessagesStatusForm.o .obj/qjackctlPatchbayForm.o .obj/qjackctlSessionForm.o .obj/qjackctlSetupForm.o .obj/qjackctlSocketForm.o .obj/moc_qjackctlConnect.o .obj/moc_qjackctlPatchbay.o .obj/moc_qjackctlPatchbayRack.o .obj/moc_qjackctlSystemTray.o .obj/moc_qjackctlAboutForm.o .obj/moc_qjackctlConnectionsForm.o .obj/moc_qjackctlMainForm.o .obj/moc_qjackctlMessagesStatusForm.o .obj/moc_qjackctlPatchbayForm.o .obj/moc_qjackctlSessionForm.o .obj/moc_qjackctlSetupForm.o .obj/moc_qjackctlSocketForm.o .obj/qrc_qjackctl.o -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -L/opt/local/libexec/qt4/lib -L/opt/local/lib -ljack -lpthread -framework CoreAudio -framework CoreServices -framework AudioUnit -framework CoreFoundation -lX11 -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -framework QtXml -F/opt/local/Library/Frameworks -framework QtCore -framework QtGui
michaelld@…, who has been doing this much much longer than me, found this error in 2010, and fixed it like so: <https://trac.macports.org/changeset/73290> in a different port. We could do that...
So - yeah - commotion deep in the guts of qt4. Options are to use something like that tricky tricky bit of sed
'ing Michael used, or to just tell people to install qt4-mac as +universal and be done with it for all ports that might have this issue.
Doesn't look like michaelld actually figured out why it happened sometimes. Just fixed it up after. Must be some reason it occurs in certain ports, of course.
I installed qt4-mac +universal last year, and so would never see this error, I guess. Seems pretty tempting to just force qt4-mac to be +univeral by default... not the purist thing, to be sure, but heck, qt4-using ports are not going to generate a ton of interest any more.
comment:5 Changed 7 years ago by kencu (Ken)
we could put something like the following in the qt4 block
PortGroup active_variants 1.1 require_active_variants qt4-mac universal
If I'm correct, that would ensure qt4-mac is installed in a compatible format for this port. Although it takes time to build it, we'd be doing everyone a favour in the end, I think, by fixing this qt4 error in whatever other ports might have it.
comment:6 Changed 7 years ago by michaelld (Michael Dickens)
See also the discussion at https://github.com/macports/macports-ports/pull/472 .
Forcing +universal isn't the right solution.
comment:7 Changed 7 years ago by michaelld (Michael Dickens)
Cc: | michaelld added |
---|
comment:8 Changed 7 years ago by detlevd (Detlev Droege)
OK, it is a problem in the guts of qmake and qt4-mac, but https://trac.macports.org/changeset/73290 gives a good hint how to work around it. I stripped that solution down to what is needed for the qjackctl port. It works this way on my Sierra system and im confident it won't hurt others. But please check on different configurations. I'll attach the Portfile diff, it simply adds
post-configure { # work around strange qmake problem if not universal, see https://trac.macports.org/ticket/54151#comment:6 if {![variant_isset universal]} { system "cd ${worksrcpath} && PATH=${qt_bins_dir}:$env(PATH) qmake -o qjackctl.mak qjackctl.pro" system "cd ${worksrcpath}/src && PATH=${qt_bins_dir}:$env(PATH) qmake -o qjackctl.mak src.pro" reinplace "s@-arch *-Xarch_x86_64@-Xarch_x86_64@" ${worksrcpath}/src/qjackctl.mak } }
comment:9 Changed 7 years ago by detlevd (Detlev Droege)
I updated the diff to include a test for variant qt4, so it won't try that on qt5:
if {[variant_isset qt4] && ![variant_isset universal]} { ...
comment:10 Changed 7 years ago by mf2k (Frank Schima)
Please update your patch to use system -W $path
instead of system "cd $path"
.
Changed 7 years ago by detlevd (Detlev Droege)
Attachment: | Portfile.diff added |
---|
Diff to fix problem with non-universal qt4-mac installations, now limited to variant qt4, using system -W ...
comment:11 Changed 7 years ago by kencu (Ken)
Will try it. I think Michael is trying to sort out how exactly that dangling -arch gets there in the first place and understand how to fix it at the origin.
comment:12 Changed 7 years ago by michaelld (Michael Dickens)
If this fix works, then let's get it in place. I'll test shortly.
comment:13 Changed 7 years ago by michaelld (Michael Dickens)
Yes, this fix does seem to work. I wish we didn't need to call qmake though. So I started looking into the issue inside qmake & have found the code & logic. I'm trying to figure out a reasonable patch. I'll check the Qt5 code to see what it does.
Changed 7 years ago by michaelld (Michael Dickens)
Attachment: | qt4-mac.tar.bz2 added |
---|
comment:14 Changed 7 years ago by michaelld (Michael Dickens)
After some ado, I've come up with a patch to qt4-mac that works for me on 10.12 latest. It's generic C++, hopefully.
The fix is a little complicated, but it generally checks the QMake LFLAGS as they are being processed to make sure when "-arch ARCH" is provided (normally 2 independent arguments), they are processed together including checking for duplicates (of both). Currently, they are processed separately, and when a string starting with "-" is found it is processed & generally appended to the internal list, while those not starting with "-" are looked for duplicates of & only appended if no duplicate found. That's why the duplicate "-arch ARCH -arch ARCH" would result in the last ARCH being dropped.
I've attached the whole qt4-mac directory with updates to this ticket since it's just easier that way. For those of you who know how to do so, please give it a try & see if it works for qjackctl as it currently stands (without patching the Portfile per the above patch files).
comment:15 Changed 7 years ago by kencu (Ken)
Building now... (non-universal) on 10.6 and 10.12. Admire your dedication to purity.
comment:16 Changed 7 years ago by kencu (Ken)
works correctly on 10.6...
$ port -v installed qt4-mac The following ports are currently installed: qt4-mac @4.8.7_4+universal platform='darwin 10' archs='i386 x86_64' date='2016-12-28T06:44:25-0800' qt4-mac @4.8.7_5-universal (active) platform='darwin 10' archs='x86_64' date='2017-05-13T21:20:47-0700' $ port -v installed qjackctl The following ports are currently installed: qjackctl @0.4.5_0+dbus+portaudio+qt4 (active) platform='darwin 10' archs='x86_64' date='2017-05-13T21:25:39-0700'
and 10.12!
$ port -v installed qt4-mac The following ports are currently installed: qt4-mac @4.8.7_4+universal platform='darwin 16' archs='i386 x86_64' date='2017-05-11T11:08:14-0700' qt4-mac @4.8.7_5 (active) platform='darwin 16' archs='x86_64' date='2017-05-13T19:03:15-0700' $ port -v installed qjackctl The following ports are currently installed: qjackctl @0.4.5_0+dbus+portaudio+qt4 (active) platform='darwin 16' archs='x86_64' date='2017-05-13T21:28:26-0700'
You da man!
comment:17 Changed 7 years ago by michaelld (Michael Dickens)
"dedication to purity" -> yes, when the code is easy to fix. Given that other projects have had this issue in the past, it makes sense to just fix it this time so that it's not an issue in the future. I do what I can ;)
comment:18 Changed 7 years ago by michaelld (Michael Dickens)
comment:19 Changed 7 years ago by michaelld (Michael Dickens)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Let the good times roll!
Thanks for the feedback, Ken.
comment:20 Changed 7 years ago by detlevd (Detlev Droege)
Thanks a lot, Michael!
Works smoothly now on my Sierra system with qt4-mac. That is by far a better solution than my ad hoc post-configure fix. I also tried to find the 'real' source of the problem but gave up in the third or fourth layer of configuration stuff (Portfile -> ./configure -> qmake -> config-vars from qt4-mac -> ...).
Logfile of failed build with +qt4 on Sierra