From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4215 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Latest pkgsrc results [What builds on musl 0.9.13?] Date: Sat, 9 Nov 2013 17:16:55 +0100 Message-ID: <20131109161655.GI1685@port70.net> 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> 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 1384013824 21702 80.91.229.3 (9 Nov 2013 16:17:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Nov 2013 16:17:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4219-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 09 17:17:09 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 1VfBDg-0006ll-65 for gllmg-musl@plane.gmane.org; Sat, 09 Nov 2013 17:17:08 +0100 Original-Received: (qmail 25995 invoked by uid 550); 9 Nov 2013 16:17:07 -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 25987 invoked from network); 9 Nov 2013 16:17:06 -0000 Content-Disposition: inline In-Reply-To: <20131109052010.GE24286@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4215 Archived-At: * Rich Felker [2013-11-09 00:20:10 -0500]: > On Sat, Nov 09, 2013 at 05:02:52AM +0100, Szabolcs Nagy wrote: > > * Rich Felker [2013-11-08 20:01:30 -0500]: > > > > getloadavg > > > > pbzip2, tokyotyrant, distccmon-gnome > > > > > > This would probably be trivial to add. > > > > return -1? > > > > we can add it i guess but these packages could > > use configure checks (i think they are autoconfed) > > Indeed. Not sure if it's useful; just reading from /proc is just as > good. i think it's useless, but looking at codesearch.debian.net it seems to be used in some packages without correct fallback so it's probably better if musl provides it > > > > mallinfo > > > > libfirm > > > > > > Deprecated API but we could provide a dummy anyway. > > > > it's so ugly with the signed int counters, i wouldnt > > support if it's not widely used > > > > i think libfirm can be fixed: it can either do the accounting > > itself or has no business providing process-wide heap info > > statistics (it is only used for a public diagnostic api) > > I thought I remembered other programs using mallinfo too, but maybe > I'm mistaken... The main reason I'd want to provide a dummy is if > there are glibc binaries using it. The range of the counters is fairly > irrelevant; keeping track of the information is prohibitively slow > anyway since it would have to be synchronized between threads on each > call to malloc/free. (glibc does some poor hack keeping this info > per-arena and summarizing it when mallinfo is called, I think...) i see > > > > c_ispeed, c_ospeed (struct termios members) > > > > icdprog > > > > > > If c_* is reserved we could possibly add these. > > > > c_* is reserved > > I'm a bit hesitant to do anything now for fear of breaking more stuff, > but perhaps just #define __c_[io]speed c_[io]speed would be okay... yes, that is non-intrusive (glibc has it by default and debian codesearch shows that other packages use it as well so it makes sense) > > it seems this is a subset of unistd.h on the bsds > > with just macro definitions on glibc it is an alias > > to unistd.h > > Bleh. since glibc does the same i think a sys/unistd.h -> unistd.h redirection is acceptable > > glibc includes linux/ppp_defs.h (plus defines some libc types) > > I don't have any fundamental objection to having nonstandard headers > like this whose applicability is limited to specialized programs rely > on linux kernel headers (we already have soundcard.h or something), > but it might be better to move them ALL out of musl and into a > separate header package at some point... > > > > sys/dirent.h > > > > heirloom-libcommon > > > > > > Possibly another #warning redirect? > > > > can be, bsds have it (a subset of dirent.h) > > but glibc does not have it as far as i can tell > > so heirloom should be more clever about it > > (i guess it has some broken ifdef around it) > > Perhaps __GLIBC__ :-) > yes i think this should be fixed in heirloom > > > > 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 > > > > 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) > > 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 > > 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 > > > > 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