[Top][All Lists]

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

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

From: Eli Zaretskii
Subject: Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
Date: Mon, 29 Apr 2013 22:34:51 +0300

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Mon, 29 Apr 2013 13:59:16 -0400
> > 1. Doesn't the FSF frown upon capability to load _any_ dynamic
> >    objects?  I think they like the GCC method whereby each extension
> >    is required to define a symbol with a certain name
> >    (plugin_is_GPL_compatible in GCC), which is tested at load time,
> >    before the dynamic object is allowed to be loaded.
> Hm.  I guess the concern is that someone will introduce a proprietary
> "plug-in"?


> > 2. The fact that the dynamic object's file extension (.so) is exposed
> >    to the Makefile is unfortunate, because it will hurt portability of
> >    Makefiles: the extension on Windows is .dll.  Can we omit the
> >    extension and append it internally?
> 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.

> The other problem here is that we want to allow rebuilding of dynamic
> objects then re-exec'ing make... if we're trying different extensions
> THAT can be a real problem... what order do we do this in?

Again, let's use only one extension.  .so on Unix, .dll on Windows.
Same as the linker does when you say -lFOO.

> > 3. I suggest to extend the search for dynamic object to a
> >    Make-specific directory (${prefix}/share/make/), before falling
> >    back to the "system-specific path".  Or maybe even not fall back to
> >    any system-specific defaults, because those are generally set for
> >    shared libraries, not for plugins.  (You do NOT want to know where
> >    Windows will look for shared libraries.)
> I'm not sure about having a make-specific directory.  It's not so easy
> to do in UNIX--we'd have to modify the LD_LIBRARY_PATH env. var. I
> suppose.

??? I thought dlopen will gladly use an absolute file name, without
looking at LD_LIBRARY_PATH.  Was I wrong?

> Also we don't really have a precedent of a "make-specific" directory
> like that.

Gawk puts them into ${prefix}/lib/gawk.

> >    . I suggest to request that the buffers for expansions and
> >      evaluation by gmk_expand and gmk_eval be provided by the caller.
> >      It is not safe (and not very convenient) to return buffers
> >      allocated internally by these functions, because the dynamic
> >      object might be compiled/linked with an incompatible
> >      implementation of memory allocation routines.
> I don't see how this can work easily.  We have no idea how large the
> buffer will be until after we complete the expansion/eval.  The only way
> this could work is to use the snprintf() model where we do the expansion
> as now, and if it's too small we return the expected length and they'd
> have to re-invoke with a larger buffer.

Yes, that's what I had in mind.

> I think we should go with this for now.  Hopefully users that do have a
> problem will find a way to make this work.

At least on Windows, it can be a real problem, because the libraries
with which a shared object was linked are hardcoded into it, and
there's more than one way of allocating memory.

How about a callback for allocating memory?  Then Make could call that
callback and get memory that the extension could free.

reply via email to

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