Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com From: "Ralf Habacker" To: "Charles Wilson" Cc: "Kde-Cygwin" , "Binutils" , "Cygwin-Apps" Subject: RE: ordinal linking for cygwin ld Date: Sat, 27 Apr 2002 02:11:30 +0200 Message-ID: <006401c1ed80$15043a80$625d07d5@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal In-Reply-To: <006001c1ed6f$55809f10$625d07d5@BRAMSCHE> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > If you use a .def file to generate your DLL, will the auto-import stuff > > get added to it? Can auto-import even work, if you're linking by > > ordinal -- I thought the _nm_ hints were based on the symbol name, > > no, the symbol name was build from the undef section, if a corresponding > _imp_symbol was found, that means from the client side. There was no access > (except of the dll name) to the implibs data. > Of course are the sections of the implib imported in the resulting binary, but currently I have an idea, how to save additional space in the implib. (for example the qt2.3.1 implib is about 8MB and contains 12079 symbols) At least each symbol name exist twice. Perhaps this can be put together d012073.o: 00000000 i .idata$4 00000000 i .idata$5 00000000 i .idata$6 00000000 i .idata$7 00000000 t .text U __head_qt_2_3_dll (a) 00000000 I __imp__y__C13QIconViewItem (b) 00000000 T _y__C13QIconViewItem ->(a) __imp__y__C13QIconViewItem ^ (b) points to (a) + offset If this is possible there is no space need to build a import lib without names, because it will be a little about the half of the current size. I will see. Regards Ralf