Experimental Physics and
Industrial Control System

1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024	Index	1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: libusb problem
From:	Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To:	Matthew Newville <newville at cars.uchicago.edu>
Cc:	"tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date:	Fri, 24 Jun 2022 12:48:15 +0000

Hi Matt,

> Does

> ldd /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so

> point to that location?

Thanks for the hint, that was the problem! The Makefile that builds libhandel.so needed to have these lines added:

ifeq ($(LINUX_USB_INSTALLED), YES)

handel_SYS_LIBS_Linux += usb

endif

libhandel.so was not being linked with libusb. Now ldd shows this:

epics@chemmat91:~/synApps/support/dxp-R6-0$ ldd lib/linux-x86_64/libhandel.so

linux-vdso.so.1 (0x00007ffcca7ce000)

libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007fcbffe9c000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcbffdb5000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcbffb8d000)

/lib64/ld-linux-x86-64.so.2 (0x00007fcbfff97000)

This error has been around for a long time, because on earlier versions of gcc it is OK for libhandel.so to not be linked with libusb, as long as the final application is linked with libusb.

> /lib/x86_64-linux-gnu/ seems like an unusual place to put libusb.

Actually on Ubuntu (at least versions 20 and 22) /lib/x86_64-linux-gnu/ is where most libraries are. It appears to be equivalent to /lib64 on Centos 7 and 8.

Thanks,

Mark

From: Matt Newville <newville at cars.uchicago.edu>
Sent: Thursday, June 23, 2022 5:46 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: libusb problem

Hi Mark,

/lib/x86_64-linux-gnu/ seems like an unusual place to put libusb.

Does

ldd /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so

point to that location?

Maybe you just need an explicit -L/lib/x86_64-linux-gnu/?

On Thu, Jun 23, 2022 at 5:38 PM Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> wrote:

I should add that another application that uses the new libusb-1.0.x library builds fine:

/usr/bin/g++ -o measCompApp -L/home/epics/synApps/support/measComp-R2-5-1/lib/linux-x86_64 -L/home/epics/synApps/support/asyn-R4-42/lib/linux-x86_64 -L/home/epics/synApps/support/autosave-R5-10-2/lib/linux-x86_64 -L/home/epics/synApps/support/busy-R1-7-3/lib/linux-x86_64 -L/home/epics/synApps/support/calc-R3-7-4/lib/linux-x86_64 -L/home/epics/synApps/support/mca-R7-9/lib/linux-x86_64 -L/home/epics/synApps/support/seq-2-2-9/lib/linux-x86_64 -L/home/epics/synApps/support/sscan-R2-11-5/lib/linux-x86_64 -L/home/epics/synApps/support/std-R3-6-3/lib/linux-x86_64 -L/usr/local/epics/base-R7.0.4.1/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/measComp-R2-5-1/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/asyn-R4-42/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/autosave-R5-10-2/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/busy-R1-7-3/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/calc-R3-7-4/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/mca-R7-9/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/seq-2-2-9/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/sscan-R2-11-5/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/std-R3-6-3/lib/linux-x86_64 -Wl,-rpath,/usr/local/epics/base-R7.0.4.1/lib/linux-x86_64 -rdynamic -m64 measCompApp_registerRecordDeviceDriver.o measCompAppMain.o -lmeasComp -lstd -lbusy -lcalc -lmca -lsscan -lautosave -lasyn -lseq -lpv -ldbRecStd -ldbCore -lca -lCom -lcbw_linux -lmeasCompLinuxDrivers -lhidapi-libusb -lusb-1.0

Mark

From: Mark Rivers
Sent: Thursday, June 23, 2022 5:00 PM
To: tech-talk at aps.anl.gov
Subject: libusb problem

Folks,

We are having a strange problem building the synApps dxp module on a new Ubuntu 22 system.

This is the command that fails:

/usr/bin/g++ -o dxpApp -L/home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64 -L/home/epics/synApps/support/areaDetector-R3-11/ADCore/lib/linux-x86_64 -L/home/epics/synApps/support/areaDetector-R3-11/ADSupport/lib/linux-x86_64 -L/home/epics/synApps/support/asyn-R4-42/lib/linux-x86_64 -L/home/epics/synApps/support/autosave-R5-10-2/lib/linux-x86_64 -L/home/epics/synApps/support/busy-R1-7-3/lib/linux-x86_64 -L/home/epics/synApps/support/calc-R3-7-4/lib/linux-x86_64 -L/home/epics/synApps/support/iocStats-3-1-16/lib/linux-x86_64 -L/home/epics/synApps/support/mca-R7-9/lib/linux-x86_64 -L/home/epics/synApps/support/seq-2-2-9/lib/linux-x86_64 -L/home/epics/synApps/support/sscan-R2-11-5/lib/linux-x86_64 -L/usr/local/epics/base-R7.0.4.1/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/areaDetector-R3-11/ADCore/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/areaDetector-R3-11/ADSupport/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/asyn-R4-42/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/autosave-R5-10-2/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/busy-R1-7-3/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/calc-R3-7-4/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/iocStats-3-1-16/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/mca-R7-9/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/seq-2-2-9/lib/linux-x86_64 -Wl,-rpath,/home/epics/synApps/support/sscan-R2-11-5/lib/linux-x86_64 -Wl,-rpath,/usr/local/epics/base-R7.0.4.1/lib/linux-x86_64 -rdynamic -m64 dxpMain.o dxp_registerRecordDeviceDriver.o -ldxp -lhandel -lmca -lseq -lpv -lNDPlugin -lADBase -lnetCDF -lMagick++ -lcoders -lMagick -ljbig -ljp2 -lbzlib -lpng -lwebp -llcms -lttf -lwmf -lfilters -lnanohttp_stream -ltiff -lxml2 -lNeXus -lhdf5 -lhdf5_hl -lbitshuffle -lblosc -lszip -lzlib -ljpeg -lasyn -lautosave -lbusy -lcalc -ldevIocStats -lsscan -lseq -lpv -ldbRecStd -ldbCore -lca -lCom -lusb -lX11 -lXext

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_open'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_release_interface'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_find_devices'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_set_configuration'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_init'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_bulk_write'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_set_debug'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_reset'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_claim_interface'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_close'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_get_busses'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_find_busses'

