From owner-freebsd-hackers Fri Feb 8 9:53:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 5A5C337B404; Fri, 8 Feb 2002 09:53:15 -0800 (PST) Received: from pool0031.cvx22-bradley.dialup.earthlink.net ([209.179.198.31] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16ZFCq-0001DG-00; Fri, 08 Feb 2002 09:53:09 -0800 Message-ID: <3C640F07.9E2E3525@mindspring.com> Date: Fri, 08 Feb 2002 09:46:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Maxim Sobolev , Jason Evans , 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 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> <20020208172503.H78163@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > 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". One case that springs to mind is the mount system call interface change. A librarr that wrapped mount expecting the old version of the interface should be linked against the shared object that exports the interface on which it depends (in this case, that's libc.so.). There are some cases where this is true, but it's incredibly rare. In this case, though, we have a threaded program that doesn't link libc_r first, which it's *required* to do, even if it *happens* to work on Linux, it *won't* on a lot of other UNIX systems. It's questionable whether it's also erroneous to link the .so's that link gainst libc.so with libc.so instead of libc_r.so, if they are threaded, anyway. Oh... another libc.so linked to a shared object example that's valid: libc_r.so should be linked against libc.so. Duh! Nearly missed that one! 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message