[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"?
Yes.
> > 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.
- Re: dynamic object searching (was: Re: Dynamic objects), (continued)
- Re: dynamic object searching (was: Re: Dynamic objects), David Boyce, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Edward Welbourne, 2013/04/29
- Re: dynamic object searching, Eli Zaretskii, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Eli Zaretskii, 2013/04/29
- Re: dynamic object searching (was: Re: Dynamic objects), Tim Murphy, 2013/04/30
- Re: dynamic object searching (was: Re: Dynamic objects), David Boyce, 2013/04/30
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Paul Smith, 2013/04/29
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Tim Murphy, 2013/04/29
- memory allocation (was: Re: Dynamic objects), Paul Smith, 2013/04/29
- Re: memory allocation, Eli Zaretskii, 2013/04/29
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82),
Eli Zaretskii <=
- Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82), Eli Zaretskii, 2013/04/29
Message not available
- Re: .ONESEHLL not working as expected in 3.82, Eli Zaretskii, 2013/04/28
- Re: .ONESEHLL not working as expected in 3.82, Paul Smith, 2013/04/28
- Re: .ONESEHLL not working as expected in 3.82, Eli Zaretskii, 2013/04/28
- Re: .ONESEHLL not working as expected in 3.82, Paul Smith, 2013/04/28
- Re: .ONESEHLL not working as expected in 3.82, Eli Zaretskii, 2013/04/28
Re: .ONESEHLL not working as expected in 3.82, Eli Zaretskii, 2013/04/29