This is connected to my previous question. I've done a bit of research and managed to do the following:
I set the LD_LIBRARY_PATH environment variable to /home/user1/anaconda3/lib/ since this is where my libstdc++.so.6 is located. After that I kept getting the "could not find CXXABI_1.3.11 which is required version" error, and so did:
strings /home/user1/anaconda3/lib/libstdc++.so.6 | grep CXXABI
which outputs:
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_1.3.8
CXXABI_1.3.9
CXXABI_TM_1
CXXABI_FLOAT128
I'm assuming that in order for the original program to run properly, I need to be seeing CXXABI_1.3.11 when I run the strings command as I did.
Does anybody know how I might be able to upgrade the version here? Thanks.
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 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.
JModelica is refusing to load the file libhsl.so as a shared library, even though I have set the LD_LIBRARY_PATH variable:
Exception of type: OPTION_INVALID in file "../../../../Ipopt/src/Algorithm/IpAlgBuilder.cpp" at line 321:
Exception message: Selected linear solver MA27 not available.
Tried to obtain MA27 from shared library "libhsl.so", but the following error occured:
libhsl.so: cannot open shared object file: No such file or directory
I have tried recompiling and rerunning JModelica in many ways.
I have set LD_LIBRARY_PATH appropriately.
I have run ldconfig.
Nothing seems to help.
How can I fix this?
As of revision 7885 of the JModelica trunk, JModelica egregiously violates the Principle of Least Astonishment.
JModelica suggest you use the script /usr/local/jmodelica/bin/jm_python.sh or what have you to run your JModelica code.
Digging inside of this script, we find the following line:
LD_LIBRARY_PATH=:/root/Ipopt-3.12.4/build/lib/:/usr/local/jmodelica/ThirdParty/Sundials/lib:/usr/local/jmodelica/ThirdParty/CasADi/lib \
Note that LD_LIBRARY_PATH is being overwritten, so it does not matter what you set it as!
Changing this line to:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/Ipopt-3.12.4/build/lib/:/usr/local/jmodelica/ThirdParty/Sundials/lib:/usr/local/jmodelica/ThirdParty/CasADi/lib \
resolves the issues.
This was brought up as a user patch on JModelica's site here on 2015-05-03. A patch was submitted on circa Revision 8185 to fix the issue, but it continued to crop up for me on trunk after that.
I'm trying to use code::blocks debugger. I followed this basic tutorial on how to do it. I also watched two videos on you tube. I was actually trying it on a bigger file which had its declaration & implementation in separate files (one was header file tree.h, one had its implementation tree.cpp & the last one had implementation_tree.cpp main function to check the header file) but it didn't work so I tried it on a very simple program. But now debugger shows this error
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: F:\Coding\test\test\
Adding source dir: F:\Coding\test\test\
Adding file: F:\Coding\test\test\bin\Debug\test.exe
Changing directory to: F:/Coding/test/test/.
Set variable: PATH=.;C:\Program Files\CodeBlocks\bin;C:\Program Files\CodeBlocks;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0
[debug]Command-line: F:\Coding\Data Structures\tree.h -nx -fullname -quiet -args F:/Coding/test/test/bin/Debug/test.exe
[debug]Working dir : F:\Coding\test\test
Starting debugger: F:\Coding\Data Structures\tree.h -nx -fullname -quiet -args F:/Coding/test/test/bin/Debug/test.exe
failed
Whatever is in this line [debug]Command-line: is the address of my tree.h file which I was trying to debug earlier. But now I've removed all the breakpoints & everything related to that file from Code::Blocks & even changed that file's location but it still shows that same address in Starting debugger:. I've also rebuilt my test program after deleting everything related to it several times but I'm still getting the same error. I'm using GDB.
I'm so sorry if this question sounds very silly as I'm trying this for the first time & not being able to proceed through any tutorials or any other forum or anything else. I've also seen other related questions on stackoverflow but none of them works for me. So, please help. Thanks.
Settings -> Compiler -> Search Directories.. Delete all paths from there.
I'm using ant.bat (in Ant 1.7.1) to build the all target in a build.xml file, on Windows 2003 Server. (I've substituted "xxx" in the error message for the project name in that file.)
It builds successfully, but then ends with:
2009-06-10 17:26:03 | all:
2009-06-10 17:26:03 |
2009-06-10 17:26:03 | BUILD FAILED
2009-06-10 17:26:03 | Target "1" does not exist in the project "xxx".
...and returns with a non-zero error code.
I've searched build.xml unsuccessfully for anything that might lead to this error. (There is no target "1", of course, nor any dependencies that might resolve "1".)
I'm hoping someone out there might recall seeing this. I don't expect anyone to debug the XML for me, but a Google search turned up http://simile.mit.edu/mail/ReadMsg?listId=9&msgId=2735, which contains "I found an email thread on this problem and will
retry.". I wish I could find that thread.
Update - here's the command-line:
D:/build/toolchain/noarch/ant-1.7.1/bin/ant.bat all -DBRANCH_NAME="main" -DBUILD_NUMBER="66675" -DCHANGE_NUMBER="1061789" -DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1 -DGOBUILD_VICLIB_ROOT=d:/build/ob/bora-66675/compcache//viclib/ob-65655/windows -DGOBUILD_VIMBASE_ROOT=d:/build/ob/bora-66675/compcache//vimbase/ob-64494/windows -DOBJDIR="beta" -DPRODUCT_BUILD_NUMBER="82" -DPUBLISH_DIR="d:/build/ob/bora-66675/publish" -DRELTYPE="beta" -DREMOTE_COPY_SCRIPT="D:/build/toolchain/win32/python-2.5/python.exe D:/build/gobuild/script/gobuildc.py bora-66675"'
Hopefully it's of some help.
Do you have any targets that depend on "1"? Perhaps due to a typo?
<target name="SomeTarget" depends="1">
....
</target>
Update: You explained (paraphrased) that the error message was a result of the (partial) command-line
-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1
Although there's a space between those two define statements, it's being treated like this:
-DGOBUILD_AUTO_COMPONENTS=-DGOBUILD_OFFICIAL_BUILD=1
because something is expected to follow '='. And it appears that the second '=' is being treated as a whitespace, perhaps because ANT is confused. I would not expect that. The correct way to do what you want to do is:
-DGOBUILD_AUTO_COMPONENTS="" -DGOBUILD_OFFICIAL_BUILD=1
That way, something follows the equals sign and ANT won't get confused.
could you add the commandline you are using. it could be that ant agrees with you that there is no target '1' but that it believes you are passing one in.
This posting helped me resolve this error and wanted to share my version of the problem.
Target "listener" does not exist in the project "null".
ANT will use an environment variable ANT_ARGS if it is set. I was using the -listener option and set this option in my Windows envvar, ANT_ARGS. When I pasted the options into the Env Var:
-listener org.apache.tools.ant.listener.Log4jListener -lib D:\apache-ant-1.7.1\lib
I was missing the 'minus' sign in front of the 'listener' option.
This is similar to the problem above, but was hidden by the fact that I used the envvar ANT_ARGS.
Ya goose :-) You changed the project to "xxx" in the heading but left it as "vireporting" in the error output.
So the cat's out of the bag. You may as well make our life easier and post the XML since our ability to help you (psychic debugging) is greatly limited. If you want, sanitize the XML you post (better than you sanitized the original, hopefully).
And your comment ('There is no target "1"') makes sense since that's what ant is telling you. What you may have done is inadvertently created a dependency on that non-existent target.
It turns out this error message is the result of "-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1" in the command-line. I guess having nothing after the '=' in that -D option confuses Ant. (As an experiment, I changed "-DGOBUILD_OFFICIAL_BUILD=1" to "-DGOBUILD_OFFICIAL_BUILD=2" in this programmatically-generated command-line and the error message changed to "Target "2" does not exist in the project "xxx".")
Removing "-DGOBUILD_AUTO_COMPONENTS=" eliminated the build failure.
If someone can clearly explain why Ant emits such a strange error message in this case (or perhaps why it's not strange if one looks at it correctly), I'll accept your answer.