Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3B1EC0A5.61046D2@ece.gatech.edu> Date: Wed, 06 Jun 2001 19:45:41 -0400 From: "Charles S. Wilson" X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Collins CC: Jason Tishler , Cygwin Users Subject: Re: [avail for test] readline-4.2-1 References: <3B1E3D55 DOT AAF8E728 AT ece DOT gatech DOT edu> <00f001c0eeda$1da0e9e0$0200a8c0 AT lifelesswks> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Collins wrote: > > get bash, rip out its included bash/readline/* stuff, replace it with > your new > > readline, and test BASH. I think this is perhaps another reason why > Chet was > > reluctant to accept my patch... > > Bash and OpenSp and ... there are a lot of GPL projects that have that > requirement. Definately part of the testing! Umm...I *thought* only bash actually included the readline source within its own source distribution. Other projects just link to the preexisting "system" readline library, right? (I know bash *can* USE_SYSTEM_READLINE as well, tho) > As I said - most of the logic handling is on the programmer today. > 1) -DDLL_EXPORT is defined. Also I recommend > definingin -DLIBFOO_COMPILATION, to allow importing headers from other > libraries without them getting the wrong decoration. I have sent a > proof-of-concept patch to automake that automates that definition for > all sources in a library, even if the source file is reused across > multiple libraries. > 2) Nothing is _automatically_ defined. -DLIBFOO_DLL_IMPORT is the > "documented" define to use to indicate you will be linking that source > file to a dll library. This should be automatically passed to gcc, but > at this point libtool doesn't know what libraries a given object file > will be linked to. (This problem affects more than libtool. It also > affects gnome modules and similar efforts. There has been some > discussion about good solutions, but nothing concrete yet). > A Configure.in recipe is provided by Gary Vaughn for automatically > setting -DLIBFOO_DLL_IMPORT for libraries at configure time. If you are > building both static and shared .exe's, then automake's If functionality > comes in handy. > 3) is the default behaviour (treated as non-PIC code). Okay, so here's my pattern: READLINE_DLL building dll. causes READLINE_EXPORT(type, symbol) to be defined as "__declspec(dllexport) type __cdecl symbol" READLINE_STATIC building static lib or building an app that links to a static lib. READLINE_EXPORT(type, symbol) is defined as "type __cdecl symbol" linking to dll. causes READLINE_EXPORT(type, symbol) to be defined as "__declspec(dllimport) type __cdecl symbol" To harmonize with libtool, "importing" behavior should be turned on by LIBREADLINE_COMPILATION. Here's the (new) libtool pattern: -DDLL_EXPORT -DLIBNCURSES_COMPILATION building dll. export READLINE symbols, but import NCURSES symbols building static lib or building an app that links to a static lib. -DLIBREADLINE_DLL_IMPORT linking to dll. So, my recipe makes the default behavior "I'm building an app and I want to link to this library dynamically". The libtool default behavior is "I'm building an app and I want to link to this library statically -- or I'm building the static lib itself". Can this be reconciled -- either by clever use of #defines and AC macros, or by changing libtool? I really think dll-import should be the default. > > The indicators are distinct except for -DDLL_EXPORT. > The -DLIBFOO_COMPILATION which automake can add automatically (with my > patch) or manually via libfoo_la_CFLAGS is distinct. > And arbitrary combinations can be ade as well. > (ie build libpng dll source linking to libbz2 dll) > -DDLL_EXPORT -DLIBPNG_COMPILATION -DLIBBZ2_DLL_IMPORT > ( vs build libpng dll source linking to libbz2.a) > -DDLL_EXPORT -DLIBPNG_COMPILATION Ummm...okay. That went by a little fast. I'll have to take a closer look at your examples. > and at the program level say - png2gif > -DLIBBZ2_DLL_IMPORT -DLIBPNG_DLL_IMPORT - link to libbz2.dll and > libpng.dll > -DLIBBZ2_DLL_IMPORT - link to libbz2.dll and libpng.a Ditto. > (There are likely symbol issues with doing mix's like that when the > dependent libraries are not of the same type - ie if you build > libbz2.dll linked statically to libpng.a, I suspect that the application > may need to link statically to libpng.a, but I haven't tested so...) Ummm...why would you do this? libbz2.dll contains the same symbols as libpng.a... > > Also, I believe libtool creates DLL's by doing > '-Wl,--export-all-symbols' and > > doesn't use the .def file, even when one is supplied. This is an > oversight, I > > believe. > > Possibly. The nice thing about what libtool does is that all the symbols > are available without functions needing decoration, and without an > external file needing updating. Rather like unix really :] Except that unix so's ALWAYS "export by name". Windows does both "export by name" and "export by ordinal". Linking to dll's is sometimes done "by name" and sometimes "by ordinal" -- I have yet to figure out which and when. In any case, IF you are unlucky enough to "link by ordinal" to a dll, and then you replace the dll with another that exports the same symbols but with additions so that the ordinal numbers are different from the original dll (--export-all-symbols will alphabetical sort the names when assigning ordingals) -- then boom! The old .exe must be relinked or it won't work. THAT's why .def files are used -- so that you can keep the ordinal numbers the same from version to version. If you can figure out how to ALWAYS force link-by-name, then this is unnecessary. > > > Most of the onus on .dll library creation rests on the programmer > today > > > - using #defines like you have. I intend to change that, but not > > > overnight!. > > Actually, yes -- I'll put it at cygutils next to dllhelpers-0.2.6 and > we can > > refer the curious to both examples. > > Emailed privately (150kb). I didn't put a licence on it - its a derived > work from the Goat book so... if there's an issue there let me know. Thanks, Chuck -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple