On Sat, Jan 17, 2015 at 05:10:40PM -0500, stephen Turner wrote:
> So i have been allowing musl to auto detect/compile and it seems to have
> always selected i386 by default. I wanted to build it for 686 and noticed
> the --target= didnt seem to do it on my system I specified -march to cflags
> and it still shows i386 for the link. The link is supposed to change
> correct? IE ld-musl-$ARCH.so.1? it appears on my debian vm to always be
> ld-musl-i386.so.1 is it instead pulling the $ARCH var from somewhere off my
> debian system instead of what it was compiled for?
>
> as far as the actual code in the libs, it could have been built in i686
> form both times but i did not try to check it by any means other than
> glancing at the link. I know the -march=i686 was passed during the compile
> process though. while watching the compile output stream by.

If you want a different -march, just put it in the CFLAGS you pass to
configure and it will be honored. This does not change $ARCH or the
name of the dynamic linker, because either way musl is providing the
exact same ABI, which we call "i386". If you build musl with
-march=i686, you won't be able to use the libc.so/ld-musl (or any
binaries static-linked with it) on a pre-686-class x86, but it's still
compatible with exactly the same application binaries.

> Im not sure exactly what is going on at the moment, im assuming i may not
> be doing something right?  A readelf output said the machine is intel 80386
> (In the event thats pointing to my processor im running a quad 64 bit amd)
>
> thanks for any help and insight.

On some archs, extended headers encode the minimum cpu model needed to
use the binary. This is not done on x86 as far as I know. If the cpu
is too old to support some instructions in the binary, you'll just get
SIGILL at runtime.

Rich