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 for Bug 33419 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
While trying to debug dynamic libraries on iOS, it's suggested to enable an environment variable for some diagnostic output: DYLD_LIBRARY_PATH
Unfortunately, setting this in XS does not seem to output anything.
**Steps to Reproduce:**
1. Set the variable in XS for an iOS project via the Project Options -> General menu
2. The var is "DYLD_LIBRARY_PATH" and the value is 1.
3. Run the project on an iOS device in debug mode.
No output in the Application Output / Console or Device logs.
Some output like this:
**Build Date & Platform:**
DYLD_LIBRARY_PATH is not part of the document (link) you provided.
DYLD_LIBRARY_PATH is meant to accept path(s) not a number to help diagnosing issues.
Issue is seen with any of the variables defined in the documentation. Last one I tried was:
which did not yield any output.
Quoted from the document:
> While these environment variables are implemented on iOS, many of them
> have limited utility because of the restricted environment on that system.
What it means is that:
1. Nearly all applications' code comes from the main executable - directly or from static libraries (Apple requirement for iOS, unless you use "user frameworks") and won't be loaded by the dynamic linker. IOW their output is generally* not helpful;
2. Most of those debugging environment variables needs to be set before the application starts. This is not what XS does (even if it "starts" the app, it's not the process that does so) so the environment variables are set very early in the application startup (but too late for dyld to help). IOW the application (and it's libraries) can initialize itself from the variables, but they won't change iOS behaviours.
It's technically possible (at least for the simulator) to set such variables* earlier but neither XS (or the iOS Simulator itself) expose a way to do it.
* that's something we need to develop XI itself (because we do load the iOS frameworks dynamically) but there has not been any need (or use case) where this has proven useful for customer code.
Please let us know if your issue does not fall within the #1 restriction.
Note: specifically for `DYLD_PRINT_ENV` you can do the same using `System.Environment` just before calling `UIApplication.Main` (or anytime later).
Thanks for the info.
The reason I was looking for this support was to debug issues that were causing the app to fail to launch. Our Xamarin.iOS application is using custom Cocoa Touch Frameworks deployed as dynamic libraries and the dynamic linker was unable to resolve the embedded frameworks, usually with an error like this:
dyld: Library not loaded: <snip>
Reason: image not found
This unfortunately means that the application does not execute Main(), and debugging from within the app is not possible.
I was able to resolve the issue by setting the install path on the frameworks and providing mtouch linker arguments to set rpath, but it took some trial and error. When I had the same issue in Xcode, setting these environment variables made the debugging process much faster.
Not knowing the implementation details of Xamarin's debugger process I just assumed the same could be done as via Xcode :)
I do see the environment variables are set correctly via XS when the app runs, just no output. Thanks!
It makes sense, with user frameworks, to make those variables work then. We'll look into enabling their support in a future release.
Thanks for the details.