Re: .ONESEHLL not working as expected in 3.82

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sat, 27 Apr 2013 14:28:18 -0400
> 
> On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote:
> > Note: there's one more major feature in current git repo that needs to
> > be made available on Windows: dynamic loading of extensions.  That is
> > my highest priority for Make todo list.
> 
> Yes.  I wonder if there are features of gnulib which make this work in a
> cross-platform way?  I've often wondered if we might get some win out of
> utilizing gnulib more in GNU make code.

AFAICS, gnulib does not offer any modules that support dynamic loading
of shared libraries.

> However, I think that investigation and reworking will need to wait
> until after the next release.  I don't want to open that can of worms
> yet... at least not widely.  But if you see something there that would
> make your work for "load" simpler let me know and we'll look into it.

I added a similar facility to Gawk, but there a problem was much
simpler, because Gawk itself was tracking the loaded extensions in
platform-independent code.  So my emulation of dlopen didn't need to
support NULL as its first argument, and didn't care about RTLD_GLOBAL.

By contrast, the way Make's code in load.c is written, it relies on
dlopen to track the shared libraries already loaded.  This is a PITA
on Windows, because there's no similar functionality built in, and the
emulation of dlopen will have to record each loaded extension in some
internal data structure, and search that when dlopen is called with
its 1st argument NULL.  Not rocket science, granted, but it does make
the job larger and the required testing more extensive.

If Make could behave like Gawk, I could have simply copied the code I
wrote for Gawk and reuse it almost verbatim.

> One other thing: I want to make a format cleanup commit at some point to
> deal with a number of annoying issues related to TABs, EOL syntax, etc.,
> as well as update copyright dates, etc.  I don't want to do that when it
> will conflict with major work anyone else is doing, so let me know when
> a good time is for you.

As far as I'm concerned, you can do it whenever you want.  I'd be
greatly surprised if git couldn't figure out how to merge stuff like
that cleanly.  CVS could have barfed, but not git (or any other modern
VCS that tracks the history DAG).