Re: readline build questions

[Brian Dessent <brian at dessent dot net>]

Eric Blake wrote:

> I'm trying to resolve a bash bug caused by relying on auto-import rather
> than __declspec(dllimport): http://cygwin.com/ml/cygwin/2008-11/msg00340.html

There is another potential workaround that doesn't involve modifying the
readline headers.  If there are only a few places that compare function
pointers, then just compare against the _imp__FOO symbol directly.

extern char *_imp__rl_tab_insert;

...

if (function_returning_function_pointer () == _imp__rl_tab_insert)
  {
    /* function returned pointer to rl_tab_insert() in the DLL.  */
  }

This will however fail if you try to link bash against a static readline
because there will be no sythesized _imp__FOO symbol, causing link
failure.  But here the breakage/restriction is limited to bash, rather
than being in the readline headers, i.e. it doesn't affect all readline
clients.

> Is it still possible to allow clients to choose between static and dynamic
> readline at link-time without supplying any compile-time flags, or does
> the fact that I am conditionally using __declspec mean that I have to
> adjust my conditions in readline.h, and that clients that want to link
> statically now have to define READLINE_STATIC in their own source?

Unfortunately, yes.  A call to a function explicitly declared dllimport
can only be satisfied by linking to a DLL containing that function, as
essentially the compiler has inlined the indirection of the thunk stub
into the call site.  So the client of such a library needs an explicit
compile-time way of declaring intent to link statically, removing the
__declspec.

> One other idea I had was to quit distributing a static libreadline.a, and
> only offer the dynamic version.  Does anyone see any problems with the
> idea of no longer providing a static library?

You could make the argument that any consumers of libreadline in the
distro should already be using the shared version anyway on general
principle, so this shouldn't affect them.  But then there could be
potential users that want to statically link it into their own
programs.  I'd say continue to provide the static version, but just note
in the readme the new requirement to configure with
CPPFLAGS=-DREADLINE_STATIC if they intend to statically link.  It's a
reasonable request given that it's not an uncommon idiom which is found
in other libraries, and it fixes a real bug.  (What's more, if anyone
complains you can tell them that the alternative under consideration was
simple removal of the static version in We're Just Mean fashion.)

Brian