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

64-bit Mono is not fully supported #14684

Closed
ticky opened this issue Jun 17, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@ticky
Copy link
Contributor

commented Jun 17, 2017

NOTE: This mandatory section is very likely not helpful in starting this discussion. As it’s requested, I’m filling it in, but you’ve been warned. 😜

To help us debug your issue please explain:

  • What you were trying to do (and why):
    Build a .NET application using Mono’s xbuild utility, then run it.
  • What happened (include command output)
    The build succeeded, but runtime warnings are emitted that WARNING: The Carbon driver has not been ported to 64bits, and very few parts of Windows.Forms will work properly, or at all, and the application crashed with an error in System.Windows.Forms
  • What you expected to happen
    The application should run successfully
  • Step-by-step reproduction instructions (by running brew install commands)

Explanation:

The Mono Project considers 64-bit support on macOS to be incomplete and they themselves do not ship a 64-bit version of the VM in their binary packages at all due to these limitations.

The 64 bit support has a few limitations today which is why we have not entirely switched to it:

  • Our Windows.Forms implementation uses Carbon, and as such, it would not work with a 64-bit Mono.
  • MonoDevelop uses Carbon for its menu integration so it would not run on a 64-bit VM.
  • MonoMac bindings have not been ported to 64 bits.

Windows.Forms in particular is pretty important, as it’s the GUI building block of most Win32 type applications!

For this reason, I think it would be best for Homebrew to instead ship a 32-bit build of Mono (either as the default or as an option), as its compatibility and usefulness would be significantly increased.

Related: #4332

@ticky

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2017

I’m currently testing building a 32-bit version of mono via Homebrew’s infrastructure. I’ll put up a PR if I succeed!

@ticky

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2017

Looks like Mono itself is fine with this, but of course the problem then becomes that other external dependencies (such as mono-libgdiplus need to be built for 32-bit, which means all their dependencies need to be built for 32-bit, which means… etc etc)

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2017

@ticky can we ship both?

@ticky

This comment has been minimized.

Copy link
Contributor Author

commented Jun 19, 2017

Hypothetically - Mono do discuss the possibility of a mono / mono64 naming convention

In the future we will ship both mono and mono64 binaries for our users.

However, it looks like they haven’t enacted such a thing yet as mono64 would still not be very useful.

@ticky

This comment has been minimized.

Copy link
Contributor Author

commented Jun 19, 2017

Just discovered brew uses, so here’s the list of things in homebrew-core which may require switching to 32-bit if Mono itself goes 32-bit.

@artob

This comment has been minimized.

Copy link

commented Jun 22, 2017

👍 I've been running into System.BadImageFormatException problems trying to use Npgsql with the Mono installed by Homebrew. Building a 32-bit Mono binary would indeed be preferable.

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Jun 30, 2017

@ticky experimenting with distributing 32-bit only sounds fine to me. Would you be willing to open a PR?

@ticky ticky referenced this issue Jul 4, 2017

Closed

mono: only build 32-bit binaries #15263

4 of 4 tasks complete
@ticky

This comment has been minimized.

Copy link
Contributor Author

commented Jul 4, 2017

@ilovezfs I threw this patch together when I was first discussing it, I should’ve published it then, haha. It’s up as #15263!

@ilovezfs

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2017

Closing this since we can now track it on #15263.

Thanks for the report @ticky!

@ilovezfs ilovezfs closed this Jul 13, 2017

@Homebrew Homebrew locked and limited conversation to collaborators May 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.