Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix CGDisplayCreateUUIDFromDisplayID linking (again) #2078

Merged
merged 1 commit into from
Jan 5, 2022

Conversation

madsmtm
Copy link
Member

@madsmtm madsmtm commented Nov 29, 2021

See previous issue: #1626.

The cocoa crate links to AppKit, which made the symbol CGDisplayCreateUUIDFromDisplayID from ApplicationServices/ColorSync (which AppKit uses internally) available to us (on macOS 10.8 to 10.13).

However, this does not work on macOS 10.7 (where AppKit does not link to ColorSync internally). Instead of relying on this, we should just link to ApplicationServices directly.

Also, lately something changed in rustc so that the linker's macOS version is 10.7, see rust-lang/rust#91372, which is why the nightly builds were failing.

  • Tested on all platforms changed
    • Tested on macOS Mojave 10.14.6, using MACOSX_DEPLOYMENT_TARGET=X.Y cargo build --example window.
    • Tested on macOS 10.10
    • And if @Imberflur could test this using their docker setup that would be nice as well!
  • Compilation warnings were addressed
  • cargo fmt has been run on this branch
  • cargo doc builds successfully
  • Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
  • Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
  • Created or updated an example program if it would help users understand this functionality
  • Updated feature matrix, if new features were added or implemented

@madsmtm
Copy link
Member Author

madsmtm commented Nov 29, 2021

Nope, I was wrong, this doesn't fix it

@madsmtm
Copy link
Member Author

madsmtm commented Dec 1, 2021

I've investigated this some more, and I'm pretty sure I've found the correct way of doing it (see the updated description)

@Imberflur and @ArturKovacs, sorry for pinging you before, but this is now ready to be tested.

Also pinging @ryanisaacg, don't know what macOS version you have but the more testers of this the merrier 😉

@madsmtm
Copy link
Member Author

madsmtm commented Dec 1, 2021

Just FYI, the nightly android builds will be fixed by rust-lang/rust#91381

@ArturKovacs
Copy link
Contributor

Unfortunately I won't have access to a macOS device until January. Feel free to ping me again at that time if this is still open then.

@madsmtm
Copy link
Member Author

madsmtm commented Dec 2, 2021

There is kind of a deadline on this, winit will break for macOS users in Rust 1.58, and I would really like to get this fix rolled out a while before that (and perhaps backported to some of the older, yet still quite widely used winit versions?)

est31 added a commit to est31/glium that referenced this pull request Dec 2, 2021
thomcc added a commit to thomcc/imagine that referenced this pull request Dec 5, 2021
Lokathor pushed a commit to Lokathor/imagine that referenced this pull request Dec 5, 2021
@ArturKovacs
Copy link
Contributor

Tagging a few people who are likely affected by this

@madsmtm madsmtm force-pushed the fix-colorsync-linking branch from 4a3f5b6 to 106d77c Compare December 6, 2021 21:10
@madsmtm
Copy link
Member Author

madsmtm commented Dec 6, 2021

To get this merged quicker, I took out the WINIT_LINK_COLORSYNC changes, will follow up with those in a separate PR.

#[cfg_attr(
not(use_colorsync_cgdisplaycreateuuidfromdisplayid),
link(name = "CoreGraphics", kind = "framework")
link(name = "ApplicationServices", kind = "framework")
Copy link
Member Author

@madsmtm madsmtm Dec 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that a bit further down in this file we're linking against CoreGraphics (this link attribute was redundant), so the only change is that we now also link to ApplicationServices.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested on MBP running macOS 12.0.1 and it works 👍

@Imberflur
Copy link
Contributor

@madsmtm I tested this with the docker setup and it links fine 👍 (although we aren't using that setup anymore currently)

@icefoxen
Copy link
Contributor

icefoxen commented Dec 9, 2021

Deferring to new ggez devs: @PSteinhaus , @nobbele and @IGBC .

@madsmtm madsmtm force-pushed the fix-colorsync-linking branch from 106d77c to 007bc57 Compare December 11, 2021 03:31
est31 added a commit to est31/glium-glyph that referenced this pull request Dec 12, 2021
parasyte added a commit to parasyte/cartunes that referenced this pull request Dec 13, 2021
parasyte added a commit to parasyte/cartunes that referenced this pull request Dec 13, 2021
parasyte added a commit to parasyte/cartunes that referenced this pull request Dec 13, 2021
@parasyte parasyte mentioned this pull request Dec 15, 2021
9 tasks
@hecrj
Copy link
Contributor

hecrj commented Dec 17, 2021

@ArturKovacs Thanks for the heads up!

Indeed, there are a bunch of projects I maintain that have failing CI with the beta toolchain. Ideally, a fix should be merged and released before the new stable release.

Is there any way I can help?

@madsmtm
Copy link
Member Author

madsmtm commented Dec 17, 2021

If we could get this tested by someone with a macOS version < 10.13 that would be nice, but this PR very probably works as-is (the previous behaviour utilized undocumented behaviour on older platforms, while linking to ApplicationServices matches what the docs say).

@madsmtm
Copy link
Member Author

madsmtm commented Dec 17, 2021

Relatedly, an update to the people following this issue:

The changes to rustc have been reverted, and the revert will (very likely) be backported to beta. So the rush for getting this rolled out before 1.58 is gone (though we should still fix the issue!)

@ArturKovacs
Copy link
Contributor

I have macOS 10.15 so it's not that easy for me to test on macOS < 10.13

However given that my machine is from mid 2012, I think I can reinstall it to the old OS version. That's a bit intrusive but I can do it if it's reeeealy needed.

@hkratz
Copy link

hkratz commented Jan 1, 2022

I have an old Macbook with 10.10 lying around. Not being familiar with winit what would be the best way to test it? Just cargo build / cargo test?

@madsmtm
Copy link
Member Author

madsmtm commented Jan 1, 2022

Just something where the linking is triggered. Try:

cargo clean
MACOSX_DEPLOYMENT_TARGET=10.7 cargo build --example window
cargo clean
cargo build --example window

@hkratz
Copy link

hkratz commented Jan 1, 2022

Looks good:

$ git remote -v
origin	[email protected]:madsmtm/winit.git (fetch)
origin	[email protected]:madsmtm/winit.git (push)
$ git status
On branch fix-colorsync-linking
Your branch is up to date with 'origin/fix-colorsync-linking'.

nothing to commit, working tree clean
$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.10.5
BuildVersion:	14F2511
$ rustc --version
rustc 1.57.0 (f1edd0429 2021-11-29)
$ cargo clean
$ cargo build --example window --quiet
$ MACOSX_DEPLOYMENT_TARGET=10.7 cargo build --example window --quiet
$ cargo clean
$ cargo build --example window --quiet
$ 

@madsmtm
Copy link
Member Author

madsmtm commented Jan 1, 2022

Wonderful, thanks a lot @hkratz!

Just out of interest, could I get you to do:

cargo clean
MACOSX_DEPLOYMENT_TARGET=10.7 cargo run --example window

And just verify that a window actually opens? I think it's rare that winit is actually used on older machines, so it would be nice to hear that working

@madsmtm madsmtm force-pushed the fix-colorsync-linking branch from 007bc57 to c780fc6 Compare January 2, 2022 21:54
@ArturKovacs ArturKovacs mentioned this pull request Jan 3, 2022
3 tasks
@madsmtm madsmtm force-pushed the fix-colorsync-linking branch from c780fc6 to 18d8079 Compare January 3, 2022 20:32
@hkratz
Copy link

hkratz commented Jan 3, 2022

cargo clean
MACOSX_DEPLOYMENT_TARGET=10.7 cargo run --example window

@madsmtm It shows a small window and produces lots of logging output after adding a workaround for borntyping/rust-simple_logger#43

@madsmtm
Copy link
Member Author

madsmtm commented Jan 3, 2022

Wonderful, thanks!

See also rust-windowing#1626.

The `cocoa` crate links to AppKit, which made the symbol `CGDisplayCreateUUIDFromDisplayID` from ApplicationServices/ColorSync (which AppKit uses internally) available to us on macOS 10.8 to 10.13.

However, this does not work on macOS 10.7 (where AppKit does not link to ColorSync internally). Instead of relying on this, we should just link to ApplicationServices directly.
@madsmtm madsmtm force-pushed the fix-colorsync-linking branch from 18d8079 to 83d55c5 Compare January 5, 2022 13:08
@madsmtm
Copy link
Member Author

madsmtm commented Jan 5, 2022

Well, I think this has had enough eyes on it

@madsmtm madsmtm merged commit 39dd30c into rust-windowing:master Jan 5, 2022
@madsmtm madsmtm deleted the fix-colorsync-linking branch January 5, 2022 13:38
madsmtm added a commit to madsmtm/winit that referenced this pull request Jan 5, 2022
Since rust-windowing#2078 we link to `ApplicationServices`, which contains the `CGDisplayCreateUUIDFromDisplayID` symbol in all versions.
@madsmtm madsmtm mentioned this pull request Jan 5, 2022
6 tasks
madsmtm added a commit to madsmtm/winit that referenced this pull request Jan 23, 2022
Since rust-windowing#2078 we link to `ApplicationServices`, which contains the `CGDisplayCreateUUIDFromDisplayID` symbol in all versions.
madsmtm added a commit that referenced this pull request Jan 23, 2022
Since #2078 we link to `ApplicationServices`, which contains the `CGDisplayCreateUUIDFromDisplayID` symbol in all versions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

8 participants