Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Due to this: https://github.com/mono/mono/commit/cfd9870f8345d2e3e6354e3deebced443809ee2f Mono does no longer create any libmono-profiler-log.dylib when we're building a bitcode-capable runtime.
The problem is that this means we don't have the dylib even when we're not using the bitcode part of the runtime.
This means that we can't support incremental builds + profiling when using any bitcode-capable Mono runtime, even though we don't need the bitcode bits (because the user is building/profiling locally on his own devices).
So would it be possible to make the mono runtime build libmono-profiler-log.dylib without bitcode support? I believe this is done by building with -fembed-bitcode-marker.
It would nice to fix that. But that won't get the profiler working on watchOS as it doesn't support coop.
The big problem here was that libmono-profiler-log.dylib failed to build in the bitcode case because undefined references are not allowed there. That's why we now only build the static library in that case. I don't think -fembed-bitcode-marker would solve this problem.
This affects tvOS as well, not just watchOS.
Maybe it would be possible to embed the profiler inside libmonosngen-2.0.dylib (if enabled at configure time)? That should solve the undefined references.
Embedding the profiler inside libmonosgen-2.0.dylib only makes sense for debug builds, but unfortunately we use the dylib for release builds as well (when renamed to Mono.framework/Mono).
The linked commit has been reverted, so there should no longer be an issue. Marking this bug as resolved.