Hi Jakub,
I think I see your problem.
In your IOC application Makefile you are not linking with the usb library. That works OK when you are linking with libuvc.so because that shareable library itself is linked with libusb.so.
But when you build statically and link with libuvc.a it will not automatically link with libusb.so. So in your IOC application Makefile you need to include
$(PROD_NAME)_SYS_LIBS += usb
Mark
________________________________
From: Wlodek, Jakub <jwlodek at bnl.gov>
Sent: Friday, August 14, 2020 4:59 PM
To: Johnson, Andrew N.; Mark Rivers
Cc: EPICS tech-talk
Subject: Re: Question about static linking in the EPICS build system
Hi Mark, Andrew,
The libuvc.a and .so files are generated by the install-libuvc.sh script in the uvcSupport directory. The libraries are copied into os/HOST_ARCH and then installed to the lib directory at the top level of the driver by the Makefile in that directory. As far as I know that directory should be included by the build system by default. Whether or not I specify SYS_LIBS or just LIBS I see the library appearing in the link phase, I just get that missing reference error if I'm using the non SYS_LIBS link. I did some messing around with the build of the vendor library as well but haven't looked too much into it.
The uvc library cmake uses pkgconfig to link against libusb and libjpeg, so I was wondering if there was some incompatibilities in that it could be linking something dynamically when constructing libuvc.a?
Thanks for the quick reply,
Jakub
________________________________
From: Johnson, Andrew N. <anj at anl.gov>
Sent: Friday, August 14, 2020 5:32:14 PM
To: Rivers, Mark L. <rivers at cars.uchicago.edu>
Cc: Wlodek, Jakub <jwlodek at bnl.gov>; EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Question about static linking in the EPICS build system
Hi Jakub,
To expand on Mark’s reply a little, if you do have a libuvc.a file elsewhere, you should be able to use this in your Makefile to link with it:
$(PROD_NAME)_LIBS += uvc
uvc_DIR = /path/to/the/library/directory
Note that when building static binaries the order of the entries in your _LIBS variable is important as the linker usually makes just one pass through the list in the order that the libraries appear in that variable.
- Andrew
On Aug 14, 2020, at 4:17 PM, Mark Rivers via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>> wrote:
Hi Jakub,
At first, I used $(PROD_NAME)_SYS_LIBS to link to the support library I used for communicating with the device,
but I would like to change this to $(PROD_NAME)_LIBS since it would be my understanding that this would mean that the driver application
could be built entirely statically, making it more portable since then the support library wouldn't have to be installed and in the system path
during runtime.
I see from the ADUVC repository on Github that the name of that support library is uvc, but I don't see a libuvc.so or libuvc.a file as part of the repository. Those must be elsewhere on your system? Is that support library provided in both shareable library (.so) and static (.a) versions? If it is only provided in .so form then you cannot include it in your application binary. If it is provided as a .a file then you can include it in your binary when you build statically.
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov>> on behalf of Wlodek, Jakub via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
Sent: Friday, August 14, 2020 3:13 PM
To: tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>
Subject: Question about static linking in the EPICS build system
Hi all,
I have been working for some time on allowing fully static linking of an areaDetector driver I wrote some time ago:
https://github.com/areaDetector/ADUVC/tree/R1-4
At first, I used $(PROD_NAME)_SYS_LIBS to link to the support library I used for communicating with the device, but
I would like to change this to $(PROD_NAME)_LIBS since it would be my understanding that this would mean that the driver application
could be built entirely statically, making it more portable since then the support library wouldn't have to be installed and in the system path
during runtime.
When using SYS_LIBS, the driver library and IOC application build without issue, however, when I change to just LIBS, the library still
compiles OK, but I get many undefined reference errors when compiling the App:
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(ctrl-gen.c.o): In function `uvc_get_scanning_mode':
ctrl-gen.c:(.text+0x5b): undefined reference to `libusb_control_transfer'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(ctrl-gen.c.o): In function `uvc_set_scanning_mode':
ctrl-gen.c:(.text+0xea): undefined reference to `libusb_control_transfer'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(ctrl-gen.c.o): In function `uvc_get_ae_mode':
ctrl-gen.c:(.text+0x17b): undefined reference to `libusb_control_transfer'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(ctrl-gen.c.o): In function `uvc_set_ae_mode':
ctrl-gen.c:(.text+0x20a): undefined reference to `libusb_control_transfer'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(ctrl-gen.c.o): In function `uvc_get_ae_priority':
ctrl-gen.c:(.text+0x29b): undefined reference to `libusb_control_transfer'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(ctrl-gen.c.o):ctrl-gen.c:(.text+0x32a): more undefined references to `libusb_control_transfer' follow
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(device.c.o): In function `uvc_free_device_info':
device.c:(.text+0x4c6): undefined reference to `libusb_free_config_descriptor'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(device.c.o): In function `uvc_get_device_descriptor':
device.c:(.text+0x58d): undefined reference to `libusb_get_device_descriptor'
device.c:(.text+0x5f1): undefined reference to `libusb_open'
device.c:(.text+0x618): undefined reference to `libusb_get_string_descriptor_ascii'
device.c:(.text+0x640): undefined reference to `libusb_get_string_descriptor_ascii'
device.c:(.text+0x668): undefined reference to `libusb_get_string_descriptor_ascii'
device.c:(.text+0x683): undefined reference to `libusb_close'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(device.c.o): In function `uvc_get_device_list':
device.c:(.text+0x711): undefined reference to `libusb_get_device_list'
device.c:(.text+0x769): undefined reference to `libusb_get_config_descriptor'
device.c:(.text+0x77d): undefined reference to `libusb_get_device_descriptor'
device.c:(.text+0x81c): undefined reference to `libusb_free_config_descriptor'
device.c:(.text+0x83c): undefined reference to `libusb_free_device_list'
device.c:(.text+0x969): undefined reference to `libusb_free_config_descriptor'
device.c:(.text+0x996): undefined reference to `libusb_ref_device'
/epics/src/support/areaDetector/ADUVC/lib/linux-x86_64/libuvc.a(device.c.o): In function `uvc_find_device':
device.c:(.text+0xac2): undefined reference to `libusb_get_device_descriptor'
device.c:(.text+0xb09): undefined reference to `libusb_unref_device'
device.c:(.text+0xb51): undefined reference to `libusb_open
...
The support library in use depends on libusb and libjpeg, both of which are found during the cmake build for said library. It is built both statically and dynamically.
I ran nm on the static library, and I did see the libusb functrions listed:
U _GLOBAL_OFFSET_TABLE_
0000000000000000 d isight_tag.6062
U libusb_alloc_transfer
U libusb_cancel_transfer
U libusb_control_transfer
U libusb_free_ss_endpoint_companion_descriptor
U libusb_free_transfer
U libusb_get_ss_endpoint_companion_descriptor
U libusb_set_interface_alt_setting
U libusb_submit_transfer
...
It is clear to me that this is some error I have in the linking process/configuration, but I can't seem to figure out what
specifically it could be. I have tried adding libusb to the LIBS for the ioc application (copying the statically compiled library to
ADUVC/lib/linux-x86_64), but this gave me the same error, and the same when I added libusb to SYS_LIBS.
I have had similar issues when trying to get a static build of OpenCV to link against an areaDetector application -
it works fine when building the intermediate libraries (plugins, driver lib), but when building the final IOC application I got undefined reference errors.
If anyone has an idea on what I should change, it would be much appreciated.
Thanks!
Jakub Wlodek
--
Complexity comes for free, simplicity you have to work for.
- Replies:
- Re: Question about static linking in the EPICS build system Wlodek, Jakub via Tech-talk
- References:
- Question about static linking in the EPICS build system Wlodek, Jakub via Tech-talk
- Re: Question about static linking in the EPICS build system Mark Rivers via Tech-talk
- Re: Question about static linking in the EPICS build system Johnson, Andrew N. via Tech-talk
- Re: Question about static linking in the EPICS build system Wlodek, Jakub via Tech-talk
- Navigate by Date:
- Prev:
Re: Question about static linking in the EPICS build system Wlodek, Jakub via Tech-talk
- Next:
Re: cannot read epics archive(d) data with CS-studio 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
- Navigate by Thread:
- Prev:
Re: Question about static linking in the EPICS build system Wlodek, Jakub via Tech-talk
- Next:
Re: Question about static linking in the EPICS build system Wlodek, Jakub 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
|