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

[Michael Hutchinson]

On Tue, Jul 13, 2010 at 9:51 AM, Paolo Molaro <lupus at ximian.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.

It was published in the 2.6 headers, though the actual functionality
did not work in normal builds.

>> 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.

Only if your dynamic linker supports looking up symbols in
"__Internal" (NULL). The Android one does not, and if you have non-PIC
static libraries the Windows one does not either.

>> 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?

I did describe a concrete use case for my solution - being able to
P/Invoke static libraries on the aforementioned major platforms.
Without my patch this is currently impossible. I have been using it
for this just fine.

Your solution is a more cumbersome solution for my problem, and does
not solve other concrete use cases.

>> 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).

Maybe, but my patch exists, and cleanly repurposes existing
functionality to fix an existing limitation.

Implementing your proposed solution properly (especially with symbol
granularity rather than library granularity) would require a much more
substantial amount of work.

-- 
Michael Hutchinson
http://mjhutchinson.com