[PATCH 1/4] dlopen: switch to new pathfinder class
Fri Sep 9 08:19:00 GMT 2016
On 09/08/2016 01:58 PM, Corinna Vinschen wrote:
> On Sep 2 13:36, Michael Haubenwallner wrote:
>> On 09/02/2016 10:52 AM, Corinna Vinschen wrote:
>>> On Sep 2 10:05, Michael Haubenwallner wrote:
>>>> Moving the allocator into pathfinder would work then, but still the
>>>> tmp_pathbuf instance to use has to be provided as reference.
>>> Hmm, considering that a function calling your pathfinder *might*
>>> need a tmp_pathbuf for its own dubious purposes, this makes sense.
>>> That could be easily handled via the constructor I think:
>>> tmp_pathbuf tp;
>>> pathfinder finder (tp);
>>> Still, since I said I'm willing to take this code as is, do you want me
>>> to apply it this way for now or do you want to come up with the proposed
>>> changes first?
>> As I do prefer both pathfinder and vstrlist to not know about tmp_pathbuf
>> in particular but a generic memory provider only: Yes, please apply as is.
> Done, minus patch 4.
Then my original problem with dlopen isn't fixed yet, where some application
code within /opt/app/bin/app.exe does dlopen(libAPP.dll), currently finding
/usr/bin/libAPP.dll although app.exe linked against /opt/app/bin/libAPP.dll.
However, thank you anyway!
> I still think that there should be only a single
> pathfinder object and the rest encapsulated within and called via some
> pathfinder member function. I'll look into it later this year.
A thought to avoid the extra tmp_pathbuf_allocator class:
Have cygmalloc.h (or similar) declare the allocator interface,
to allow for tmp_pathbuf to implement it by itself.
The complete idea is to have another allocator implementation using
cmalloc+cfree, as well as one more using malloc+free. Probably there
is use for another one using VirtualAlloc+VirtualFree as well.
Then even path_conv might utilize the allocator interface, using the
cmalloc+cfree implementation (provided by cygmalloc.h) by default...
More information about the Cygwin-patches