Unresolved QuickTime dependency on Mac OS X?

[jodonoghue]

Issue reported by Conal Elliott ([email protected] - see http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1192)

I installed wxWidgets-devel-2.9.3 via macports and then wxHaskell, and I get the following when trying to run a simple wxHaskell program in ghci:

Loading package wxc-0.90.0.2 ... can't load framework: QuickTime (dlopen(/System/Library/Frameworks/QuickTime.framework/QuickTime, 9): no suitable image found.  Did find:
    /System/Library/Frameworks/QuickTime.framework/QuickTime: no matching architecture in universal wrapper
    /System/Library/Frameworks/QuickTime.framework/QuickTime: no matching architecture in universal wrapper)

Any suggestions? I'm using Mac OS 10.6.8 and GHC-7.0.4 from the Haskell Platform.

[HeinrichApfelmus]

The problem seems to be that QuickTime 7 is a 32bit library and will stay that way. Instead of porting it to 64bit, Apple chose to completely rewrite it instead, creating the QuickTime X library. You can still use the QuickTime 7 library, but only from 32bit processes.

Solution:

1. Install wxWidgets-devel-2.9.3 with the +universal flag on macports. This creates a library that is both 32bit and 64bit.
2. Configure GHC to produce and link 32bit binaries.

I don't know what exactly happens on the wxWidgets side, though. Do they link QuickTime when creating a 64bit target?

Alternatively, we would need to update the wxc package to become QuickTime-agnostic, whatever that means.

[HenryLockyer]

Re "what exactly happens on the wxWidgets side . . . Do they link QuickTime when creating a 64bit target?" (above):

. . .
g++ -mmacosx-version-min=10.5 -o wxrc wxrc_wxrc.o    -L/Users/henrylockyer/wxWidgets/wxWidgets-2.9.3/build-cocoa-static-unibin3264-wxhaskell/lib  -arch ppc -arch i386 -arch x86_64  -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL -framework QuickTime   -lwx_baseu_xml-2.9 -lexpat -lwx_baseu-2.9     -lwxregexu-2.9  -arch ppc -arch i386 -arch x86_64  -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL -framework QuickTime  -lz -lpthread -liconv  -lz -lpthread -liconv
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file
. . .

The above is from building a universal binary version of widgets 2.9.3 on OS 10.6.8 Snow Leopard. The warning is seemingly received only for 'wxrc' out of all the widgets bits and pieces (not sure what it is exactly) and it does not appear to be complaining about the other architectures. The same occurs if only a 64bit build is selected, as one might expect. Compiling any of the widgets demos and samples for / including 64bit gets the same warning. Will experiment a little further.

[HenryLockyer]

See http://trac.wxwidgets.org/ticket/14144 and http://trac.wxwidgets.org/changeset/71086

I haven't managed to get the patch from 14144 to work, it still includes the QuickTime framework when making an x86_64-only build. The patch updates the 'config.in' file OK but the change doesn't seem to have the desired effect.
The changeset solution seems a little more complex but I don't understand it or what to do with it.

It may not solve the wxc problem anyway. Not sure if Conal Elliots GHC 7.0.4 was 16 bit or 32 bit. Presumably 64.. Why is wxc looking for quicktime ? The above widgets ticket suggests it does not need the QuickTime framework in the 64bit version so why/where is GHCi hitting this problem?

[HeinrichApfelmus]

Judging from the wxWidgets issue, the QuickTime library is only needed on a 32bit build, but accidentally linked in the 64bit case as well.

It looks like C++ code using wxWidgets can cope with that: the linker will generate a warning, but since the framework is not used anywhere, this doesn't lead to faulty behavior. What exactly happens in the case of wxc? If Conal sees a build warning, then he can ignore it; but it it's a build error, then he obviously can't.

It looks like wx-config will return the -framework QuickTime flag even on 64bit and wxc will link it in, but then has problems because that doesn't work. The solution to issue http://trac.wxwidgets.org/ticket/14144 is to remove the erroneous -framework QuickTime in the 64bit case.

If we want to fix this downstream, then we have to detect and remove the -framework QuickTime flag in the 64bit case by hand from the setup https://github.com/jodonoghue/wxHaskell/blob/master/wxc/Setup.hs#L81 .

[HenryLockyer]

Evidently their configurator design can't/doesn't generate separately for the different architectures and then combine, so uses a common set of flags for multiple arch's. Hence their patch will only exclude the quicktime framework if it is only 64bit, not in the case of multiple including 64 bit eg.as in universal binary which will still get the warning. I think with the patch it only works if the mac architecture param is explicitly set to x86_64 in the configure command.

Just my general+frameworks ignorance but I was surprised one would find any problem when linkng the 64bit widgets library functionality later after the library had been built, since it evidently doesn't use it anyway. How/why does it remember such things for future users..? I would have thought the library would just be sitting there quietly ready to be used! but anyway..

I may have misinterpreted the severity in Donal's case. I'm going to try it myself soonish.

(As well as trying to apply the patch from ticket 14144 I also tried running the configure command for a 64-bit only lib and then manually removing QuickTime from the lists of frameworks in the makefile, but again sadly it did not work and there is evidently more to it...)

[HenryLockyer]

To get rid of the QuickTime warning for 64bit versions:

After playing around a little I got rid of the QuickTime framework warning from the wxWidgets build for an i86_64 (only) build by building wxWidgets myself after having edited the top level "configure.in" and "configure" files of version 2.9.3 to remove QuickTime from the frameworks list (2 places). It is probably sufficient to just edit the script since it does not seem to rebuild the configure script from the "configure.in" file during the normal configure/make process.

Also I guess if you download the latest wxWidgets in-progress S/W version you will get changeset 71086 by now, and hopefully it will work as intended.

I haven't been able to test for the original problem above yet since I don't have wxHaskell working yet..

[neapel]

I'm still getting the same issue with wxmac 3.0.2.0 (via homebrew) and wx 0.91.0.0…
Building wxmac with --disable-mediactrl removes the QuickTime dependency from the output of wx-config.

[ekmett]

Would it be possible to manually filter the QuickTime dependency out of what we get back for now, when running on OSX in 64-bit?

I'd love to be able to ship software on top of this, but right now this issue basically renders this entire library unusable to me, because I basically lose all of my users if they can't install the package, and knowing that it might be fixed in 6 months by the wxmac folks doesn't do me a lot of good.

I'd really rather see a bandaid in place that works and then rip it off when the right solution presents itself downstream.

[ekmett]

I managed to get a patch into homebrew to make it so that brew will install --without-mediactrl on 64-bit platforms.

That should make it so going forward, users won't suffer from this problem.

Homebrew/legacy-homebrew@f41ec80

[HenryLockyer]

Sounds like Progress.
Sorry I have not been able to contribute usefully to the topic.
I noticed the recent emails from yourself, neapel, Jeremy etc. but have been away from wxhaskell and software in general for some time now.
I appreciate you keeping me in the loop however; and things may swing back again..
Regards/ Henry

On 2 Dec 2014, at 09:32, Edward Kmett wrote:

I managed to get a patch into homebrew to make it so that brew will install --without-mediactrl on 64-bit platforms.

That should make it so going forward, users won't suffer from this problem.

Homebrew/legacy-homebrew@f41ec80

—
Reply to this email directly or view it on GitHub.