From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17270 invoked from network); 9 May 2022 18:04:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 May 2022 18:04:49 -0000 Received: (qmail 3501 invoked by uid 550); 9 May 2022 18:04:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3469 invoked from network); 9 May 2022 18:04:45 -0000 Date: Mon, 9 May 2022 13:49:22 -0400 From: Rich Felker To: Rob Landley Cc: musl@lists.openwall.com Message-ID: <20220509174921.GE7074@brightrain.aerifal.cx> References: <4ca2386b-8ff6-c4b5-bb13-c6a7bd451846@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ca2386b-8ff6-c4b5-bb13-c6a7bd451846@landley.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] Re: Coldfire toolchain. 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