[Mono-dev] [PATCH] Make mono_dl_register_library into a fallback

[Miguel de Icaza]

The first problem this is trying to address is precisely that we are running Mono now on four configurations that have no dynamic linker.   All they offer is a static linked image.

The second problem is that this solves is allowing us to statically link existing libraries that have existing invoke bindings without having to modify the c# code every time we port a library (for example, we keep dllimport "Cairo" in the source).

I don't particularly care about the implementation details, but the two scenarios above need to be supported.      We can deal with some adjustments in the four ports with the c API, but the __internal stuff is just not going to work.

Miguel.

Sent from my iPhone

On Jul 13, 2010, at 9:51 AM, "Paolo Molaro" <lupus at novell.com> wrote:

> On 07/02/10 Michael Hutchinson wrote:
>>> This interface is not suitable as a fallback mechanism, it would be too
>>> cumbersome to use and it's probably not ideal even for its intended
>>> purpose. What about a callback registration system instead?
>> 
>> The intended purpose, AFAIK, is to expose statically linked libraries
>> to P/Invoke. That's what I'm using it for, and it's very
>> straightforward to use this way. I have a trivial C# tool that
>> reflects over the library with the P/Invokes and dumps the mappings to
>> source files.
> 
> The interface was just a quick hack from Miguel, in fact is has never
> been exposed as public API as you found out (it was only possible to use
> it in a custom mono build for consoles).
> If you have a tool generating the table now, changing it to generate
> the function needed by the new interface should be trivial, anyway.
> 
>> My patch isn't intended to provide a generic dynamic linker fallback.
> 
> But it does change the code to fallback and you want to publish the API,
> so then we're stuck with an unsuitable API for a new feature.
> 
>> It's meant to provide an easy way to P/Invoke statically linked
>> libraries for all embedders, not just those on platforms without
>> dynamic linkers.
> 
> If you have a working dynamic linker using DllImport ("__Internal")
> is the way to go.
> 
>> That's certainly more flexible, but I'm not convinced it's necessary
>> at this time without concrete use cases. If we're going to include the
> 
> If you don't have concrete cases, why are you expanding the
> functionality of the quick and dirty (and non-public) API?
> 
>> old interface anyway - else we make embedders responsible for
>> reimplementing its functionality - then why not go this path for now,
>> and reimplement it on top of the callbacks later?
> 
> Because it means exposing an API and attaching to it functionality it's not
> suited for.
> 
>> The tricks you mention could be much more useful if callbacks could
>> intercept lookups for individual symbols, rather than acting as a
>> fallback for handling whole libraries. But this would require much
>> more substantial changes to the dynamic linker code.
> 
> A separate API entry point could be added for that.
> To recap:
> *) that API was never public.
> *) I'm not comfortable with publishing that API and supporting it
> with the fallback functionality.
> *) if we need a fallback mechanism something like my proposed
> interface is much better and I think is suitable for publishing
> (maybe with an additional flags value to give a priority vs the
> existing lookups).
> 
> lupus
> 
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list