From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 641 invoked by alias); 28 Nov 2008 01:12:00 -0000 Received: (qmail 631 invoked by uid 22791); 28 Nov 2008 01:11:59 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Nov 2008 01:10:48 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1L5rsW-0005eV-Pi for cygwin-apps@cygwin.com; Fri, 28 Nov 2008 01:10:42 +0000 Message-ID: <492F450F.DBEC5D47@dessent.net> Date: Fri, 28 Nov 2008 01:12:00 -0000 From: Brian Dessent Reply-To: cygwin-apps MIME-Version: 1.0 To: cygwin-apps Subject: Re: readline build questions References: <492EC608.40105@byu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-11/txt/msg00126.txt.bz2 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