This is the mail archive of the
mailing list for the Cygwin project.
RE: duplicate regexec/regcomp functions detected
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: <cygwin at cygwin dot com>
- Date: Tue, 1 Jan 2002 22:54:17 +0100
- Subject: RE: duplicate regexec/regcomp functions detected
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]On Behalf
> Of Christopher Faylor
> Sent: Tuesday, January 01, 2002 5:59 PM
> To: email@example.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
Thats the reason why I'm using speclib in the below mentioned way.
/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
/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
and so on.
You see, that the cygwin.din isn't nessessary for doing this (Isn't it real ? Are there some
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html