Libstdc++.so.6 error?

[marekm371]

Hello everyone. Have you ever dealt with this error? Any ideas how to fix it?

ImportError: /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/python3/dist-packages/apt_pkg.cpython-36m-x86_64-linux-gnu.so)

[marcan]

Sounds like you put the Xilinx library path in front of your OS's library path while running Python (e.g. in LD_LIBRARY_PATH). You shouldn't do that. The Xilinx libraries should only be used for the Xilinx tools themselves.

[marekm371]

As far as I see in the so-called documentation, Xilinx toolchain is required for building firmware. I thought that it is a correct way. I decided to miss this step and use the package included in repo.

Anyway I'm facing another problem when running ovctl.py

Traceback (most recent call last): File "./ovctl.py", line 6, in <module> import LibOV File "/home/markos/projects/openvizsla/ov_ftdi/software/host/LibOV.py", line 19, in <module> libov = ctypes.cdll.LoadLibrary(_lpath + "/libov." + _lib_suffix) File "/usr/lib/python3.6/ctypes/__init__.py", line 426, in LoadLibrary return self._dlltype(name) File "/usr/lib/python3.6/ctypes/__init__.py", line 348, in __init__ self._handle = _dlopen(self._name, mode) OSError: /home/markos/projects/openvizsla/ov_ftdi/software/host/libov.so: undefined symbol: libusb_release_interface

I installed libusb-1.0.0-dev and python3-dev, though.

[marcan]

The Xilinx toolchain is required for building the FPGA code, and it ships with its own libraries for its own use. Migen works by calling Xilinx binaries, it does not need nor should never directly interact with the libraries shipped with ISE. Therefore, you should never have LD_LIBRARY_PATH set while calling the build tools. Do you know how the Xilinx lib/lin64 ended up in your library path?

[marcan]

Your second error is probably due to the same exact issue. Run ldd /home/markos/projects/openvizsla/ov_ftdi/software/host/libov.so. If anything xilinx shows up, then you're using Xilinx libraries (probably a libusb they ship) which is probably messing everything up too. As I said, Xilinx libraries are only for use by Xilinx tools, they should never be used for any other software and should never end up in your LD_LIBRARY_PATH when running anything that isn't Xilinx software.

If that's not the issue and you're using your system libusb, then please tell us what libusb version and OS you're using.

[marekm371]

I haven't even set the library path. I noticed there are no errors about Xilinx right now and I got the error raise ValueError("Cannot extract clock domain name from code, need to specify.")when buliding ov3 package but as I mentioned above I had used the package already generated. For now, only the libusb_release_interference is an issue.

[marcan]

Did you run ldd /home/markos/projects/openvizsla/ov_ftdi/software/host/libov.so? Can you post the output?

For the migen issue, use this branch and try again. There have been updates to builds with newer migen recently, but it's not pushed to master yet. Make sure you update your submodules too.

[marekm371]

Output of the ldd libov.so

linux-vdso.so.1 (0x00007fff6b2d6000)
/opt/Xilinx/14.7/usb-driver/libusb-driver.so (0x00007f236011b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f235fd2a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f235fb26000)
libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007f235f91d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f235f6fe000)
libftdi.so.1 => /usr/lib/x86_64-linux-gnu/libftdi.so.1 (0x00007f235f4f6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f236072c000)

[marcan]

As I mentioned, nothing Xilinx should be in there. Somehow 'libusb-driver.so' from Xilinx got linked in, and also libftdi and libusb-0.1. Everything there is wrong; libov.so should only depend on and link against your system's libusb-1.0.so.

It sounds like your system is seriously broken and somehow Xilinx libraries are intruding in software you build. Run this and paste the output:

