bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tim Murphy
Subject: Re: dynamic object searching (was: Re: Dynamic objects)
Date: Tue, 30 Apr 2013 08:57:23 +0100

Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit program, the real issue is what architecture was make itself built with. It's sort of a matter of make identifying itself rather than telling you that you're running on ubuntu 13.04 or solaris 10.

Regards,

Tim


On 30 April 2013 03:38, Eli Zaretskii <address@hidden> wrote:
> 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.



--
You could help some brave and decent people to have access to uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/friends/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]