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: <3A7325F6.2097BEB9@ece.gatech.edu> Date: Sat, 27 Jan 2001 14:48:06 -0500 From: "Charles S. Wilson" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: chet AT po DOT CWRU DOT edu CC: cygwin-apps AT sources DOT redhat DOT com Subject: Re: bash calls private readline functions References: <1010123180744 DOT AA23683 DOT SM AT nike DOT INS DOT CWRU DOT Edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chet Ramey wrote: > > > /* 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 > > Thanks. These have been fixed. Out of curiosity, how did you fix these? (I haven't seen an updated tarball on ftp.gnu.org for either readline or bash, so I'm not sure how you approached this). Did you work around it in bash, so that bash doesn't call the private functions, or did you make them public in readline? (If the latter, then I need to modify my DLL exports to take that into account). No problem either way, I'm just curious. > When I configure --with-installed-readline, the build process uses the > readline include files in ${includedir}, which is /usr/local/include by > default. configure sets ${includedir} to ${prefix}/include, but you > can set it explicitly using the `--includedir=xxx' argument to `configure', > or run configure with a different `--prefix'. That's what I thought. I wasn't real sure about this problem -- I didn't reproduce it myself, but the symptoms reported by Earnie sure looked familiar. I'll check back into this after the next version of bash|readline are released. Thanks for looking into the problem. --Chuck