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: List-Archive: List-Post: List-Help: , 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 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.