From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1364 Path: news.gmane.org!not-for-mail From: idunham@lavabit.com Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 9/10] GLIBC ABI patches Date: Tue, 24 Jul 2012 23:00:54 -0400 (EDT) Message-ID: <11675.132.241.65.164.1343185254.squirrel@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1343206726 27517 80.91.229.3 (25 Jul 2012 08:58:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2012 08:58:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1365-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 25 10:58:45 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1StxQW-00027J-2C for gllmg-musl@plane.gmane.org; Wed, 25 Jul 2012 10:58:40 +0200 Original-Received: (qmail 11587 invoked by uid 550); 25 Jul 2012 08:58:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11520 invoked from network); 25 Jul 2012 03:01:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=bVPfi0zj0pNYDsb4FgDExQ+yMbS5nl2YxYv8G1iN9aA7ErQoEA1TC5oM0D29R87SKgDOzNT86oxG75tIFjG7GpB7DnO4Bu4ti91Y5b32io3ZeHhuKZOwsdoUGi/+DUwMUOYVnGARksuDZyhUiTvgHauW0UPUfjyFj/9NTPUrQTY=; h=Message-ID:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; User-Agent: SquirrelMail/1.4.13 Xref: news.gmane.org gmane.linux.lib.musl.general:1364 Archived-At: > >>>>>>> Just nonsense aliases GNU uses... >>>>>>> Needed for ABI compatability. >>>>>> could we mark them as such? at least with a comment. >>>>>> I really like that musl is so readable. This patch adds some >>>>>> obfuscation that can simply be countered by marking it as "ok this >>>>>> is only here for reason X." >>>>> I would like to see those options behind a compile time option : It >>>>> bloats musl with in many cases unneeded code. I test my compiles with >>>>> musl, and I like it lean and mean. >>>> These are just aliases, not code. There's no bloat there. >>>> >>>> One of the advantages of musl is its LACK of configurability: If you >>>> have *musl*, you know what precisely you're getting. >>>> >>>> With valediction, >>>> - Gregor Richards >>>> >>> While I agree with the above, I still have a few objections : >>> >>> - We don't want glibc compatibility. We want a good libc. >>> - That we even need those aliases is usually a case of bad automake / >>> autoconf / bad feature detection. >>> >>> Why bloat code with stuff to provide glibc compatibility ? >>> >>> >>> Igmar >> >> These are for ABI compatibility, not API compatibility. Nobody using >> glibc uses these symbols intentionally, they are renamed and aliased by >> the library. Last I checked, musl is shockingly close to ABI >> compatibility with glibc, and like it or not, that's a valuable feature. >> If you don't like the *bloat* of it, you'll have to dig out a lot of the >> existing aliases too. > > I've seen lots of code who use internal glibc functions / data structures. > We want to prevent them from being used, that's why I personally have a > problem with adding code like this. Unless it actually serves a real use. > > Igmar The real use here, from what orc was saying, is running the proprietary nvidia driver on a musl-based system. Rich: I have three questions: 1. Should it be possible to weak_alias an externally defined function? ie, src/stdlib/strtod.c defines strtod, then src/glibc-abi/stdlib.c goes: #include "libc.h" #include weak_alias(strtod, __strtod_internal) 2. Would this result in obfustication of the source? 3. Would a subdirectory of src/ solely for glibc ABI/API compatability be appropriate? The point would be to allow removing gnuish extensions without too much trouble. Even if 1 or 2 mean that weak_alias stuff goes in the same file, this could contain functions like the ones added for gnulib (src/stdio/ext*.c). Isaac Dunham