|
Message-ID: <20131109164147.GH24286@brightrain.aerifal.cx> Date: Sat, 9 Nov 2013 11:41:47 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Cc: Gregor Richards <gr@...due.edu> Subject: Re: Latest pkgsrc results [What builds on musl 0.9.13?] 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 <sys/perm.h> > #else > #include <sys/io.h> > #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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.