mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Re: Coldfire toolchain.
       [not found] <4ca2386b-8ff6-c4b5-bb13-c6a7bd451846@landley.net>
@ 2022-05-09 17:49 ` Rich Felker
  0 siblings, 0 replies; only message in thread
From: Rich Felker @ 2022-05-09 17:49 UTC (permalink / raw)
  To: Rob Landley; +Cc: musl

On Mon, May 09, 2022 at 06:51:57AM -0500, Rob Landley wrote:
> So I lightly hacked my mcm-buildall.sh wrapper script to do:
> 
> ../mcm-buildall.sh m68k:linux-uclinux:"--with-arch=cf --with-cpu=5208
> --enable-default-pie"
> 
> And with an m68k-linux-uclinux tuple (because it's looking for -linux and -musl
> both with a dash in front of them, and thus can't accept one with both), the
> compiler builds but then musl's build fails with:

*-uclinux isn't a valid tuple for musl target. If you're using a
nondefault ABI, you can reflect that in the tuple name as a vendor
label (the optional 4th component) or preferably a suffix (with no -)
after musl, e.g. muslcf. Here there may also be a way you can encode
the difference in the cpu type name; I'm not sure. But if your tuple
isn't *-musl* then gcc will wrongly have glibc or uclibc assumptions.

> checking whether compiler's long double definition matches float.h... no
> .../src_musl/configure: error: unsupported long double type
> 
> And grepping the compiler's #defines for DOUBLE gives:
> 
> #define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L)
> #define __SIZEOF_LONG_DOUBLE__ 8
> #define __DBL_MAX__ ((double)1.7976931348623157e+308L)
> #define __DBL_MIN__ ((double)2.2250738585072014e-308L)
> #define __DBL_EPSILON__ ((double)2.2204460492503131e-16L)
> #define __SIZEOF_DOUBLE__ 8
> 
> Is there something more I should dig out of the logs, or do you know a
> --with-special-float option I can hit it with? (It's a soft float target...)

If you're doing a softfloat target, the ABI musl supports uses 80 bit
long double. --with-arch and --with-cpu should not be needed for the
soft float one since it's 100% compatible with conventional m68k. I'm
guessing either one of those or the -uclinux thing is making gcc
select the different ABI (possibly along with other uclibc/FLAT
oriented things that aren't appropriate with musl).

> I've already got a coldfire kernel booting under qemu with the old toolchain,
> but userspace would NOT do static pie, so I'm down the rabbit hole of building a
> toolchain that's all coldfire static pie...

If something weird is going on with it potentially not loading plain
m68k binaries, I would really start with a known-working-on-cf
userspace and dropping m68k-sf binaries into it, and seeing where they
fail. Otherwise there's going to be a lot of guesswork here since you
can't observe what's going wrong...

Rich

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-05-09 18:04 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <4ca2386b-8ff6-c4b5-bb13-c6a7bd451846@landley.net>
2022-05-09 17:49 ` [musl] Re: Coldfire toolchain Rich Felker

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).