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: <39F5B4DF.96C0D1C5@ece.gatech.edu> Date: Tue, 24 Oct 2000 12:12:15 -0400 From: "Charles S. Wilson" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael DOT Ring AT t-mobil DOT de CC: cygwin AT sources DOT redhat DOT com Subject: Re: AW: DLL naming flamefest References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Ring said: > I have not (yet) checked your site but I would like to get my hands on a > pre-compilesd version of gcc & binutils with all needed features included (The > version you used to build your dll's) > > Are they available ? No, not yet. But that's not necessary to build these dll's. Remember, the current ld prefers implibs just like the new one will. Implibs embded the dll name. So, you could name the zlib dll "my-silly-broken-zlib.dll" if you wanted to -- as long as the implib was named "libz.dll.a" linking will "just work." The upcoming changes to ld just allow you to link directly to a dll (a) when you don't have (or can't find) the implib, and (b) the dll is named, in order of preference, .dll, lib.dll, or .dll. So, you can *use* and *link to* and *build* these new dlls as is, without the new ld -- because you've got an implib. Even with the new ld, you won't be able to link directly to these dlls (even if you delete the implibs and statlibs so they won't interfere with ld's search) -- because the dlls are stripped. I used the stock cygwin distributed binutils and gcc to build all of these packages. --Chuck -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com