I have SpringToolSuite 4 installed in macOS 11 "Big Sur" running in aarch64 of Zulu11 OpenJDK 11.0.11+9-LTS . I get this error below when starting up and have added the "-clean" parameter to the two ways I use to start up.
From an Applescript: open /Applications/SpringToolSuite4.app" & " --args -clean
Or from the command line: ./SpringToolSuite4 -clean
It would seem the clean parameter is successfully sent as '-Dosgi.clean="true"' is on the last line below. However, it doesn't seem to help as this is reappearing at every restart.
Are there other ways to do an OSGi clean?
I can't edit the ini-file because macOS will clampdown on this and render the whole installation invalid. Since the clean command seems to get passed, that is likely unnecessary.
Error message:
java.lang.UnsatisfiedLinkError: ~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: dlopen(~/Library/Caches/JNA/temp/jna13221667715595625418.tmp, 1): no suitable image found. Did find:
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: dlopen(~/Library/Caches/JNA/temp/jna13221667715595625418.tmp, 1): no suitable image found. Did find:
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
~/Library/Caches/JNA/temp/jna13221667715595625418.tmp: no matching architecture in universal wrapper
java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
java.base/java.lang.Runtime.load0(Runtime.java:768)
java.base/java.lang.System.load(System.java:1837)
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
com.sun.jna.Native.(Native.java:195)
com.github.dockerjava.zerodep.UnixDomainSocket.(UnixDomainSocket.java:80)
com.github.dockerjava.zerodep.ApacheDockerHttpClientImpl$2.createSocket(ApacheDockerHttpClientImpl.java:124)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:125)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:409)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:164)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:174)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:135)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:165)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:93)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:128)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:178)
com.github.dockerjava.zerodep.shaded.org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:67)
com.github.dockerjava.zerodep.ApacheDockerHttpClientImpl.execute(ApacheDockerHttpClientImpl.java:157)
com.github.dockerjava.zerodep.ZerodepDockerHttpClient.execute(ZerodepDockerHttpClient.java:8)
com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:228)
com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:202)
com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:75)
com.github.dockerjava.core.exec.InfoCmdExec.exec(InfoCmdExec.java:24)
com.github.dockerjava.core.exec.InfoCmdExec.exec(InfoCmdExec.java:14)
com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
org.springframework.ide.eclipse.boot.dash.docker.runtarget.DockerRunTarget.connect(DockerRunTarget.java:130)
org.springframework.ide.eclipse.boot.dash.cloudfoundry.RemoteBootDashModel.lambda$2(RemoteBootDashModel.java:77)
org.springframework.ide.eclipse.boot.dash.model.remote.RefreshStateTracker.call(RefreshStateTracker.java:80)
org.springframework.ide.eclipse.boot.dash.model.remote.RefreshStateTracker.lambda$3(RefreshStateTracker.java:123)
org.springsource.ide.eclipse.commons.frameworks.core.util.JobUtil$6.run(JobUtil.java:193)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
-Dosgi.clean="true"
The issue mentioned above is this: https://github.com/spring-projects/sts4/issues/684
It is not related to OSGi, so -clean doesn't help here. The fix will be part of STS 4.12.1 release, but you could grab a nightly CI build to get the fix right away from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html
On a related note: Once you started STS at least one you should be able to modify the .ini file without issues. If macOS still complains about it, you can remove the quarantine flag from the app:
sudo xattr -r -d com.apple.quarantine SpringToolSuite4.app
This will avoid the error message and let you start your STS4 install even after editing the content.
Related
I want to build a PetaLinux Image for my Ultra96v2.
I followed this guide up until building my application project in Vitis. It looks promising but then while building the application project for my custom platform, Vitis throws this error:
18:08:28 **** Incremental Build of configuration Debug for project dpu_appl_system ****
make all
Generating bif file for the system project
Executing command '::scw::generate_bif -xpfm /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_demo/export/dpu_demo/dpu_demo.xpfm -domains linux_domain -bifpath /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/system.bif' on XSCT
sdcard_gen --xpfm /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_demo/export/dpu_demo/dpu_demo.xpfm --sys_config dpu_demo --bif /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/system.bif --bitstream /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl/_ide/bitstream/dpu_hardware.bit --sd_file /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl/Debug/dpu_appl.elf
creating BOOT.BIN using /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl/_ide/bitstream/dpu_hardware.bit
Running /home/user/Xilinx/Vitis/2021.2/bin/bootgen -arch zynqmp -image /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif -w -o i BOOT.BIN
ERROR:BootGen - syntax error
Line #13, "/media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif".
... emo/sw/atf,dpu_demo/boot/bl31.elf
^
[ERROR] : BIF file parsing failed with code 1
Error writing SD card data : Error when running '/home/user/Xilinx/Vitis/2021.2/bin/bootgen -arch zynqmp -image /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif -w -o i BOOT.BIN'
make: *** [makefile:42: package] Error 1
18:08:36 Build Finished (took 7s.643ms)
It specifically shows me, that there is a comma in the path where it searches for the file. The files are available
at the "normal" location, without the "atf,", "dtb,", etc
at the "weird" location. I created the path so the requested path exists for every file that throws an error message, like
/media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif". ... emo/sw/atf,dpu_demo/boot/bl31.elf
I created the path with the weird artefact "arf,dpu_demo", with the komma in the path, but still it wont work. Is this some kind of problem with Vitis, like some env variables not set correctly, or is the building mechanism just acting weird? I cant resolve this issue, because I am not able to change the paths it is supposed to look for the files. This hinders me in advancing my project. I work on Ubuntu 20.04.
Can anyone help me out here, please? I would really appreciate it!
I asked this question in the Xilinx Community, too, but unfortunately there was no resonance at all.
Thank you so much in advance!
PLEASE READ THE WHOLE ANSWER FOR ACTUAL SOLUTION
I think I got it now, though I did not verify whether the image actually works on my Ultra96v2, yet.
I noticed, that the weird path with commata is inside of the boot.bif and system.bif.
So the first time I tried to build it, the bif wasnt there, but got created (I assume). The bif was ready then but only had a weird path inside, so I took the makefile (you can find it in debug/sd_card), copied it, and just commented out the line GENERATE_BIF_XSCT_CMD = ${GENERATE_BIF} -xpfm ${XPFM_PATH} -domains ${DOMAINS} -bifpath ${BIF_PATH}.
Then I edited the boot.bif and system.bif and changed the atf,boot, uboot,boot, and dts,boot to just boot, so the BootGen wouldnt look into the directories with the commata anymore, but only the boot-directory which was specified.
Once that was set up, I executed the edited makefile in my console, by going into the sd_card-directory and executing the following command:
make -f <your_edited_makefile>
This means, that you cant press "build" in Vitis, it wont work. You build the content on your own and wont get a green check mark beside the project! Then the sd_card-directory was populated with (I assume) all necessary data to boot the Ultra96v2 from SD card. This was the content:
boot.scr
BOOT.BIN
dpu_appl.elf (your application project name, I guess)
README.txt
system.dtb
The underlying issue seem to have been that the ::scw::generate_bif created a path to look after, which didnt exist. Really weird issue, in my opinion.
UPDATE:
I just made some changes to the PetaLinux config with the petalinux-config command and rebuilt everything. Once I go to the Vitis part, I changed the system.bif within Vitis itself, and the project compiled successfully, also populating the sd_card directory, as it seems.
UPDATE 2:
Everything failed, so I tried to get to the *.bif of the Application System project. I opened it (linux.bif) and edited the "atf,", "dtb," and "uboot," out of it. Since this is only created once and references by the following files, this fixed my issue and the build was completed successfully in Vitis. So just ignore my originial answer and update.
I hope this is working and hope it will help some of you.
I am trying to install ghc-mod so that I can use ide-haskell in Atom.
The instructions say to use stack build ghc-mod. It seems that GHC 8.2+ is not supported by ghc-mod, so I set my resolver to lts-9.21.
When running stack build ghc-mod, I keep getting this error (emphasis mine; not using code formatting because line wrap helps readability):
aeson > : can't load .so/.DLL for: /Users/timoffex/.stack/snapshots/x86_64-osx/db354248ca37308313a93487c93190e1d5b819629b60b38b68871c9a691e52b9/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHStime-locale-compat-0.1.1.3-KZ1jqNx8uhlHjmuPPj6V1Y-ghc8.0.2.dylib (dlopen(/Users/timoffex/.stack/snapshots/x86_64-osx/db354248ca37308313a93487c93190e1d5b819629b60b38b68871c9a691e52b9/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHStime-locale-compat-0.1.1.3-KZ1jqNx8uhlHjmuPPj6V1Y-ghc8.0.2.dylib, 5): REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 2 which is not a writable segment (__LINKEDIT) in /Users/timoffex/.stack/snapshots/x86_64-osx/db354248ca37308313a93487c93190e1d5b819629b60b38b68871c9a691e52b9/8.0.2/lib/x86_64-osx-ghc-8.0.2/libHStime-locale-compat-0.1.1.3-KZ1jqNx8uhlHjmuPPj6V1Y-ghc8.0.2.dylib)
... (later)
-- While building package aeson-1.1.2.0 using:
/Users/timoffex/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.24.2.0 build --ghc-options ""
Process exited with code: ExitFailure 1
Progress 1/4
Here's a snippet from the above that looks weird to me:
REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 2 which is not a writable segment
I am running macOS Catalina 10.15.3.
I can't find any mention of this online except for this open GitHub issue: https://github.com/facebook/duckling/issues/446
I also tried lts-7.24. I get the exact same error, except it happens while building profunctors.
What could be the problem? Where can I file a bug?
I had the same error in a project using resolver: lts-9.17.
What fixed it for me is to update stack.yaml and use this line:
resolver: lts-10.9
I need to build RXTX (http://rxtx.qbang.org/wiki/index.php/Main_Page) for a 64 bit platform with --disable-locks. ( the target platform is a Ubuntu Snappy platform so there is a problem with the permissions and lock files).
The .configure --disable-locks and make seemed to run ok.
I got a new .jar file and librxtxSerial.so as a result.
However when I installed them, I get the following error :
java.lang.UnsatisfiedLinkError: gnu.io.RXTXCommDriver.nativeGetVersion()Ljava/lang/String; thrown while loading gnu.io.RXTXCommDriver
java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
Is there something else I need to do?
Are there other object files I need to copy over.
Thanks in advance.
I solved the problem myself.
The problem was that the configure script was not expecting a java version higher than 1.5 as shown here in t he extract :
case $JAVA_VERSION in
1.2*|1.3*|1.4*|1.5*)
#fix_parameters $JPATH/jre/lib/javax.comm.properties
CLASSPATH=".:\$(TOP):\$(TOP)/src:"find $JPATH/ -name RXTXcomm.jar |head -n1
RXTX_PATH="\$(JPATH)/jre/lib/\$(OS_ARCH)"
JHOME=$JPATH/"jre/lib/ext"
So the paths were not being set up correctly for me.
I changed it to
case $JAVA_VERSION in
1.2*|1.3*|1.4*|1.5*|1.7*)
Then it worked ok.
I have followed step by step the tutorial to install Veins, but when I tried running the example scenario (final step) I ended up with the above error.
The whole error was:
Error in module (cModule) RSUExampleScenario (id=1) during network
setup: Class "Veins::ObstacleControl" not found -- perhaps its code
was not linked in, or the class wasn't registered with
Register_Class(), or in the case of modules and channels, with
Define_Module()/Define_Channel().
TRAPPING on the exception above, due to a debug-on-errors=true
configuration option. Is your debugger ready?
Simulation terminated with exit code: -2147483645 Working directory:
C:/Users/user/src/veins-4.3/examples/veins Command line:
../../../omnetpp-4.6/bin/opp_run.exe -r 0 -n .;../../src/veins
--tkenv-image-path=../../images -l ../../src/veins omnetpp.ini
I don't think I have missed a step during the tutorial as I have tried it two times. I did not make any change in anything, I've just strictly followed the tutorial like a robot, so I cannot provide an MCVE with more details than the tutorial.
Here is what I'm using:
- Windows 7 Pro 64 bits
- SUMO 0.25.0 64 bits
All other steps of the tutorial successfully worked until the final step.
I assume this error occurs when running Veins via the OMNeT++ IDE. Or, if you have compiled it with GCC (The error does not happen if you use CLANG)
There are two ways to bypass this error:
Use the .run as executable from your examples directory, which calls veins/run and includes all the required libraries:
Use opp_run as executable and set dynamic libraries to the directory where libveins.so is located (usually src/veins)
PS: to answer #ChristopSommer questions: Veins::ObstacleControl appears in opp_run -l src/veins -h classes
This could be a solution too, but I never tested it: Compiler flags in Eclipse
I'm running Qt 5.3.1 on Mac OS X 10.8 and 10.9 I'm trying to use the macdeployqt tool to bundle libraries and plugins with my executable, but it's apparently trying to include everything on my hard drive.
I invoke it with:
/Applications/Qt/5.3.1/5.3/clang_64/bin/macdeployqt /Users/adamwilt/Desktop/temp/DesktopPixie.app -verbose=2
-qmldir=/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/DesktopPixie
and get lots of normal, expected log messages like:
Log: copy: "/Applications/Qt/5.3.1/5.3/clang_64/qml/QtQuick/Controls/Styles/Base/images" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/QtQuick/Controls/Styles/Base/images"
...and all runs fine until I start getting messages like:
Log: copy: "" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums"
ERROR: file copy failed from "/do-gst"
ERROR: to "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/do-gst"
ERROR: file copy failed from "/rescuepro.properties"
ERROR: to "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/rescuepro.properties"
ERROR: file copy failed from "/rescuepro34act.lic"
and then the fun begins:
Log: copy: "/Applications" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/Applications"
Log: copied: "/Applications/License.rtf"
Log: to "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/Applications/License.rtf"
Log: copy: "/Applications/0xED-1.0.7.app" "/Users/adamwilt/Desktop/temp/DesktopPixie.app/Contents/Resources/qml/MessageBoxUI/Enums/Applications/0xED-1.0.7.app"
It appears it's trying to copy everything (that is, "") into the app, but I ^C out of it while I still have disk space left!
It didn't do this at first; then it did so for a week; then it stopped; now it's back. This is a distributed development project; I'm doing the QML stuff and folks elsewhere are doing the C++. It's possible the other folks are changing a configuration somewhere that's causing this to occur, but I'm the only one doing Mac deployments, so I'm the only one who sees this.
Is there a config file of some sort for macdeployqt where this might be getting triggered? Or is it more likely a problem related to the C++ object MessageBoxUI, which defines several Q_ENUMs (apparently correctly, as it compiles without warnings or errors, and appears to run properly), since that's the target directory when it starts going mad?
Sussed it (well enough that I can go on):
The Qt app I'm trying to deploy lives in ~/Desktop/temp. If I set my current directory to ~/Desktop or ~/Desktop/temp before I run macdeployqt, it runs as expected.
If I run it from from my home directory ~, or ~/Documents, macdeployqt tries to pull in everything it finds in /Applications, /opt, and/or other directories unassociated with the app.
Setting cwd to most other paths, including ~/Downloads, /Applications, subdirectories of ~/Documents, etc. also seems to work; it's only running macdeployqt from ~ and ~/Documents that causes the problem.
No proper explanation as to why this is happening, but just a warning in case someone else sees this sort of weird behavior: try changing to the apps's location before running macdeployqt.