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 Subject: Re: auto-import STATUS From: Robert Collins To: Danny Smith Cc: Charles Wilson , Paul Sokolovsky , cygwin-apps AT cygwin DOT com In-Reply-To: <20010803233635.73332.qmail@web14506.mail.yahoo.com> References: <20010803233635 DOT 73332 DOT qmail AT web14506 DOT mail DOT yahoo DOT com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <996892555.8222.13.camel@lifelesswks> Mime-Version: 1.0 X-Mailer: Evolution/0.11 (Beta Release) Date: 04 Aug 2001 12:37:25 +1000 X-OriginalArrivalTime: 04 Aug 2001 02:23:32.0936 (UTC) FILETIME=[7523BC80:01C11C8C] On 04 Aug 2001 09:36:35 +1000, Danny Smith wrote: > > > > 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." > > > > > In the event, the problem I reported with STLPort probably has nothing > to do with dllimport/dllexport attributes. Instead, I think it stems > from differences in the way basic_[io]stream::sentry is constructed in > dll vs static lib in this implemntation. In dll, sentry is typedef > (within scope of surronding stream class) for standalone separate > class, in static lib sentry is an inner class, defined within the basic > stream classes. Another difference between dynamic linking and static > linking revolves around what is exposed in the header: with DLL linkage > cannot expose the "general" template definitions of helper templates, > unless explicitly declare each and every char and wchar_t that does > reside in the dll as a specialisation. > > If I use the static lib class definitions and --export-all to build the > lib, but the dll class definitions (sans __attribute__(dllimport)) > when building the client and --enable-auto-import, I get no errors with > dll-dependent test app. --export-all should NOT be used with --auto-export. They have different uses! --export-all is used to get _every_ symbol exported, and then filtered - as the current cvs libtool does, using dlltool. --auto-export provides aliases exports for data symbols allowing --auto-import to work. I don't know why --export-all keeps comingup in these auto-import discussions - BUT IT SHOULDN'T. WARNING: --export-all will export data symbols without aliasing AFAICT, so things will link, BUT NOT RUN. > I still don't understand the logic completely, but I cannot get > iostreams to initialise properly, using DLL, with [io]stream::sentry > defined as inner class by client app, regardless of the dllimport > attribute markings. My guess is that it's the use of --export-all that is causing you headaches. Rob > There is a caveat here somewhere about C++ dlls. One of them being not > to let DS lose around templates. > > Danny > > > > _____________________________________________________________________________ > http://messenger.yahoo.com.au - Yahoo! Messenger > - Voice chat, mail alerts, stock quotes and favourite news and lots more!