[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
