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: <3A18549E.8674EFEA@ece.gatech.edu> Date: Sun, 19 Nov 2000 17:30:54 -0500 From: "Charles S. Wilson" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cygwin AT sources DOT redhat DOT com Subject: Re: [ANNOUNCEMENT] Updated: binutils-20001029-2.tar.gz References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Wilson wrote: > > Chris Faylor wrote: > > > > - Fix from DJ for getting ordinal values right when generating a DLL. > > > > I'm not convinced this actually did the trick. I rebuilt libXpm-noX > (which uses a def file with 'skipped' numbers -- since I want to keep > the ordinals the same between the -X and the -noX versions, but the > -noX is missing a few functions). Hmmm...more experimentation shows that the problem seems to be related to __declspec(dllexport)'ed functions that are not explicitly listed in the def file. When there are missing ordinals in the def file, the new ld inserts the missingInTheDefFile-but-__declspec'ed functions to fill in the holes. However, those functions which ARE specified in the def file DO get assigned the correct ordinal. However, the OLD linker got really confused by the situation, and filled in the 'holes' with *any* function -- thus screwing up the ordinals occaisionally for the functions listed 'farther down' in the def file. So, I think this ld is A-OK. Sorry for the false alarm. (I 'fixed' my problem by explicitly listing EVERY declspec'ed in the def file, using whatever wacky numbering scheme the OLD linker put into the original libXpm dll. The new linker obeys this, so the new libXpm dll matches the old one. Yay! --Chuck -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com