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 From: "Ralf Habacker" To: Subject: RE: duplicate regexec/regcomp functions detected Date: Tue, 1 Jan 2002 22:54:17 +0100 Message-ID: <001c01c1930e$dbffe390$865c07d5@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 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20020101165921.GA6767@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal > -----Original Message----- > From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf > Of Christopher Faylor > Sent: Tuesday, January 01, 2002 5:59 PM > To: cygwin AT cygwin DOT com > Subject: Re: duplicate regexec/regcomp functions detected > > > On Tue, Jan 01, 2002 at 03:24:49PM +0100, Ralf Habacker wrote: > >After thinking about this problem a while I had an idea how to solve > >such problems instead of using simple links from libcygwin.a to > >libpthread.a and other. The idea was to use the cygwin1.dll as used > >currently, but to build only several import libs (!) for special libs > >like libpthread and may me libm and libc. > > Yes. I had misgivings about this idea when you first mentioned it but > on reflection, I really think that this is a very good idea and, so, > have implemented it. The change is in CVS, as I've mentioned. As I > mentioned, I used roughly your technique to accomplish this goal. > > >The task for doing so (for libpthread) is to look which functions of > >the pthread library are exported (decribed in pthread.h and relating > >headers, but I think it is only the one). This is done by scanning > >pthread.o with nm for every exported symbol. (The consequence for this > >is, that only this symbols are has to be exported) > > > >Then search cygdll.a after those symbols and extract only the relevant > >d000xxx.o from cygdll.a to a newly created import library named > >libpthread.a or other revelant name. > > And, here is where I don't understand your confusion. You don't need to > search cygdll.a. You already have a text file available to you which > contains all of the exports from the cygwin DLL -- cygwin.def. There is a difference. How does the process for integrating libs in cygwin goes on ? Let me explain this for example with the libm. From anywhere (in this case from newlib) there comes a static lib named libm.a build of several object files . The symbols of this lib were used in cxgwin.din/def to export symbol in cygwin1.dll. But this file contains all symbols from every lib, which is integrated in the cygwin dll. So if one uses the cygwin.def as symbol list to extract the relating d000xxx files from cygdll.a to create for example the libm import library, the import library contains all exported symbols and not only the ones from the original libm.a. But I think the libm import library should only contains the libm related symbols and this seems to me true for all other in this way builded libs. Because of this strategy I'm using the second parameter ($reflib) in speclib to the original static lib like libm.a or for example objectfile pthread.o to get only the lib relating symbols. Thats the reason why I'm using speclib in the below mentioned way. Makefile.in: ... /bin/sh speclib cygdll.a ../newlib/libm.a libm.a "$(NM)" "$(AR)" "$(RANLIB)" || exit 0 In words: scan ../newlib/libm.a to get all exported symbols and than extract all object files from cygdll.a to create the partially import library libm.a for libpthread.a /bin/sh speclib cygdll.a pthread.o libpthread.a "$(NM)" "$(AR)" "$(RANLIB)" || exit 0 In words: scan pthread.o (it contains all pthread relating symbols) to get all exported symbols and than extract all object files from cygdll.a to create the partially import library libpthread.a and so on. You see, that the cygwin.din isn't nessessary for doing this (Isn't it real ? Are there some exceptions ?) With this, it is quite easy to integrate additional libs into cygwin. What is not handled currently are exceptions from this rule, so if some symbols must not exported, although they are public in the static lib. Ralf -- 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/