Victor Duchovni:
> On Tue, Nov 23, 2010 at 01:28:45PM -0500, Wietse Venema wrote:
>
> > Wietse Venema:
> > > Victor Duchovni:
> > > > There is a bit of pain around the ultimate location of the shared
> > > > libraries
> >
> > Perhaps a simpler option is to link into each Postfix program just
> > enough bootstrap library code that it can read /etc/postfix/main.cf
> > and then run-time link the shared Postfix library into itself (it
> > can be simple if we forego macros in the $library_directory value).
>
> This is rather invasive. We'd have to use function-pointer tables for
> the bulk of the Postfix API. I don't think this is very practical.
There is no need to change the calling code - the work happens
once on the other end.
#ifdef POSTFIX_DYNAMIC
extern char *(postfix_mymalloc)(int);
#define mymalloc postfix_mymalloc
#else
extern char *mymalloc(int);
#endif
Outside of Postfix, I did some work that involved dynamic linking:
http://www.isoc.org/isoc/conferences/ndss/10/pdf/19.pdf
> I don't think that compile-time libraries are *that* painful, just a
> bit tricky to get the right user-interface for specifying this value.
>
> Yes, once compiled-in, the run-path is not easily changed. So the
> installation directory for libraries cannot easily be changed at
> install time, except into a directory on the system library search
> path.
For compile-time libraries I think that the only practical option
is not to make it configurable at all. Install them on the system
library search path, such as
/usr/local/lib shared objects
/usr/local/include/postfix header files
Without header files the objects would be worthless.
Now the problem is that every d*mned internal Postfix API becomes
a published interface. That is not where I want to go.
Wietse
