qemu-irix fails to build under Alpine 3.10 (GCC 8.3) - docker

Just for fun, I'm attempting to build the irixxxx's qemu-irix as a Docker image.
It builds successfuly under Debian Buster (using GCC 8 container). However, it fails to build under Alpine 3.10 (it fails only when I selected the Irix targets), with the following errors (at the make stage):
CC util/oslib-posix.o
In file included from util/oslib-posix.c:39:
/usr/include/sys/signal.h:1:2: warning: #warning redirecting incorrect #include <sys/signal.h> to <signal.h> [-Wcpp]
#warning redirecting incorrect #include <sys/signal.h> to <signal.h>
^~~~~~~
CC util/qemu-openpty.o
util/qemu-openpty.c: In function 'qemu_openpty_raw':
util/qemu-openpty.c:123:9: warning: implicit declaration of function 'openpty'; did you mean 'openat'? [-Wimplicit-function-declaration]
if (openpty(&amaster, aslave, pty_buf, NULL, NULL) < 0) {
^~~~~~~
openat
util/qemu-openpty.c:123:9: warning: nested extern declaration of 'openpty' [-Wnested-externs]
(...)
CC irix-linux-user/linux-user/syscall.o
/qemu-irix/linux-user/syscall.c:6784:22: error: 'F_EXLCK' undeclared here (not in a function); did you mean 'F_RDLCK'?
TRANSTBL_CONVERT(F_EXLCK),
^~~~~~~
/qemu-irix/linux-user/syscall.c:6779:51: note: in definition of macro 'TRANSTBL_CONVERT'
#define TRANSTBL_CONVERT(a) { -1, TARGET_##a, -1, a }
^
/qemu-irix/linux-user/syscall.c:6785:22: error: 'F_SHLCK' undeclared here (not in a function); did you mean 'F_RDLCK'?
TRANSTBL_CONVERT(F_SHLCK),
^~~~~~~
/qemu-irix/linux-user/syscall.c:6779:51: note: in definition of macro 'TRANSTBL_CONVERT'
#define TRANSTBL_CONVERT(a) { -1, TARGET_##a, -1, a }
^
In file included from /qemu-irix/linux-user/syscall.c:121:
/qemu-irix/linux-user/syscall.c: In function 'target_to_host_sigevent':
/qemu-irix/linux-user/syscall.c:7422:27: error: 'struct sigevent' has no member named '_sigev_un'; did you mean 'sigev_value'?
__get_user(host_sevp->_sigev_un._tid, &target_sevp->_sigev_un._tid);
^~~~~~~~~
/qemu-irix/linux-user/qemu.h:501:5: note: in definition of macro '__get_user_e'
((x) = (typeof(*hptr))( \
^
/qemu-irix/linux-user/syscall.c:7422:5: note: in expansion of macro '__get_user'
__get_user(host_sevp->_sigev_un._tid, &target_sevp->_sigev_un._tid);
^~~~~~~~~~
/qemu-irix/linux-user/syscall.c:7422:36: error: '(const bitmask_transtbl *)&<erroneous-expression>' is a pointer; did you mean to use '->'?
__get_user(host_sevp->_sigev_un._tid, &target_sevp->_sigev_un._tid);
^
/qemu-irix/linux-user/qemu.h:501:5: note: in definition of macro '__get_user_e'
((x) = (typeof(*hptr))( \
^
/qemu-irix/linux-user/syscall.c:7422:5: note: in expansion of macro '__get_user'
__get_user(host_sevp->_sigev_un._tid, &target_sevp->_sigev_un._tid);
^~~~~~~~~~
/qemu-irix/linux-user/qemu.h:506:13: warning: left-hand operand of comma expression has no effect [-Wunused-value]
(hptr)), (void)0)
^
/qemu-irix/linux-user/qemu.h:510:31: note: in expansion of macro '__get_user_e'
# define __get_user(x, hptr) __get_user_e(x, hptr, be)
^~~~~~~~~~~~
/qemu-irix/linux-user/syscall.c:7422:5: note: in expansion of macro '__get_user'
__get_user(host_sevp->_sigev_un._tid, &target_sevp->_sigev_un._tid);
^~~~~~~~~~
/qemu-irix/linux-user/syscall.c: In function 'do_syscall':
/qemu-irix/linux-user/syscall.c:13545:25: warning: implicit declaration of function 'sethostid'; did you mean 'gethostid'? [-Wimplicit-function-declaration]
ret = get_errno(sethostid(arg1));
^~~~~~~~~
gethostid
/qemu-irix/linux-user/syscall.c:13545:25: warning: nested extern declaration of 'sethostid' [-Wnested-externs]
make[1]: *** [/qemu-irix/rules.mak:66: linux-user/syscall.o] Error 1
make: *** [Makefile:472: subdir-irix-linux-user] Error 2
The command '/bin/sh -c make && DESTDIR=/tmp/qemu make install' returned a non-zero code: 2
I researched about the differences between Debian's and Alpine's GCC (in fact, libc6 and musl) about similar failures, but I haven't found any information about how to solve this without modifying the code.
So, where can I find more information about this issue and which packages may solve it? Thanks.
Dockerfiles and full log here. Docker container image (Debian Buster) here.

The difference seems to be caused by the underlying libc implementations: glibc of Debian, vs musl-libc of Alpine.
While GNU libc is the defacto standard libc implementation in Linux, musl libc is used by a handful of distributions, such as Alpine Linux and Void Linux. musl is a minimalistic strict-POSIX libc implementation, and is generally not compatible with glibc. Usually, software projects have to be ported to musl libc to be supported on Alpine, especially non trivial applications.
The compilation of syscall.c breaks on several places, the first being:
/qemu-irix/linux-user/syscall.c:6784:22: error: 'F_EXLCK' undeclared here (not in a function); did you mean 'F_RDLCK'?
TRANSTBL_CONVERT(F_EXLCK)
The F_EXLCK is macro is not defined in musl libc's fcntl.h. However, it could be easily patched by defining it manually, for example with make CFLAGS='"-DF_EXLCK=4"'. This is how qemu is patched for musl for non-irix targets (patch link).
However, there are more undefined macros down the road, such as __SIGRTMIN and __SIGRTMAX, the macro TRANSTBL_CONVERT, and probably others. Patching them ad-hoc may not be enough - so it appears to be that the qemu-irix project has to be properly ported for Alpine and musl libc.
If you're willing, you could try following existing qemu musl patches, and attempt to patch it yourself for qemu-irix:
- https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg04773.html
- https://github.com/NixOS/nixpkgs/pull/46449/files
Off topic comment, use make -j to build parallely, which will end much faster.

Related

Using Clang with built libstdc++ produces undefined symbol _ZSt15__once_callable

I have built libstdc++ with no modifications yet:
cd gccsrcdir/libstdc++-v3/build
../configure --prefix=$PWD/../install
make && make install
I am using Ubuntu 21.10 and I set the following environment variables:
export LIBRARY_PATH=gccsrcdir/libstdc++-v3/install/lib
export LD_LIBRARY_PATH=gccsrcdir/libstdc++-v3/install/lib
export CPLUS_INCLUDE_PATH=gccsrcdir/libstdc++-v3/install/include/c++/13.0.0
When I then use the system's GCC, I get no problems. When I use the system's Clang, it produces a symbol lookup error - even with no parameters:
clang++
clang++: symbol lookup error: /lib/x86_64-linux-gnu/libicuuc.so.67: undefined symbol: _ZSt15__once_callable, version GLIBCXX_3.4.11
In fact I only need to update LD_LIBRARY_PATH to arrive here. What am I doing wrong?
The symbol -- std::__once_callable is defined in your system libstdc++.so.6 (it has version GLIBCXX_3.4.11 in my build, which means it was added in GCC-4.4.0).
Your build of libstdc++.so.6 should define this symbol as well, but for some reason does not. That is a problem -- any binary which uses this symbol will fail at runtime when using your build of libstdc++.so.6 (which is happening because you've pointed LD_LIBRARY_PATH to it).
Note: in your case it's the clang++ binary that is failing to run -- any flags you add to it (such as -femulated-tls) are irrelevant -- they only affect the binary that would have been generated IF clang++ itself didn't fail.
I just repeated your configure && make steps, and the library built this way also doesn't define this symbol.
I then repeated the configure && make, but starting from top-level GCC directory, and libstdc++.so.6 built that way does define the symbol.
Conclusion: libstdc++ is configured differently during "normal" GCC build.
The definition comes from mutex.o, which is built from ./libstdc++-v3/src/c++11/mutex.cc, and which has this chunk of code:
#ifdef _GLIBCXX_HAS_GTHREADS
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
#ifdef _GLIBCXX_HAVE_TLS
__thread void* __once_callable;
__thread void (*__once_call)();
...
So it sounds like either _GLIBCXX_HAS_GTHREADS or _GLIBCXX_HAVE_TLS is not defined when doing configure && make in the libstdc++-v3 directly.
Digging further, I see that libstdc++-v3 determines _GLIBCXX_HAS_GTHREADS by trying to compile #include "gthr.h", and that file is available in libgcc/gthr.h, but not in "standard" installed GCC.
../libstdc++-v3/configure && grep _GLIBCXX_HAS_GTHREADS config.h
/* #undef _GLIBCXX_HAS_GTHREADS */
TL;DR: correctly configuring libstdc++.so is complicated, and you will be better off building complete GCC.
Once you have a complete build, you will have a libstdc++-v3 directory properly configured, and can just rebuilt in that directory:
grep _GLIBCXX_HAS_GTHREADS ./x86_64-pc-linux-gnu/libstdc++-v3/config.h
#define _GLIBCXX_HAS_GTHREADS 1

golang gocv error when go run ./cmd/version/main.go

I'm pretty new in Golang and i have some problems to install gocv.
I don't know weather it is impotent to know, but
I use Manjaro Linux on version 5.19.3, the current go- version is 1.14.2 and last but not least gccgo on version 10.1.0 (amd64).
I installed gocv as described on https://gocv.io/getting-started/linux/
go get -u -d gocv.io/x/gocv
cd $GOPATH/pkg/mod/gocv.io/
make install
If it works correctly, following message should be desplayed:
gocv version: 0.24.0
opencv lib version: 4.4.0
# gocv.io/x/gocv
In file included from features2d.cpp:1:
features2d.h:22:21: error: 'SIFT' is not a member of 'cv'
22 | typedef cv::Ptr<cv::SIFT>* SIFT;
| ^~~~
features2d.h:22:21: error: 'SIFT' is not a member of 'cv'
features2d.h:22:25: error: template argument 1 is invalid
22 | typedef cv::Ptr<cv::SIFT>* SIFT;
| ^
features2d.cpp: In function 'int* SIFT_Create()':
features2d.cpp:434:28: error: 'SIFT' is not a member of 'cv'; did you mean 'SIFT'?
434 | return new cv::Ptr<cv::SIFT>(cv::SIFT::create());
| ^~~~
In file included from features2d.cpp:1:
features2d.h:22:28: note: 'SIFT' declared here
22 | typedef cv::Ptr<cv::SIFT>* SIFT;
| ^~~~
features2d.cpp:434:28: error: 'SIFT' is not a member of 'cv'; did you mean 'SIFT'?
434 | return new cv::Ptr<cv::SIFT>(cv::SIFT::create());
| ^~~~
In file included from features2d.cpp:1:
features2d.h:22:28: note: 'SIFT' declared here
22 | typedef cv::Ptr<cv::SIFT>* SIFT;
| ^~~~
features2d.cpp:434:32: error: template argument 1 is invalid
434 | return new cv::Ptr<cv::SIFT>(cv::SIFT::create());
| ^
features2d.cpp:434:38: error: 'cv::SIFT' has not been declared
434 | return new cv::Ptr<cv::SIFT>(cv::SIFT::create());
| ^~~~
features2d.cpp: In function 'KeyPoints SIFT_Detect(SIFT, Mat)':
features2d.cpp:443:9: error: base operand of '->' is not a pointer
443 | (*d)->detect(*src, detected);
| ^~
features2d.cpp: In function 'KeyPoints SIFT_DetectAndCompute(SIFT, Mat, Mat, Mat)':
features2d.cpp:460:9: error: base operand of '->' is not a pointer
460 | (*d)->detectAndCompute(*src, *mask, detected, *desc);
| ^~
Fehler: Prozess beendet mit Rückgabewert 2.
I tried to find a solution on in the internet, but I don't even understand the problem.
I hope someone can help me.
best regards
Felix
SIFT (Scale-Invariant Feature Transform) algorithm is a patented algorithm that requires user to import a non-free header file if you need to use it as below :
#include <opencv2/nonfree/nonfree.hpp>
However, the patent is already expired as of now. (OpenCV 4.4.0) So this package is moved to main repository of opencv (check release highlightes https://opencv.org/opencv-4-4-0/)
As a result,the gocv repository which using SIFT has been updated to get this algorithm from the opencv main repository as below, (in gocv v0.24.0 change log: https://github.com/hybridgroup/gocv/commit/04b71cbb6d82e8c396ccbbf0d65b446a80a0e8fa)
typedef cv::Ptr<cv::SIFT>* SIFT;
This is the line of code updated which causes you failed to build.(You will only get this error if you are not using opencv 4.4.0, you may check the MakeFile that you are using)
To solve this problem, you may try get/update the gocv repository again now as they have updated all MakeFile to use opencv 4.4.0 already. Or you may just manually update your MakeFile to change the opencv version to 4.4.0

llvm-link error when using memcpy in C code and compiling with wasm target

I am trying to compile two *.c files to LLVM bitcode via clang, link them together using llvm-link, and make a single *.wasm file out of it. I built LLVM on my machine via the Makefile provided by https://github.com/yurydelendik/wasmception
This works fine until I use memcpy in the C code. Then llvm-link stops with error:
Intrinsic has incorrect argument type!
void (i8*, i8*, i32, i1)* #llvm.memcpy.p0i8.p0i8.i32
The following is a minimal example to reproduce the issue:
one.c
#define EXPORT __attribute__((visibility("default")))
#include <string.h>
char* some_str();
EXPORT void do_something() {
char* cpy_src = some_str();
char other_str[15];
memcpy(other_str, cpy_src, strlen(cpy_src));
}
two.c
char* some_str() {
return "Hello World";
}
Execute the following commands:
$ clang --target=wasm32-unknown-unknown-wasm --sysroot=../wasmception/sysroot -S -emit-llvm -nostartfiles -fvisibility=hidden one.c -o one.bc
[...]
$ clang --target=wasm32-unknown-unknown-wasm --sysroot=../wasmception/sysroot -S -emit-llvm -nostartfiles -fvisibility=hidden two.c -o two.bc
[...]
Note that no optimization is done because that would eliminate the unnecessary memcpy call here. As I said, this is a minimal example out of context to show the error.
$ llvm-link one.bc two.bc -o res.bc -v
Loading 'one.bc'
Linking in 'one.bc'
Loading 'two.bc'
Linking in 'two.bc'
Intrinsic has incorrect argument type!
void (i8*, i8*, i32, i1)* #llvm.memcpy.p0i8.p0i8.i32
llvm-link: error: linked module is broken!
When I comment out the memcpy call in the example file, the error is gone. Of course this is not an option in the real project I am working at.
Am I doing something wrong? Is it a bad idea in general to use memcpy in a WebAssembly context? Can this be a bug in LLVM/Clang?
Reading through these github issues, it seems the memcpy intrinsic is not currently supported by the WASM backend:
https://github.com/WebAssembly/design/issues/236
https://github.com/WebAssembly/design/issues/1003
As a workaround, you could instruct clang to disable intrinsic expansion using -fno-builtin, so that the generated code will call the actual memcpy function.

How to exclude old version library in /usr/local?

Disclamer: using -nostdcincl isn't possible because it excludes needed system libraries. Here instead the problem seems to be that tthe compiler ignores my -I directives
I have installed a library (OpenCV) in ~/local on a remote machine, since I don't have sudo access there. Notice that an older version of the same library is installed in /usr/local.
I'm trying to compile this code:
g++ -DCC_DISABLE_CUDA -I/home/spm1428/CloudCache -I/home/spm1428/local/include/opencv -I/home/spm1428/local/include/opencv2 -I/usr/include/boost -I/home/spm1428/vlfeat -O3 -g -Wall -c -fopenmp -std=c++11 -c -o Descriptor.o ../Descriptors/Descriptor.cpp
However, the returned error is:
In file included from /usr/local/include/opencv2/opencv.hpp:77:0,
from /home/spm1428/CloudCache/Utilities/Utility.hpp:11,
from ../Descriptors/Descriptor.cpp:17:
/usr/local/include/opencv2/highgui/highgui.hpp:165:25: error: redeclaration of ‘IMREAD_UNCHANGED’
IMREAD_UNCHANGED =-1,
^
In file included from ../Descriptors/Descriptor.cpp:13:0:
/home/spm1428/local/include/opencv2/imgcodecs.hpp:65:8: note: previous declaration ‘cv::ImreadModes IMREAD_UNCHANGED’
IMREAD_UNCHANGED = -1, //!< If set, return the loaded image as is (with alpha channel,
^
In file included from /usr/local/include/opencv2/opencv.hpp:77:0,
from /home/spm1428/CloudCache/Utilities/Utility.hpp:11,
from ../Descriptors/Descriptor.cpp:17:
/usr/local/include/opencv2/highgui/highgui.hpp:167:24: error: redeclaration of ‘IMREAD_GRAYSCALE’
IMREAD_GRAYSCALE =0,
I think that this happens because there is another version installed. How can I solve this?
I think this error happens for the same reason (the old version doesn't have cv::xfeatures2d::SURF).

Building a C library (GMP) for arm64 iOS

I'm trying to build a C library (GMP 6.0.0) for arm64 for use on iOS. I'm running the configure script with the invocation below (compiler is as found using xcrun --find).
./configure \
CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" \
CPP="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -E" \
CPPFLAGS="-target arm64-apple-darwin -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/ -miphoneos-version-min=7.0" \
--host=aarch64-apple-darwin
However this fails at the following line ("long long reliability test 1"):
checking compiler /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -O2 -pedantic -target arm64-apple-darwin -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/ -miphoneos-version-min=7.0... no, long long reliability test 1
configure: error: could not find a working compiler, see config.log for details
Full config.log available here. It shows multiple warning and errors for the long long reliability test compile, including the following:
conftest.c:9:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
f(){static const struct{t1 n;t1 src[9];t1 want[9];}d[]={{1,{0},{1}},};t1 got[9];int i;
^
conftest.c:10:44: error: implicit declaration of function 'h' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
for(i=0;i<1;i++){if(e(got,got,9,d[i].n)==0)h();g(i,d[i].src,d[i].n,got,d[i].want,9);if(d[i].n)h();}}
^
conftest.c:10:48: error: implicit declaration of function 'g' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
for(i=0;i<1;i++){if(e(got,got,9,d[i].n)==0)h();g(i,d[i].src,d[i].n,got,d[i].want,9);if(d[i].n)h();}}
^
conftest.c:10:100: warning: control reaches end of non-void function [-Wreturn-type]
for(i=0;i<1;i++){if(e(got,got,9,d[i].n)==0)h();g(i,d[i].src,d[i].n,got,d[i].want,9);if(d[i].n)h();}}
^
Using --host=none it works fine, but I'd really like to figure out how to build it with assembly optimized for arm64.
My system is x86_64-apple-darwin13.1.0 (or coreisbr-apple-darwin13.1.0 according to config.guess), an early '11 Core i7 MBP running OS X v10.9.2. I'm using Xcode 5.1 (5B130a).
Any help appreciated.
EDIT 1
Compiling for ARMv7 passes configure, but fails on make (full configure/make output here), apparently while compiling some assembly:
tmp-dive_1.s:165:18: error: unexpected token in '.section' directive
.section .rodata
^
EDIT 2
#MarcGlisse: By forcing clang to ignore the errors as suggested (-Wno-...) arm64 passes configure, but then fails on make (full output here):
tmp-mul_1.s:59:2: error: unrecognized instruction mnemonic
bcc Lfi1
^
tmp-mul_1.s:60:2: error: unrecognized instruction mnemonic
beq Lfi2
^
As a side note: these commits, I assume intended to remove the need for suppressing the error, don't seem to work i.e. I get the same error when removing the supression.
For armv7, using these commits as suggested fixes the .section error, but make fails later on with the following (full output here):
tmp-mode1o.s:64:2: error: unknown directive
.protected ___gmp_binvert_limb_table
^
EDIT 3
Using the suggested edits, armv7, armv7s, i386 and x86_64 now all compile with assembly!
For arm64 the edits get it past the previous error, but now gives several errors about an invalid input constraint 'rZ', all in the same file (full output here):
divrem_1.c:237:5: error: invalid input constraint 'rZ' in asm
udiv_qrnnd_preinv (*qp, r, r, nshift, d, dinv);
^
../gmp-impl.h:3062:2: note: expanded from macro 'udiv_qrnnd_preinv'
add_ssaaaa (_qh, _ql, _qh, _ql, (nh) + 1, (nl)); \
^
../longlong.h:551:7: note: expanded from macro 'add_ssaaaa'
: "rZ" (ah), "rZ" (bh), "%r" (al), "rI" (bl) __CLOBBER_CC)
EDIT 4
After commenting out add_ssaaaa and sub_ddmmss in longlong.h and editing some more assembly instructions in gcd_1.asm (blo to b.lo etc.), it now fails with several of the following errors (full output here):
tmp-invert_limb.s:75:22: error: immediate value expected for shifter operand
add x1, x1, x2, lsr 1
^
tmp-invert_limb.s:75:22: error: invalid operand for instruction
add x1, x1, x2, lsr 1
^
I'll post a total diff later.
EDIT 5
Ok, that gets us another step further, but it now hits into (full output here):
tmp-invert_limb.s:52:2: error: ADR/ADRP relocations must be GOT relative
adrp x1, approx_tab
^
If this keeps going it might be better to continue this via email.
"Support for ARM64 alias Aarch64 alias ARMv8"
https://gmplib.org/gmp6.0
Copyright issues aside...
GMP may not be compatible with Apple's proprietary CPU, and may not be compatible with Clang/LLVM. Being a GNU project it is probably more thoroughly tested with GCC on non-proprietary chipsets.
A quick search shows historically at least there have been issues compiling GMP with clang.
You really should email the GMP community and ask for help on this one.

Resources