[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Nov 2013 17:16:55 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Latest pkgsrc results [What builds on musl 0.9.13?]
* Rich Felker <dalias@...ifal.cx> [2013-11-09 00:20:10 -0500]:
> On Sat, Nov 09, 2013 at 05:02:52AM +0100, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@...ifal.cx> [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 <sys/perm.h>
#else
#include <sys/io.h>
#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
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.
