I am trying to build a Docker image in my Mac M1....
When I try to run my Image I am getting "exec format error" which as I understand a cross platform native image problem but as far as I can see I build the native-image with an arm64 GraalVM.
[1/7] Initializing...
(6,5s # 0,23GB)
Version info: 'GraalVM 22.3.0 Java 17 CE'
Java version info: '17.0.5+8-jvmci-22.3-b08'
C compiler: cc (apple, arm64, 14.0.0)
Garbage collector: Serial GC
1 user-specific feature(s)
And I used a base image from alpine:arm64
https://hub.docker.com/layers/library/alpine/3.17.0/images/sha256-af06af3514c44a964d3b905b498cf6493db8f1cde7c10e078213a89c87308ba0?context=explore
and
uname -a
confirms that is an arm64 based linux.
Linux 5e6ec3a5a46e 5.15.64-0-virt #1-Alpine SMP Mon, 05 Sep 2022 08:02:49 +0000 aarch64 Linux
and
docker image inspect
reports
"Architecture": "arm64",
"Os": "linux",
"Size": 80206330,
"VirtualSize": 80206330,
it is an arm64/linux is.
What is going on here?
#peterz answer is absolutely correct, my assumption that MacOS is Unix/Linux based was false.
When I did a cross platform native-image Generation for alpine, this error disappeared.
Related
when i finished cross-compile chrome for amr64, I found that an error 'Segmentation fault' would be reported after starting chrome.
The cross-compile server system version is: Linux version 4.4.0-157-generic (buildd#lgw01-amd64-037) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) )
The arm64 server system version is: Linux centos7.6-aarch-template 4.14.0-115.e17a.0.1.aarch64
Here are params in args.gn:
import("//build/args/headless.gn")
target_os = "linux"
symbol_level = 0
is_debug = false
blink_symbol_level = 0
target_cpu = "arm64"
disable_histogram_support = true
The autoninja -C out/Debug headless_shell is used for compling headless chrome.
Then copy the Debug folder to the ARM server
But when I run ./headless_shell on the server, there is only segmentation fault, no more information.
just like this:
./headless_shell
Segmentation fault.
Any help or guidance on how I can solve the problem would be greatly appreciated.
I've prepared docker image that demonstrate the problem:
https://drive.google.com/uc?id=1i04_dVL0Rp5rxXCMuHaS4LYREkZjAAW1&export=download
This image is basically alpine:3.11 + apk add openjdk8 maven + my maven project containing sample minimal java class that shows problem
Which you can try with following commands:
# docker load -i bugexample.img
# docker run -w /root/bug-example --name bugtest bugexample /bin/ash build-until-sha-different.sh
If you are lucky enough (sometimes require several attempts) you will get following output:
Found! Sha1 of two subsequent otherwise identical builds are different!
--- 1.sha1
+++ 2.sha1
## -1,3 +1,3 ##
d8d46555c93da579adefc629f1764965a5493edb com/SimpleBug$1.class
75007242aab1e1877d24124d432cb246a79476a8 com/SimpleBug$SimpleBugBuilder.class
-23e8d0ea909b95a7955e0ec0adb4d12ae2193dd1 com/SimpleBug.class
+6a303d69d3f382b23ca04caee4102ee1cd7151e3 com/SimpleBug.class
The core issue with this build is that it produce different bytecode almost each time it get build even though nothing else (neither environment, nor code itself) had changed.
When I do compare these different class files I see that they differ in one single byte:
# cmp -lb 1_SimpleBug.class 2_SimpleBug.class
4053 66 6 65 5
Digging deeper into class file structure I've found that this difference come from stackmapframe constant pool pointers (StackMapTable attribute -> stack_map_frame entry with tag Object_variable_info -> cpool_index)
1_SimpleBug.class
#35 = Utf8 supSetStringParameter10
#36 = Utf8 Lcom/google/common/base/Supplier;
2_SimpleBug.class
#35 = Utf8 supSetStringParameter10
#36 = Utf8 Lcom/google/common/base/Supplier;
So one file points to #35 and another to #36. I don't think this is correct behavior.
I would like to sumbit this to a proper issue tracker but I don't know how to do that since all related JDK trackers are for devs only.
# java -version
openjdk version "1.8.0_242"
OpenJDK Runtime Environment (IcedTea 3.15.0) (Alpine 8.242.08-r0)
OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
# mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/share/java/maven-3
Java version: 1.8.0_242, vendor: IcedTea, runtime: /usr/lib/jvm/java-1.8-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-1050-kvm", arch: "amd64", family: "unix"
And here is archive with java project:
https://drive.google.com/uc?id=1ZBdRzUk00QtpkGGnKAzipMjMtcnkKGN4&export=download
Well... The Mountain in Labour...
All of this was for nothing. Maven was main culprit. First time I ran my build it downloads lots of stuff that maven require (apart from my project dependencies) and then start compilation in same jvm. Second time build runs there is no need to download so compilation starts immediately. I don't know exactly why but first invocation of compiler is somehow affected by state of the jvm and this cause it to produce slightly different bytecode.
Solution was to add <fork>true<fork> to my pom.xml file and build now is totally reproducible... though takes ~2x more time :)
I still believe that this should not happen even if initial compilation happened inside maven jvm, and it may still be topic for improvement in javac but this "workaround" is acceptable.
For two days Travis CI returns version 62 of chrome instead of 77, do you also have the problem on your CI / CD?
.travis.yml (source)
addons:
chrome: stable
trace: (source)
$ export CHROME_SOURCE_URL=https://dl.google.com/dl/linux/direct/google-chrome-stable_current_amd64.deb
Installing Google Chrome stable
1.17s$ wget --no-verbose -O /tmp/$(basename $CHROME_SOURCE_URL) $CHROME_SOURCE_URL
2019-09-11 15:41:31 URL:https://dl.google.com/dl/linux/direct/google-chrome-stable_current_amd64.deb [62302944/62302944] -> "/tmp/google-chrome-stable_current_amd64.deb" [1]
dpkg-deb: error: archive '/tmp/google-chrome-stable_current_amd64.deb' has premature member 'control.tar.xz' before 'control.tar.gz', giving up
dpkg: error processing archive /tmp/google-chrome-stable_current_amd64.deb (--install):
subprocess dpkg-deb --control returned error exit status 2
Errors were encountered while processing:
/tmp/google-chrome-stable_current_amd64.deb
Google Chrome 62.0.3202.94
I add install dpkg
.travis.yml:
addons:
apt:
packages:
- dpkg
chrome: stable
It's a known bug with the dpkg package not supporting xz compressed packages and latest versions of Chrome apparently use it.
The best solution would be to upgrade to dist: xenial build env since trusty are quire old now. Or update the package I guess.
See https://github.com/travis-ci/travis-ci/issues/9361
Changing the Linux distribution fixed the issue for me.
Change:
dust: trusty
To:
dist: xenial
In the .travis.yml file, change my Chrome version from 62.0.3202.94 to 81.0.4044.138
I fixed it on our opensource project by forcing dpkg reinstall:
https://github.com/PrestaShop/PrestaShop/pull/15581
Recently I am trying to build OpenCV with CUDA support, and I met problem while building the module cudaarithm.
OpenCV source: git cloned from : http://github.com/Itseez/opencv.git
OpenCV branch: master branch
OpenCV commit:
`commit 5466e321b8c8f97536002a357e5b7ff49a5d2bf9, on Tue Feb 10 12:17:11 2015 +0000`
CUDA version: CUDA 6.5
Hardware: MacBook Pro (13-inch, Mid 2010)
GPU: NVIDIA GeForce 320M 256 MB
OS Version: OS X Yosemite
Steps I used:
1. cd in OpenCVSource, then mkdir myrelease, and cd myrelease
2. cmake -DPLANTUML_JAR=/usr/local/Cellar/plantuml/8002 -D BUILD_DOCS=1 -DPYTHON2_LIBRARY=/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib -DPYTHON2_INCLUDE_DIR=/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 -DPYTHON3_LIBRARY=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/libpython3.4m.dylib -DPYTHON3_INCLUDE_DIR=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/include/python3.4m -D CMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/usr/local -Wno-dev -DNVCC_FLAGS_EXTRA="-Xcompiler -stdlib=libstdc++; -Xlinker -stdlib=libstdc++" -DOPENCV_EXTRA_CXX_FLAGS=" -stdlib=libstdc++" -DOPENCV_EXTRA_EXE_LINKER_FLAGS="-stdlib=libstdc++" ..
3. make VERBOSE=1
Expect Result: Building success without error
Actual Result: when building OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu, error happend like below:
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(61): *error: identifier "getInputMat" is undefined*
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(67): *error: identifier "getOutputMat" is undefined*
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(92): *error: identifier "syncOutput" is undefined*
Then what action I take:
check the code and I found these undefined symboles are defined in OpenCVSource/modules/core/include/opencv2/core/private.cuda.hpp
check the code and I confrim that the "transpose.cu" file include "opencv2/core/private.cuda.hpp"
check the building log, and I the confirm the private.cuda.hpp is in the search path of header file
cp "opencv2/core/private.cuda.hpp" as another file "opencv2/core/hawk.hpp", and then edit "transpose.cu" to include this new file, and I found
the "undifined symbole error" disapeared.
Although this is a workable workaround, I would like know whether the original OpenCV source cannot be compiled.
All, I think I found the problem cause.
Before I met such problem, I've already build and install OpenCV using older code from the git repo. So that there already have header files in my /usr/local/include/opencv2, especially there is /usr/local/include/opencv2/core/private.cuda.hpp.
However, it is an older one that doesn't define the symbols reporting undefined in above question. At the same time I found during the building nvcc have -I/usr/local/include in the command line, so that it use wrong private.cuda.hpp. As you know it should use the one in OpenCVSource, not the older installed one.
I think the solution is to gracefully remove the original installed OpenCV from my computer, then build again. I am trying and I will report later.
So far I was building libxml2-2.9.2 and previous versions for iOS 32 bits only.
The command I'm using to call configuration script is:
./configure --with-debug=no --host=arm-apple-darwin12.5.0 --with-iconv=no --with-zlib=no
and this was working just fine.
Now to build it for 64 bit architecture I'm passing:
./configure --with-debug=no --host=arm64-apple-darwin12.5.0 --with-iconv=no --with-zlib=no
And this is printing out the following errors:
checking build system type... x86_64-apple-darwin12.5.0
checking host system type... Invalid configuration `arm64-apple-darwin12.5.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin12.5.0 failed
Do you know how to fix this problem?
Thanks in advance.