dynamic object searching (was: Re: Dynamic objects)

[Paul Smith]

On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote:

> > Yes, that should be possible.  My concern is that, at least on UNIX, the
> > rules for this are complex and I don't want to reimplement the runtime
> > linker :-).  Maybe something like, first try the path as given and if
> > that fails, try adding arch-specific extensions?
> 
> No, much simpler: _always_ append _a_single_ arch-specific extension,
> and try loading that.  We should document that extension; using the
> one that is used by default by the compiler for producing shared
> libraries should be good enough, I think.

It's not so simple, though, as just .so vs. .dll.  MacOS for example
uses .dylib.  And I think AIX does something else weird that I've
forgotten about.  Others probably do as well.

Plus on UNIX any extension is acceptable since we're using dlopen()
(even with the normal linker you can give any library name you want,
it's only the -l flag that makes assumptions).  Maybe someone wants to
write pattern rules to build their GNU make loadable objects with a
suffix ".gmkso" to distinguish it (and use a different rule) from
building normal .so shared objects.

I want to be sure the benefits outweight the loss of flexibility before
we go down that path.

On Mon, 2013-04-29 at 23:13 +0300, Eli Zaretskii wrote:
> > the same way one creates 1 makefile that can build the same code for 2
> > operating systems - something done every day.  You make it up. You run
> > uname with $(shell) or you pass in an argument from a top level script that
> > does know the platform or whatever.   In the end you have a bit of makefile
> > that says:
> 
> First, there's no uname on Windows.  You are in fact saying that in
> order to run a Makefile one would need something similar to autoconf.

It's probably a good idea to have make predefine a variable containing
the "host" architecture, to avoid the need for uname.  We currently have
an internal variable "make_host" which is the GNU autoconf --host value
on systems where configure runs, and the various config.h templates have
hardcoded values.  Maybe we could do something with this (just using the
--host value might be too arbitrary, I'd have to look at the options).

Which is kind of beside the point, but just a thought :-).