[Mono-dev] Next steps for mkbundle

Miguel de Icaza miguel at microsoft.com
Sat Aug 20 16:24:18 UTC 2016


Hello James,

Thanks for the feedback.   I had not thought about that.

It is certainly possible to support it.  For AOT it would be up to you to produce the artifacts.

You could then AOT with LLVM and use regular runtime for the regular runtime.





On Sat, Aug 20, 2016 at 11:01 AM -0400, "James Babcock" <jimrandomh at gmail.com<mailto:jimrandomh at gmail.com>> wrote:


I've got a (so far unpublished, but quite far along) project aiming to replace the traditional Unix command line (terminal, shell, tmux and miscellaneous utilities). It's predominantly C#, with a little bit of C++. One of its wishlist features is a busybox-style dependency-free binary, and a while back I made myself a hacked up mkbundle that got most of the way there, except that it still had a libc dependency and couldn't embed AOT.

So it's exciting to hear that mkbundle is getting some love! A general facility for embedding shared libraries in the bundle would be amazing for this case. Especially if it could handle both CLR DLLs and Linux shared libraries, and especially if it included the shared libraries generated by AOT compilation. If only a subset of these things work it's still useful.

On Aug 19, 2016 7:13 PM, "Miguel de Icaza via Mono-devel-list" <mono-devel-list at lists.dot.net<mailto:mono-devel-list at lists.dot.net>> wrote:
Hello team,

I am very happy with the new hack to simplify creating bundles of applications, because we no longer need a C compiler to make these happen, and as a bonus, we now allow cross-compilation of bundles.

Just a couple of days ago, I added support for a new "--18n" flag that controls which encoders are shipped with the application, similar to the same setting that we surface on Xamarin.{Android,iOS,tvOS,macOS}.

The cross-compilation feature has surfaced a problem, when we bundle, we bundle using the assemblies from the system, but a VM that you can specify, and this can lead to mismatches between the C and C# code in the runtime (ie, Mono 4.0 and mscorlib 4.2).

So it seems to me that instead of just shipping Mono runtimes in our server for cross compilation, we are going to have to ship the entire set of assemblies that are part of a distribution. Perhaps all of $prefix/lib/mono/gac as well as the C runtime, and the support libraries for Mono.Posix.

Now, that is the easy part.

The part that I am debating is the part where we would like to distribute shared libraries that go with the bundled binary.   Either we can require that shared libraries be distributed side-by-side, to be a user/distribution problem, or to allow a way in mkbundle to ship those on behalf of the user/distributor.

Something like:

                mcs foo.cs  -pkg:gtk-sharp-2.0
                mkbundle -cross arm64-debian-linux-4.2.0 -shared-libs=/tmp/my-gtk-2.0-for-debain-shared-libs

Thoughts?
Miguel.

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.dot.net<mailto:Mono-devel-list at lists.dot.net>
http://lists.dot.net/mailman/listinfo/mono-devel-list<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.dot.net%2fmailman%2flistinfo%2fmono-devel-list&data=01%7c01%7cmiguel%40microsoft.com%7cbaf64ef9ccc64f9bf07a08d3c90ace88%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Zm7m%2fk5MOc5OhZAOzMcjGdXEaiApkYQx4pHs23fPjVY%3d>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20160820/29bfc468/attachment.html>


More information about the Mono-devel-list mailing list