Mailing-List:	contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To:	mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID:	<3A69383D.75B8A2A9@ece.gatech.edu>
Date:	Sat, 20 Jan 2001 02:03:25 -0500
From:	Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer:	Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language:	en
MIME-Version:	1.0
To:	chet AT po DOT CWRU DOT edu, cygwin-apps AT sources DOT redhat DOT com
Subject:	bash calls private readline functions

Chet -
  (sorry for the duplicate; I mistyped the mailing list address the
first time)

see subject.  This was discovered on the cygwin platform; about two
months ago I heavily patched readline to support building as a dll on
cygwin, and that library has been working fairly well during our tests.  

However, Windows DLL's are somewhat different than unix shared libs or
static libs, because DLL's only expose functions and variables
explicitly marked as exportable.  When I patched readline, I did so in
such a way that it only exported public functions, and did not export
any functions or variables declared in rlprivate.h -- especially not
those that start with the '_rl_' prefix:

/* NOTE: Functions and variables prefixed with `_rl_' are
   pseudo-global: they are global so they can be shared
   between files in the readline library, but are not intended
   to be visible to readline callers. */
--from rlprivate.h

Recently, one of the cygwin users tried to build bash using my readline
DLL and the --with-installed-readline configure option.  It failed,
because bash was trying to call the following functions:

These are defined in rlprivate.h:
  _rl_set_screen_size
  rl_last_func
  rl_explicit_arg
  rl_editing_mode

The following IS exported by the dll and requested by bashline.o; this
is a different problem:  
  rl_filename_completion_desired
Because of the way DATA (variable) exports from a DLL work, it is
important that the calling program declare these as extern
__declspec(dllimport), not just extern.  I've also hacked the readline.h
file to support this, based on compile-time -Ddefines.  However, this
means that bash should #include the system readline.h, and not its own
local readline.h when --with-installed-readline is specified; currently,
it seems to prefer the its local version.

For more info and discussion, see this thread on the cygwin-apps list:

libreadline.dll.a missing functions
  http://www.cygwin.com./ml/cygwin-apps/2001-01/msg00007.html

Should bash be calling these functions which are clearly private, or
should those functions/extern vars be moved to the public, readline.h
header?  Also, what is the best way to insure that
--with-installed-readline forces use of the installed readline *header*
file?

--Chuck Wilson

P.S. 

Most of the patches that allow building readline as a dll on cygwin are
transparent to other platforms.  I can feed that to you if you're
interested in incorporating the changes.  The only downside is it drives
ctags crazy: all exported (public) functions and variables have to be
declared with a macro like so:

extern READLINE_EXPORT(char *, filename_completion_function) __P((char
*, int));
extern READLINE_EXPORT_VAR(int) rl_filename_completion_desired;

so ctags and emacs can't figure out what the function names are...sigh.

- Raw text -