/usr/bin/ld: /home/epics/synApps/support/dxp-R6-0/lib/linux-x86_64/libhandel.so: undefined reference to `usb_bulk_read'

It is not finding the usb_* functions. However, the third to last argument in the link command is –lusb.

This code uses the “old” version of libusb, i.e. libusb-0.1.x, not the new libusb-1.0.x.

The libusb-dev package is installed. This is the library file:

epics@chemmat91:~/synApps/support/dxp-R6-0$ ls -l /usr/lib/x86_64-linux-gnu/libusb.so

-rw-r--r-- 1 root root 74 Mar 24 11:20 /usr/lib/x86_64-linux-gnu/libusb.so

That file is a GNU ld script:

epics@chemmat91:~/synApps/support/dxp-R6-0$ more /usr/lib/x86_64-linux-gnu/libusb.so

/* GNU ld script. */

GROUP ( /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4 )

It points to lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4.

This is the output of nm on that file showing symbols starting with usb_. Note that all of the missing symbols in the link command are indeed defined in this file.

epics@chemmat91:~/synApps/support/dxp-R6-0$ nm -D /lib/x86_64-linux-gnu/libusb-0.1.so.4.4.4 | grep usb_

00000000000045b0 T usb_bulk_read

0000000000004590 T usb_bulk_write

000000000000b148 B usb_busses

0000000000003b70 T usb_claim_interface

0000000000005920 T usb_clear_halt

0000000000003a70 T usb_close

0000000000003ea0 T usb_control_msg

000000000000b144 B usb_debug

0000000000003790 T usb_destroy_configuration

0000000000005bc0 T usb_detach_kernel_driver_np

0000000000002be0 T usb_device

0000000000009120 B usb_error_errno

0000000000009140 B usb_error_str

000000000000b140 B usb_error_type

00000000000041c0 T usb_fetch_and_parse_descriptors

0000000000004830 T usb_find_busses

00000000000053e0 T usb_find_devices

0000000000002c00 T usb_free_bus

0000000000003900 T usb_free_dev

0000000000002bf0 T usb_get_busses

0000000000004160 T usb_get_descriptor

00000000000040f0 T usb_get_descriptor_by_endpoint

0000000000005ab0 T usb_get_driver_np

0000000000003fa0 T usb_get_string

0000000000003fd0 T usb_get_string_simple

0000000000005810 T usb_init

00000000000045f0 T usb_interrupt_read

00000000000045d0 T usb_interrupt_write

0000000000003950 T usb_open

00000000000039c0 T usb_os_close

0000000000005140 T usb_os_determine_children

0000000000004610 T usb_os_find_busses

0000000000004a00 T usb_os_find_devices

0000000000005610 T usb_os_init

0000000000003930 T usb_os_open

0000000000002d50 T usb_parse_configuration

0000000000002c70 T usb_parse_descriptor

0000000000003ca0 T usb_release_interface

00000000000059f0 T usb_reset

0000000000005850 T usb_resetep

0000000000003d70 T usb_set_altinterface

0000000000003aa0 T usb_set_configuration

0000000000002b80 T usb_set_debug

0000000000002c10 T usb_strerror

Any ideas what could be wrong?

Thanks,

Mark

--Matt Newville <newville at cars.uchicago.edu> 630-327-7411

References:: libusb problem Mark Rivers via Tech-talk; RE: libusb problem Mark Rivers via Tech-talk; Re: libusb problem Matt Newville via Tech-talk

Navigate by Date:: Prev: Re: Re: Some Questions With RTEMS 5 in MVME2502 chengsn via Tech-talk; Next: RE: Problem with huge waveforms in EPICS 7 Mark Rivers via Tech-talk; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024
Navigate by Thread:: Prev: Re: libusb problem Matt Newville via Tech-talk; Next: Re: libusb problem Michael Davidsaver via Tech-talk; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024

ANJ, 14 Sep 2022

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System