Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Feb 2002 17:25:03 +0200
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Maxim Sobolev <sobomax@FreeBSD.org>, Jason Evans <jasone@canonware.com>, jdp@FreeBSD.org, deischen@FreeBSD.org, jasone@FreeBSD.org, hackers@FreeBSD.org, jlemon@FreeBSD.org
Subject:   Re: Linking libc before libc_r into application causes weird problems
Message-ID:  <20020208172503.H78163@sunbay.com>
In-Reply-To: <3C63E961.45706408@mindspring.com>
References:  <1013147180.73417.2.camel@notebook> <20020207234233.D23162@canonware.com> <3C639A8C.6D100326@FreeBSD.org> <3C63A62D.3E4A4FC4@mindspring.com> <3C63AD02.79BA5AF5@FreeBSD.org> <20020208164132.D78163@sunbay.com> <3C63E5D1.1E423698@FreeBSD.org> <3C63E961.45706408@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 08, 2002 at 07:06:09AM -0800, Terry Lambert wrote:
> Maxim Sobolev wrote:
> > No, I meant ld(1). The problem here is that in the case when libc is
> > recorded before libc_r in dynamic dependencies list the resulting
> > executable may not work correctly (see my testcase).
> 
> Patient: "Doctor, it hurts when I record libc before libc_r
> 	  in the dynamic dependencies list!"
> 
> Doctor:  [expected response]
> 
> 8-).
> 
> Seriously, the "Evolution" build process is seriously
> broken; it works on Linux because Linux has a simple
> threads implementation, rather than an efficient one.
> 
Doctor's Assistant: "No library should ever have an explicit
dependency on libc".


Cheers,
-- 
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020208172503.H78163>