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" <lu...@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 > > -- > ----------------------------------------------------------------- > lu...@debian.org debian/rules > lu...@ximian.com Monkeys do it better > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list