From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1359 Path: news.gmane.org!not-for-mail From: Igmar Palsenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 9/10] GLIBC ABI patches Date: Tue, 24 Jul 2012 20:33:31 +0200 Message-ID: <794E4E83-2775-4DAF-8FDF-D87936250600@palsenberg.com> References: <20120722181332.191d4fa5@newbook> <20120722183828.20b71c9d@newbook> <72fae6f34ad57662422b87379f3fdf9b@exys.org> <65E116B4-1634-478A-957E-A7B374396614@palsenberg.com> <500EE723.5050003@purdue.edu> <77170945-3310-4E43-A57E-D5B00974DCA0@palsenberg.com> <500EE977.70205@purdue.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1343154823 24112 80.91.229.3 (24 Jul 2012 18:33:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Jul 2012 18:33:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1360-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 24 20:33:41 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 1StjvR-0002Mp-DQ for gllmg-musl@plane.gmane.org; Tue, 24 Jul 2012 20:33:41 +0200 Original-Received: (qmail 1398 invoked by uid 550); 24 Jul 2012 18:33:40 -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 1390 invoked from network); 24 Jul 2012 18:33:40 -0000 In-Reply-To: <500EE977.70205@purdue.edu> X-Mailer: Apple Mail (2.1278) Xref: news.gmane.org gmane.linux.lib.musl.general:1359 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. >>>=20 >>> One of the advantages of musl is its LACK of configurability: If you = have =93musl=94, you know what precisely you're getting. >>>=20 >>> With valediction, >>> - Gregor Richards >>>=20 >> While I agree with the above, I still have a few objections : >>=20 >> - 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. >>=20 >> Why bloat code with stuff to provide glibc compatibility ? >>=20 >>=20 >> Igmar >=20 > =93That we even need those aliases is usually a case of bad automake / = autoconf / bad feature detection=94 >=20 > 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 =93bloat=94 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=