From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16666 invoked from network); 6 Jul 2000 10:15:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Jul 2000 10:15:47 -0000 Received: (qmail 21990 invoked by alias); 6 Jul 2000 10:15:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12179 Received: (qmail 21977 invoked from network); 6 Jul 2000 10:15:33 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: "maurice s. barnum" , "Peter Stephenson" Cc: "Zsh hackers list" Subject: RE: Getting dynamic loading to work on cygwin Date: Thu, 6 Jul 2000 14:15:28 +0400 Message-ID: <000701bfe733$1bdc6440$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: > : > : Yuk, it looks like your right. Using dlsym to get the > symbol works OK, but > : simply linking against the DLL and loading it doesn't seem > to pick up the > : right value. That will screw up a lot of things. > > Data references can be imported on Win32, but you need help from the > compiler to generate an extra indirection on access to the > imported data. > This of course implies that the compiler needs to know what data is > being imported, which with normal Win32 compilers is indicated by > decorating the extern declaration with '__import' or > '__declspec(dllimport)'. > I don't have cygwin or it's documentation handy, so I don't know if > gcc supports this or some alternate spelling. > Cygwin supports __declspec(dllimport/export) but it different matter. The following case works (foo.dll is assumed to access variable in bar.dll) build bar.dll that defines and exports variable build foo.dll with bar stub library bar.a that directly references this variable (extern ...) the following case does not work build bar.dll that defines and exports variable build foo.dll that loads bar.dll with dlopen() and lokos up variable with dlsym(). Variable is found but seems to point to the wrong location. I did define variable with __declspec(dllexport) but it did not help. -andrej