wxmac: add --without-mediactrl option to disable dependency on QuickTime #33366
Conversation
|
Isn't this something that could/should by fixed in wxHaskell? |
|
It could be fixed in wxHaskell, by filtering the output of |
|
It seems less usable to me to have users somehow know that this is the magic option they should enable if they want to use wxHaskell. I'd be more open to disabling it globally or at least with 64-bit builds enabled. That said though, it does seem like something that should be fixed upstream in either wxHaskell or wxMac rather than us applying a band-aid. |
|
Ironically, I'm having the exact same problem building Code::Blocks (which doesn't seem to have anyone maintaining their Mac build, so I thought I'd give it a shot). I'm sure I'll have other problems, but this one is stopping me in my tracks at the moment. Good timing! |
|
@MikeMcQuaid, I agree, the issue does hold for anyone building in 64-bit on a mac. The existing 32-bit QuickTime framework will never be upgraded to 64 bit, so in theory it should just be that when you go to build on a 64-bit Mac, you just kill it automatically. That would remove the need for fancy options and avoid just making the thing unusable for 64-bit users. |
|
For now it basically just stops everyone who wants to use the package on a Mac in 64-bit mode dead though. |
|
@ekmett Please submit an issue to the upstream developers and create a new PR to just disable it globally, thanks! |
|
The issue was already been submitted upstream 4 months ago, so in another 8 months or so it will probably become usable. ;) So if I parsed you correctly, you'd rather have this patch here not be an option, but rather just check for x64 and do the only sensible thing? I'd rather prefer that as well, because then you don't get users going through a monolithic install process only to discover afterwards that they wasted their time. |
Yup. |
) Users of tools that fail when trying to link non-existent frameworks run into problems on 64-bit macs, because the old 32-bit QuickTime framework does not and never will exist as a 64 bit library. This has been submitted upstream and accepted into wxmac HEAD, however a released version is not yet available and won't be for quite some time. This patch lets us actually get code to compile without waiting 8 months for a release.
) Users of tools that fail when trying to link non-existent frameworks run into problems on 64-bit macs, because the old 32-bit QuickTime framework does not and never will exist as a 64 bit library. This has been submitted upstream and accepted into wxmac HEAD, however a released version is not yet available and won't be for quite some time. This patch lets us actually get code to compile without waiting 8 months for a release.
|
I've submitted an alternate patch that acts as requested. |
) Users of tools that fail when trying to link non-existent frameworks run into problems on 64-bit macs, because the old 32-bit QuickTime framework does not and never will exist as a 64 bit library. This has been submitted upstream and accepted into wxmac HEAD, however a released version is not yet available and won't be for quite some time. This patch lets us actually get code to compile without waiting 8 months for a release.
Users of tools that fail when trying to link non-existent frameworks run into problems on 64-bit macs, because the old 32-bit QuickTime framework does not and never will exist as a 64 bit library. This has been submitted upstream and accepted into wxmac HEAD, however a released version is not yet available and won't be for quite some time. This patch lets us actually get code to compile without waiting 8 months for a release. Closes Homebrew#34543. Closes Homebrew#33366. Signed-off-by: Mike McQuaid <[email protected]>
QuickTime being 32bit only creates some issues, for example wxHaskell uses
wx-config --libsoutput which includes-framework QuickTimewhen building with mediactrl enabled, and then fails to run on 64bit because the library can't be loaded: jodonoghue/wxHaskell#2