Re: [exim-dev] [Bug 2671] Consider integration of localscan_…

Top Page
Delete this message
Reply to this message
Author: Andrew C Aitchison
Date:  
To: exim-dev
Subject: Re: [exim-dev] [Bug 2671] Consider integration of localscan_dlopen patch
On Fri, 6 Nov 2020, admin--- via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=2671
>
> --- Comment #2 from Jeremy Harris <jgh146exb@???> ---
> I had some hope that dlmopen() might help with the lookup-modules conflict.
> But I still can't see a way of getting the combination
> - dl{,m}open()'d local_scan code can only see the defined local_scan API
> symbols of the main exim program, enforced by the linker
> - dl{,m}open()'d lookup modules can see the larger range of (non-C-static)
> symbols, ditto
>
> The discussions I find around these features seem to be only in terms of
> protecting the DSO symbols from the calling program, so as to enforce the API
> of the DSO. Our problem is the opposite, and we have two classes of API -
> with one being a subset of the other.


Could exim provide two libraries, one for each type of module and
have all interface between exim and the module code via the libraries ?

If the lookup library doesn't have an local_scan interface, then
someone writing a local_scan library would not need or want to link
against the lookup library.

(Yes it is open source so they can do whatever they want,
but we have already established that they do not wish to
relink exim to include their module.)

----

Twenty years ago the XFree86 project (and possibly the Xorg project today)
had operating system independent hardware driver modules
(I built a driver on linux and someone else used it on an OS/2 machine).

To do that we wrapped *every* system and (IIRC) library call that the
drivers were allowed to use.
However, IIRC, we did *not* use dlopen.

-- 
Andrew C. Aitchison                    Kendal, UK
             andrew@???