mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Rob Landley <rob@landley.net>
Cc: musl@lists.openwall.com
Subject: [musl] Re: Coldfire toolchain.
Date: Mon, 9 May 2022 13:49:22 -0400	[thread overview]
Message-ID: <20220509174921.GE7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <4ca2386b-8ff6-c4b5-bb13-c6a7bd451846@landley.net>

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

           reply	other threads:[~2022-05-09 18:04 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <4ca2386b-8ff6-c4b5-bb13-c6a7bd451846@landley.net>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220509174921.GE7074@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).