| Age | Commit message (Collapse) | Author |
|---|
|
mkbundle works by generating a small C source file which, in addition to
embedded assemblies/configs/etc, contains a certain amount of code to initialize
the bundle, uncompress the assemblies and set runtime options (e.g. AOT mode).
This source code is generated based on a number of templates shipped as
resources inside `mkbundle.exe` and is not part of any public, maintained API.
The generated code contains calls to Mono runtime which work just fine when
mkbundle is used to generate a desktop application bundle with the default
template code. However, it breaks when a third party (like Xamarin.Android)
embeds Mono runtime and loads it dynamically **after** the application is
initialized. Such third parties must ensure that the bundle's startup code is
able to access the Mono runtime functions it needs by providing pointers to
them, loaded using e.g. the `dlsym` function.
However, as the Mono calls are hard-coded into the generated source code, the
third party needs to resort to search-and-replace methods (e.g. Xamarin.Android
https://github.com/xamarin/xamarin-android/blob/62e7792ca52949f2fa213330d292865ad78d2bfa/src/Xamarin.Android.Build.Tasks/Tasks/MakeBundleNativeCodeExternal.cs#L159-L166)
which are very fragile and prone to undetected breakage.
One example of such breakage which slipped under the radar is
https://github.com/xamarin/xamarin-android/issues/1651 which was caused by
addition of the `mono_jit_set_aot_mode` call to the generated code. The change
slipped under the radar and was discovered only after release.
This commit attempts to make the situation better by establishing a sort of a
code contract between "upstream" mkbundle and the third party. Since the
template code is not "public" (nor should it be), the third party cannot simply
include a header file with the API definitions. Instead, the idea here is to
ensure that all and any Mono runtime calls needed by the template code are
placed in a dispatch structure as pointers to functions and that the structure
needs to be initialized by the embedding party before calling the
`mono_mkbundle_init()` function. The third party is responsible for maintenance
of its own version of the dispatch structure as well as for its initialization
via the `initialize_mono_api` function in the template code. The generated code
must include the third party's version of the structure, in place of the default
one as shipped with `mkbundle`, and to make it possible this commit adds the
`--mono-api-struct-path` mkbundle parameter which points to a file that's
injected into the generated code, replacing the default structure definition.
Following that, the `mono_mkbundle_init()` code calls the `validate_api_struct`
function which checks each and every pointer in the structure for `null`,
exiting the application with error if any `null` pointer is encountered.
This (along with the `initialize_mono_api` function in the template) has the
additional effect that if the third party's structure is incompatible with the
default one a build error will happen, thus allowing early detection of obvious
incompatibilities/omissions.
As long as all the new Mono runtime calls are added to the structure, the above
should make it possible for issues like the one linked to above to not happen in
the future.
|
|
target architecture. (#7281)
* Use VSCMD_ARG_TGT_ARCH env in mkbundle on Windows when trying to autodetect target architecture.
Using mkbundle on Windows with VS toolchain, mkbundle will detect target
architecture (x86/x64) by looking at the architecture of executing .NET runtime.
This could lead to some surprises when run from a VS development command propmt setup
to target x86 or x64 but running a mono binary using opposite architecture.
To mitigate this issue mkbundle will look now at the VSCMD_ARG_TGT_ARCH
set in VS development command prompts and use target architecture based
on this env variable. If not defined, current behavior will be used, picking the target
architecture based on executed .NET runtime architecture.
* Updated mkbundle documentation.
|
|
* [mkbundle] Automatically bundle config files and machine.config files for the simple/cross compiler scenario, fixes one of the missing issues for #6230
|
|
* [runtime] Fix mkbundle compilation on OSX
* [runtime] Add aot arguments to mkbundle
* [runtime] Enable compiling aot with mkbundle
* [runtime] Add new dedup interface to mkbundle
* [runtime] Fix path resolving for mkbundle
* [runtime] Use mkbundle in BCL tests
* [runtime] Skip building System.Security, System.IdentityModel tests on testing_aot_full
* [runtime] Fix in-tree building for mkbundle
* [runtime] Move testing dll into profile
* [runtime] Add target to mkbundle all tests before CI
* [runtime] Build stripper and use with mkbundle
Preliminary linker support ran into dependency-finding bug
with the monolinker.exe binary. Fix postponed until later.
* [runtime] Skip not supported tests with mkbundle
* [runtime] Don't re-aot when running BCL tests
* [runtime] Provide config to mkbundle
* [runtime] Fix mkbundle internationalization test results, build all
* [runtime] Clean up temp mkbundle aot directory
* [runtime] Add mkbundle support for dedup
* [runtime] Fix tracking of dedup module in mkbundle
* [runtime] Document mkbundle AOT options in man pages
* [runtime] Fix CADMessage generic method argument marshalling
|
|
I found that multiple libraries need to be specified in dependency order. That was not obvious from the man page. Make it explicit.
See https://bugzilla.xamarin.com/show_bug.cgi?id=59154
|
|
This reverts commit 9a287c04126d095e7371afee32632febd0dafd93, reversing
changes made to 4a79280b3bef8d5f15da9ddd2a2af3a03e194b03.
It breaks tons of tests.
|
|
|
|
We haven't been consistent in keeping those version numbers
up to date as we bump Mono's version so it's less confusing
to not show them in the manual pages.
`mono --version` is and has been the source of truth.
|
|
Make mkbundle use SDKs instead of a single runtime for cross compilation
|
|
* [mkbundle] add support for bundling native libraries
* [glib] add g_mkdtemp
* mono: Load the various library payloads for bundled executables
* [msvc] Export mono_dl_open and mono_loader_register_module
|
|
* [mkbundle] add support for baking environment variables, make endian-independent
* [runtime] Bundle support, implement missing stream processing
|
|
man page
|
|
|
|
* Start of packager for mkbundle
* [mkbundle] Add fingerprint and directory at end of package
* [mkbundle] Update embedding file format, add support for --options, support for --runtime, chmod +x
* [driver] Add a way to parse arbitrary command line options
* [mkbundle] Align the assemblies on a page boundary, do not release directory buffer
* Work-around odd compiler error by using memcpy
* Update makefile
* Fix the windows build
* [Windows] Export the new mono_parse_options_from API
* Implement the various cross-compiler target fetching commands
* Clean
|
|
|
|
* mkbundle.1: Document MONO_BUNDLED_OPTIONS.
svn path=/trunk/mono/; revision=133933
|
|
svn path=/trunk/mono/; revision=88978
|
|
svn path=/trunk/mono/; revision=76749
|
|
svn path=/trunk/mono/; revision=70490
|
|
svn path=/trunk/mono/; revision=68721
|
|
* mkbundle.1: The `-z' option is now supported under Windows.
svn path=/trunk/mono/; revision=65087
|
|
svn path=/trunk/mono/; revision=62356
|
|
* man/mkbundle.1: Documented environment variables and Windows issues.
svn path=/trunk/mono/; revision=55198
|
|
svn path=/trunk/mono/; revision=51486
|
|
* man/mkbundle.1: add --config-dir flag
svn path=/trunk/mono/; revision=43745
|
|
* man/mkbundle.1: add --static option
svn path=/trunk/mono/; revision=42790
|
|
svn path=/trunk/mono/; revision=42717
|
|
svn path=/trunk/mono/; revision=39203
|
|
svn path=/trunk/mono/; revision=36707
|
|
svn path=/trunk/mono/; revision=36692
|
