Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#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)

main.log (103.2 KB) - added by detlevd (Detlev Droege) 7 years ago.
Logfile of failed build with +qt4 on Sierra
qjackctl.log (194.1 KB) - added by kencu (Ken) 7 years ago.
qtjackctl +qt4 successful build log on SnowLeopard
Portfile.diff (826 bytes) - added by detlevd (Detlev Droege) 7 years ago.
Diff to fix problem with non-universal qt4-mac installations, now limited to variant qt4, using system -W …
qt4-mac.tar.bz2 (38.0 KB) - added by michaelld (Michael Dickens) 7 years ago.

Download all attachments as: .zip

Change History (25)

Changed 7 years ago by detlevd (Detlev Droege)

Attachment: main.log added

Logfile of failed build with +qt4 on Sierra

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!

Last edited 7 years ago by kencu (Ken) (previous) (diff)

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 in that one port. 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.

Last edited 7 years ago by kencu (Ken) (previous) (diff)

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.

Last edited 7 years ago by kencu (Ken) (previous) (diff)

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'

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!

Version 0, edited 7 years ago by kencu (Ken) (next)

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)

In e47a4481547c5a28200699acb5d5bb0fdc766b78/macports-ports:

qt4-mac: patches for various fixes.

1) rename current patch to both fix typo as well as for its actual purpose: to handle frameworks in Makefile creation;

2) add in patch to fix the "-arch ARCH -arch -Xarch" issue from ticket #54151 and others from years gone by.

3) add in patch for commit 0a2f2382 on July 10, 2015 at 7:22:32 AM EDT that was not included in 4.8.7 release, which offers better handling of invalid font tables.

rev-bump for all to be in effect.

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

Resolution: fixed
Status: newclosed

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 -> ...).

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

YW! Glad it's working for you.

Note: See TracTickets for help on using tickets.