echo $LD_LIBRARY_PATH
cat /etc/ld.so.conf
cat /etc/ld.so.conf.d/*.conf
pkg-config --cflags libusb-1.0
pkg-config --libs libusb-1.0

Also, what distro and version are you using?

For reference, this is what correct output from ldd libov.so looks like:

$ ldd libov.so 
        linux-vdso.so.1 (0x00007fff8f1a7000)
        libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f6d43c57000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6d4388f000)
        libudev.so.1 => /lib64/libudev.so.1 (0x00007f6d43666000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6d43446000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6d4407b000)

[marekm371]

I am using Ubuntu 18.04 LTS

My outputs

$echo $LD_LIBRARY_PATH - nothing in the output

$cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf`

$ cat /etc/ld.so.conf.d/*.conf

###########################################################################
#                                                                         #
#  digilent-adept-libraries.conf -- Adept Dynamic Loader Configuration    #
#                                                                         #
###########################################################################
#  Author: MTA                                                            #
#  Copyright 2010 Digilent Inc.                                           #
###########################################################################
#  File Description:                                                      #
#                                                                         #
#  This file contains the path of the directory that contains the         #
#  shared libraries that make up Digilent's Adept Runtime on Unix         #
#  systems. The dynamic loader uses this configuration file to locate     #
#  Digilent's shared libraries.                                           #
#                                                                         #
#  Usage:                                                                 #
#                                                                         #
#  Copy this file to "/etc/ld.so.conf.d" and execute "ldconfig" as root.  #
#  This only needs to be done immediately after installation. The         #
#  configuration file is automatically read each time you reboot.         #
#                                                                         #
###########################################################################
#  Revision History:                                                      #
#                                                                         #
#  04/16/2010(MTA): created                                               #
#                                                                         #
###########################################################################

/usr/local/lib64/digilent/adept # Path to 64-bit runtime libraries.
/usr/lib/x86_64-linux-gnu/libfakeroot
# Path to libftd2xx
/usr/local/lib64
# libc default configuration
/usr/local/lib
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
# Legacy biarch compatibility support
/lib32
/usr/lib32
# Legacy biarch compatibility support
/libx32
/usr/libx32

$pkg-config --cflags libusb-1.0 -I/usr/include/libusb-1.0

$pkg-config --libs libusb-1.0 -lusb-1.0

$ldd libov.so

linux-vdso.so.1 (0x00007ffd1cf03000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc6c2f3d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc6c3535000)

[marcan]

How did the output of ldd libov.so change? It makes no sense that there are no USB libraries there now.

With that pkg-config output it makes no sense that you got a libov.so linked against libusb-0.1 before.

I don't know what that digilent stuff is, but it has inserted itself at the top of your system's dynamic library search path. You should check all of the directories /usr/local/lib64/digilent/adept /usr/lib/x86_64-linux-gnu/libfakeroot /usr/local/lib64 /usr/local/lib /usr/local/lib/x86_64-linux-gnu and see what's in there. If there's anything related to libusb-1.0 then that's wrong and should be removed, since you should be using your distro's libusb-1.0.

Please paste the output of doing this in the libov.so directory: rm -f *.o && make clean all && ldd libov.so && readelf -d libov.so

[marekm371]

It wooorks. Finally I got what I wanted. Cleaning has been helpful

markos@markos:~/projects/openvizsla/ov_ftdi/software/host$ ./ovctl.py -h
usage: ovctl.py [-h] [--pkg PKG] [-l] [--verbose] [--config-only]
                {uwrite,uread,report,sdramtest,sniff,debug-stream,ioread,iowrite,led-test,eep-erase,eep-program,sdram_host_read_test,lb-test}
                ...

positional arguments:
  {uwrite,uread,report,sdramtest,sniff,debug-stream,ioread,iowrite,led-test,eep-erase,eep-program,sdram_host_read_test,lb-test}

optional arguments:
  -h, --help            show this help message and exit
  --pkg PKG, -p PKG
  -l, --load
  --verbose, -v
  --config-only, -C

But when I try to do a report I get somethinh like this

markos@markos:~/projects/openvizsla/ov_ftdi/software/host$ ./ovctl.py report
Traceback (most recent call last):
  File "./ovctl.py", line 524, in <module>
    main()
  File "./ovctl.py", line 477, in main
    dev = LibOV.OVDevice(mapfile=args.pkg.open('map.txt', 'r'), verbose=args.verbose)
AttributeError: 'NoneType' object has no attribute 'open'

[marcan]

You need -p ov3.fwpkg to tell it to use the provided firmware package.

Edit: just pushed a fix for ovctl.py to default to a sane path (same directory as the script), since crashing without a path is not useful.

[marekm371]

Ok, I think that everything works ok. Thank you @marcan for your help and time.