Re: dynamic object searching (was: Re: Dynamic objects)

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: Tim Murphy <address@hidden>, address@hidden
> Date: Mon, 29 Apr 2013 16:34:01 -0400
> 
> 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.

OK, how about a lesser solution: have a builtin variable, say $SOEXT,
which will have a platform-specific default extension of shared
objects?  Then whoever wants to use it for a portable Makefile, could
do that, and people who want to use .gmkso can do that, too.  WDYT?

> It's probably a good idea to have make predefine a variable containing
> the "host" architecture, to avoid the need for uname.

That's a good feature regardless, but I think we should provide some
solution for the extension as well.