Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3C6812FF.3020106@ece.gatech.edu> Date: Mon, 11 Feb 2002 13:52:47 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Gerald S. Williams" CC: cygwin AT cygwin DOT com Subject: Re: "Best" way to build a DLL? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Gerald S. Williams wrote: > Have I just been lucky, or is building and linking of > DLLs now supported by GCC directly? Yes. > > It looks like Nousiainen [am DOT nousiainen AT pp DOT inet DOT fi] has > had the same experience, although Chuck Wilson's reply > (and the FAQs, etc.) seem to indicate that you need to > use libtool, rebase, and/or other tools. a) I never said ANYTHING about rebase b) libtool makes life easy and cross-build compatible. But it is NOT necessary -- see the OTHER examples in dllhelpers. Currently there are 8 -- only the four newest examples use the autotools. The older examples: "C" "CXX" "F77" "C_AND_C++" just use gcc(g++,g77). > I seem to be > getting along fine like this, though: > > gcc -o bin/my.dll -shared obj/my.o > gcc -o bin/my.exe obj/main.o bin/my.dll > > I verified that this uses the library dynamically--the > DLL is required at runtime. > > In fact, this is much nicer since I don't have to worry > about those pesky .def files. And for some libraries, I > avoid warnings that way. For example, when I link with > libpython2.2.dll.a, I get warnings such as: > > Warning: resolving __Py_NoneStruct by linking to \ > __imp___Py_NoneStruct (auto-import) > Warning: resolving _PyInt_Type by linking to \ > __imp__PyInt_Type (auto-import) > > I don't get these when linking to the dll directly. It > sounds like some entries are missing in whatever .def > file is used to build that import library, but that is > just a guess. Wrong. Those "warnings" are really just informational messages. The python library exports *variables* as well as functions. Your DLL probably only exports funtions. DATA exports are very very tricky; there is a lot of magic going on to enable Jason to buld python without having to use a .def file or __declspec() declarations -- previously, these were REQUIRED on exported variables. Thanks the "auto-import" feature of new binutils, this isn't necessary any more -- but when linking a client app that access those variables, the "magic" generates those "warning" messages. It's not a bug, it's a feature. Also: if your dll doesn't export any variables -- or if your client apps do not access those variables -- then you won't see these "Warning: resolving...." messages. > I don't mind using tools where needed (e.g., if I want > to prevent some non-static symbols from being exported), > but I'd rather not use extra tools if I don't need them, > especially since some of the tools don't seem to be in > the normal Cygwin distributions. So for now my makefiles > just use GCC. Again, I never mentioned rebase. I use only official tools to build DLLs. > This has been working so far for me, but as I said it > could just be luck. Do I need to bite the bullet and > figure out how to make a DLL another way? No, it isn't necessary -- but there are other benefits to autoconfiscating and libtoolizing your package...you might want to look into it. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/