This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: All clear [was Re: [1.7]: For the love of god, don't update!]
On Apr 7 00:12, Dave Korn wrote:
> Christopher Faylor wrote:
> > On Mon, Apr 06, 2009 at 08:08:33PM +0200, Corinna Vinschen wrote:
> >> On Apr 6 13:33, Christopher Faylor wrote:
> >>> On Mon, Apr 06, 2009 at 06:29:43PM +0200, Corinna Vinschen wrote:
> >>>> Wouldn't it help if libc.a, libm.a etc. wouldn't export any symbols at
> >>>> all? I mean, eventually there's libcygwin.a linked in which satisfies
> >>>> all of the requested symbols. What would break if the secondary libs
> >>>> pointing to cygwin1.dll would be stubs?
> >>> We rehashed all of this years ago. IIRC, some configuration scripts
> >>> actually look for symbols explicitly in the libraries.
> >> Hmm, too bad. So it was a naive thought.
> >
> > I think I had the same thought while resisting the whole concept of
> > speclib.
> >
> > Maybe I should have resisted harder.
>
> I think there's a strong argument that those configuation scripts are doing
> a very wrong thing in that they're trying to second-guess internal
> implementation details of the operating environment. If you remember, was
> there a good reason why they couldn't answer the same questions solely using
> link tests? Grepping through library symbols seems quite fragile when so many
> standard C library functions are permitted to be implemented as macros.
I assume they use nm rather than grep.
But maybe we should give up on such broken configure scripts?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/