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: <3B69F92E.1000501@ece.gatech.edu> Date: Thu, 02 Aug 2001 21:06:54 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Sokolovsky , Robert Collins , Danny Smith , DJ Delorie , cygwin-apps AT cygwin DOT com Subject: auto-import STATUS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Now that the initial patch for auto-import has been accepted, I figured I should summarize the current status. Also, for those of us who have to answer questions on various user lists, the two predictable FAQs are at the bottom of this email, with answers. (These were inspired by Danny's "bug" reports ) --Chuck Auto-import BUGS/TODO: ---------------------- 0. make --enable-auto-export the default (uncomment line 151 in pe.em). Requires 0a.) -- e.g. lots more testing. 0a. repeat all testing that was previously done with various in-development versions of auto-import. Sigh. 1. make pe_data_import_dll static? No, used in both pe.em and pe-dll.c. But why? Is this really necessary -- it sure is ugly. Can we fix it? 2. Ralf's bug report. My intuition sez this is related to the pe_data_import_dll thing. See http://sources.redhat.com/ml/binutils/2001-06/msg00742.html synopsis: segfaults when xmalloc returns 0. Caused by running out of heap space due to memory leak (which Ralf has pinpointed). Problem is, how to fix? this bug is only user- visible when linking large libs. 3. Danny Smith reports an esoteric problem: "I am still having some (sorry, one very specific) problem with C++ and auto-import. It is with cerr, cin, cout in the STLport of the SGI iostream lib. These are initialised before main. When building dll with auto-export and using auto-import to link (no dllimport attributes), I get successful link, but runtime failure of app at initialisation (before main). When building dll with --export-all, but marking DATA with dllimport when compiling client, I get successful link and run." 4. Ralf's "--export-whole-archive" problem with static libs: http://sources.redhat.com/ml/cygwin/2001-07/msg01198.html Question: how do you distinguish, automagically, between static libs that *shouldn't* be exported, and static "convenience" libs that *should* be exported? I think this "problem" should be addressed at a higher level -- for a particular package: Makefile.am? Perhaps improvements to the already-experimental robert-collins-libtool? Ralf's suggestion of "--export-whole-archive" and "--no-whole-archive" has possibilities, but it's really orthogonal to the question: "Does auto-import work". (e.g. it's another feature, not an improvement to THIS feature). Another possibility is to extend the new table-based symbol exclusion list (pe-dll.c(auto-export)) so that you can add patterns to those tables from the command line. --exclude-symbols-from-library, --exclude-symbols-from-object, --exclude-symbol-with-prefix, --exclude-symbol-wiht-suffix (there already is an --exclude-symbols option). But again, this is a *different* problem, not specifically a problem with auto-import itself. Auto-import KNOWN ISSUES ------------------------ These behaviors are not bugs. It's just "the way things are". 1. Situation: DLL: built using an "old" version of ld. Has __declspec(dllexport) decorators. client: New client, does not use __declspec(dllimport) Q: Why can't I link this client with this DLL? I'm using the --enable-auto-import option... A: Because the DLL doesn't export the correct thunking items to allow this. Face it, if your library headers (which declare function foo or variable baz) do not match the DLL, then you're going to have problems -- whether the discrepancy is "int foo()" vs. "char foo()" or "extern int foo()" vs. "extern __declspec(dllimport) foo()". Clients and libs should AGREE on definitions! Ordinarily, you shouldn't have to worry about this -- if a library's header was munged to support DLL's the "old way" -- that is, with appropriate defines so that __declspec(dllexport), __declspec(dllimport), and "" all work properly -- then they will continue to work. Just read that package's documentation. Note also that even the "old" ld could do auto-import/export -- if the DLL in question (a) used a functional-only interface, no data exports, (b) no overzealous porter (like me, csw) sprinkled __declspec()'s around -- THEN you could build a client app without __declspec's, too. However, this ONLY works for DLL's written in C. Why? Because there aint no such animal as a C++ dll with a functional-only interface. C++ *has* to export data. Classes ARE data. 2. Situation: DLL: a standard, microsoft system DLL. Generated an import library using dlltool, or used the import libs provided in the w32api package client: New client, accessing exported items in that DLL but doesn't declare them with __declspec(dllimport). Q: Why can't I link this client? I'm using the --enable-auto-import option... A: Because the DLL doesn't export the correct thunking items to allow this -- it's an MS DLL! This is really the same question as #1. However, at least with open-source DLL's, it's possible (if not likely) that these old DLLs may, at some point in the future, be recompiled to support auto-import. However, I'll give you dollars to donuts that MS DLL's will never support it. (Note that you CAN auto-import *functions* from MS DLL's -- you've been able to do that for several years. It's the DATA exports that are troublesome.) So, you can cheat (use auto-import, be lazy with __declspec() on DATA items, etc) IF and ONLY IF the dll was built by a new ld. Since the official Microsoft dll's will never be built that way, you'll aways be stuck with these windows-isms. In other words, you need to "follow the __declspec rules" to link with MS dlls and with "old-style" dlls that were built with an "old" ld. Most of the time, you won't need to worry about this; library maintainers and "platform distributors" (like the main cygwin team, or the main w32api team, will insure that the headers you include will use the __declspec decorators when necessary. All you have to do is make sure to #define the appropriate flags (if any) like -DZLIB_STATIC on cygwin-zlib. Unfortunately, there will never be a replacement for reading the distribution documentation (or package documentation).