IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Recently yet another post-build check has been added:
/usr/bin/strip: Unable to recognise the format of the input file `./usr/lib/aarch64-linux-gnu/sys-root/usr/lib64/libc.a(getutxid.o)'
which (unsurpisingly) broke the build.
Tell strip to ignore the foreign libraries.
libsanitizer wants limits.h, which is a part of compiler. However
the compiler hasn't been installed yet, since we are building its
runtime. Disable libsanitizer to avoid the problem.
TODO: Perhaps there's a special target to build an install compiler
headers only. Figure it out and re-enable libsanitizer.
As of now the driver tries to locate `as` (and `ld`) somethere in $PATH
if nothing was found in libsubdir and tooldir. This is a bad idea for
a cross-compiler. Use DEFAULT_TARGET_MACHINE-{as,ld} instead.
Note that `collect2` already behaves that way (which is a good thing).
Apparently `invoke_as:` directive in GCC spec file applies to running
assembler on C/C++ compiler output. However compiling `assemble` (.s) and
`assembler-with-cpp` pseudo-languages use `as` instead of ${target}-as)
anyway. Fortunately GCC searches for `as` in libexec/gcc/$target/$version
directory. Therefore add symlink to ${target}-as into that directory.
Do the same thing for ar, ld, nm, objcopy, etc just in a case.
aarch64-targeted cross-compiler definitely does not make any sense on
aarch64 and armh (native or multilib compilers are available).
Using 32-bit x86 as a development platform does not make any sense either.
Same applies to mipsel. ppc64el and e2k might be powerful enough but
these machines are way too rare/expensive.
