Re: Latest pkgsrc results [What builds on musl 0.9.13?]

[Rich Felker <dalias@aerifal.cx>]

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