[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Feb 2017 02:45:38 -0600
From: Rob Landley <rlandley@...instruments.com>
To: musl <musl@...ts.openwall.com>, Szabolcs Nagy <nsz@...t70.net>
Subject: Re: musl-cross-make build script.
Oh right, this list has the broken reply-to header that makes "reply
all" not reply to all. I need to come up with a thunderbird plugin to
disable that...
On 02/17/2017 05:53 AM, Szabolcs Nagy wrote:
> * Rob Landley <rlandley@...instruments.com> [2017-02-16 16:57:54 -0600]:
>>
>> git clone https://github.com/richfelker/musl-cross-make
>> cd musl-cross-make
>> ~/mcm-buildall.sh
>>
>> And then wait a long time and the result should wind up in "output".
>
> nice
>
>> #!/bin/bash
>
> isn't it posix sh compatible?
>
>> PATH="$LP" make OUTPUT="$OUTPUT" TARGET="$TARGET" \
>> GCC_CONFIG="--disable-nls --disable-libquadmath --disable-decimal-float $GCC_CONFIG" COMMON_CONFIG="$COMMON_CONFIG" \
>> install -j$(nproc)
>
> i didnt know about -j$(nproc), what does it do?
You answered your own question, but I note you can go "taskset 1
./thingy.sh" to do a single processor build with this. :)
>> for i in i686:: \
>> armv5l:eabihf:--with-arch=armv5t armv7l:eabihf:--with-arch=armv7-a \
>> "armv7m:eabi:--with-arch=armv7-m --with-mode=thumb --disable-libatomic --enable-default-pie" \
>> armv7r:eabihf:--with-arch=armv7-r \
>> armv8l:eabihf:--with-arch=armv8-a i486:: sh2eb:fdpic:--with-cpu=mj2 \
>> mipsel:: mips:: powerpc:: sh4:: microblaze:: mips64:: powerpc64:: \
>> s390x:: x86_64::
>
> aarch64 is missing
In theory armv8l is what they used to call aaaarrcchh64 before they
decided to stutter and pretend it wasn't arm or whatever that nonsense
is. (I've done my best to ignore it.)
https://www.arm.com/products/processors/armv8-architecture.php
In practice I haven't tested that one yet and it looks like it's broken,
have to figure out how to hit it with a rock...
(The armv7r target is also broken because it's nommu but not pie, need
to tweak that...)
> (and i don't think it's useful to
> build both armv7l and armv8l toolchains: the former
> can produce binaries for armv8-a targets just fine
These are not multilib toolchains. If armv7l is 32 bit, armv8l is 64
bit, they have different libgcc.a and so on...
> and i don't know about any code in the toolchain target
> libs that would be different on armv8-a,
One is 32 bit, one is 64 bit?
> well may be
> the new float to int rounding and acquire/release
> atomics insns could be used but that's about it)
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
