EPICS Controls Argonne National Laboratory

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  <20202021  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  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Question about static linking in the EPICS build system
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: "Wlodek, Jakub" <jwlodek at bnl.gov>, "Johnson, Andrew N." <anj at anl.gov>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>
Date: Fri, 14 Aug 2020 22:09:19 +0000
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  <20202021  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  <20202021  2022  2023  2024 
ANJ, 17 Aug 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·