From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4217 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Latest pkgsrc results [What builds on musl 0.9.13?] Date: Sat, 9 Nov 2013 11:41:47 -0500 Message-ID: <20131109164147.GH24286@brightrain.aerifal.cx> References: <527AE027.9030604@purdue.edu> <20131107020120.GY1685@port70.net> <527AF956.1010400@purdue.edu> <20131107024652.GA1685@port70.net> <20131107234630.GC1685@port70.net> <20131109010129.GD24286@brightrain.aerifal.cx> <20131109040252.GG1685@port70.net> <20131109052010.GE24286@brightrain.aerifal.cx> <20131109161655.GI1685@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1384015316 3877 80.91.229.3 (9 Nov 2013 16:41:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Nov 2013 16:41:56 +0000 (UTC) Cc: Gregor Richards To: musl@lists.openwall.com Original-X-From: musl-return-4221-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 09 17:42:01 2013 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 1VfBbk-0003gg-DC for gllmg-musl@plane.gmane.org; Sat, 09 Nov 2013 17:42:00 +0100 Original-Received: (qmail 10152 invoked by uid 550); 9 Nov 2013 16:41:59 -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 10138 invoked from network); 9 Nov 2013 16:41:59 -0000 Content-Disposition: inline In-Reply-To: <20131109161655.GI1685@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4217 Archived-At: On Sat, Nov 09, 2013 at 05:16:55PM +0100, Szabolcs Nagy wrote: > > > > > net/if_ether.h > > > > > cia > > > > > > > > Is this a duplicate of the one in netinet or something different? > > > > > > as far as i can see it's like netinet/if_ether.h on glibc > > > but glibc, freebsd, openbsd dont have it (i can only see > > > it in netbsd) > > > > > > however netinet/if_ether.h includes net/ethernet.h on > > > glibc, but it's the other way around in musl > > > (and on glibc both headers include linux/if_ether.h) > > > > > > that's probably a bug > > > > In musl or in glibc? :) > > musl > > assuming glibc is the defacto standard for these headers > > we should compare the visible symbols in the two headers > glibc vs musl OK. > > > > > sys/perm.h > > > > > xosview > > > > > > > > Seems redundant with sys/io.h? > > > > > > yes, we could add an alias > > > (although on glibc sys/io.h has a bit more stuff) > > > > Yes, I just don't see any use for sys/perm.h without sys/io.h. > > i see this header used in a couple of places like > > #ifdef __i386__ > #include > #else > #include > #endif > > maybe we should add an alias (both are ugly glibc inventions) Or put just the declarations in sys/perm.h and have sys/io.h include sys/perm.h. That might be preferable if sys/io.h (intentionally) breaks on some archs that don't have it. > > > the mm_malloc.h thing is ugly, i'm not sure who else > > > uses that header, but the incompatible prototype > > > might bite others (i still dont quite understand > > > why extern "C" api needs throw() in glibc) > > > > It's an optimization to tell GCC that the function won't throw an > > exception that reaches back to the caller. GCC should assume this by > > default, but because GNU C has support for exceptions in C, it > > doesn't. So they have to work around their own misfeature to avoid > > suboptimal code generation. In musl I just consider that a GCC bug; I > > looked for a way to work around it with global compiler flags rather > > than ugly header hacks, and was told none exists, so until GCC gets > > their act together and fixes this, we can just live with slightly > > suboptimal C++ code generation. > > this is sad > so c++ code that includes mm_malloc.h and stdlib.h will fail What is mm_malloc.h and why is it declaring malloc itself rather than including stdlib.h? > > > earm_epoc_pe.c: In function 'gld_arm_epoc_pe_place_orphan': > > > earm_epoc_pe.c:1512:37: error: empty character constant > > > && (dollar = strchr (secname, '')) != NULL) > > > ^ > > > earm_epoc_pe.c:1646:25: error: empty character constant > > > if (strchr (lname, '') == NULL) > > > ^ > > > > I found the offending code in ld/emultempl/pe.em, but I can't figure > > out why it's breaking. The line in question is: > > > > && (dollar = strchr (secname, '\$')) != NULL) > > > > and running that as a here-document on Busybox ash works fine for me; > > the literal $ (without the \ before it) makes it into the output. > > with the amount of hackery binutils build scripts do > i'm not surprised if this breaks I'm still surprised. I wonder if it's an old version of busybox or something. > > > > > > tk: tkPanedWindow.o: file not recognized: File truncated > > > > > > > > Weird... > > > > > > yes the log has no context for it > > > and tk is a wanted package on pkgsrc > > > > My best guess is something odd in the makefile that caused the file to > > get overwritten with junk, touched as a zero-length file, or similar. > > can be another instance of busybox vs bash/coreutils > incompatibility Yes, possibly. (Is it possible that "ar" is getting used to make a .a file and somehow busybox ar is getting used?) Rich