Hello Michael,
Thank you for your reply and sorry for the late response.
To be precise my problem was not, strictly speaking, in the compilation
phase, but instead during the linking stage. As I said in the first
mail what happened was that during the generation of libuhd.so the
command used for linking was trying to use libboost*.a.
My solution is quite simple (quick and dirty I should say), I commented
the line
set(Boost_USE_STATIC_LIBS ${ENABLE_STATIC_LIBS})
in host/cmake/Modules/UHDBoost.cmake and commented the call to dlopen in
host/lib/utils/load_modules.cpp. This way all the compilation process
(linking included) goes smootly, at least in my case.
For what concerns the compilation of a custom application that link
against libuhd.a I just used as "inspiration" the CMakeLists.txt file in
host/examples/init_usrp/. I used the variables
${UHD_STATIC_LIB_LINK_FLAG} and ${UHD_STATIC_LIB_DEPS}.
Thank you for your attention, have a good day
Paolo
On 5/13/21 3:40 PM, Michael Dickens wrote:
Hi Paolo - Sounds like you've had some success getting the static
build working under UHD 3.15 for your specific needs. If the details
to get this working are relatively simple then please go ahead and
post them here, and that might be useful for others. If they are
somewhat involved then please just send them to me directly. Either
way: We'll see what we can do to help get them documented and/or
tweaked in UHD 3.15-LTS. - MLD
On Thu, May 13, 2021 at 8:36 AM Paolo Palana <p.pal...@itsystems.it
<mailto:p.pal...@itsystems.it>> wrote:
The problem was, of course, mine
I had wrong line in my cmake. With libuhd 3.10.3 I had the line
set(MY_STATIC_LIB -Wl,--whole-archive ${UHD_STATIC}
-Wl,--no-whole-archive ${DL_STATIC})
while for libuhd 3.15
set(MY_STATIC_LIB -Wl,--whole-archive ${UHD_STATIC}
-Wl,-no-whole-archive)
However I have proposal for a fix for the CMkeFiles of libuhd
3.15. I don't know if it is the case to discuss it here, or
directly with developer.
If developer or a moderator will read this mail, please let me know.
Thank you in advance
Paolo
On 5/12/21 10:38 AM, Paolo Palana wrote:
Hi to all the mailing list.
I'm trying to compile libuhd-3.15 in order to get the static
version of this library, but I've problems. The platform I'm
using in ubuntu 18.04 x86_64
the cmake command I use is: cmake -DENABLE_STATIC_LIBS=ON
-DENABLE_LIBERIO=OFF -DENABLE_USB=OFF -DENABLE_B100=OFF
-DENABLE_B200=OFF -DENABLE_E300=OFF -DENABLE_USRP1=OFF
-DENABLE_USRP2=OFF -DENABLE_N230=OFF -DENABLE_MPMD=OFF
-DENABLE_E320=OFF -DENABLE_OCTOCLOCK=OFF -DENABLE_DPDK=OFF ../
The compilation process seems to be ok, but I get from the linker
the error:
/usr/lib/x86_64-linux-gnu/libboost_filesystem.a(operations.o):
relocation R_X86_64_PC32 against symbol ......
If I run the command VERBOSE=1 make I can see that the linker
command issued to generate of libuhd.so try to link libbost_*.a
files in order to genertate the libuhd.so file. To be plain I'm
not very familiar with this kind of problems, but I think this is
not correct. I did many try and guess to solve the issue and I
found that commenting the line set(Boost_USE_STATIC_LIBS
${ENABLE_STATIC_LIBS}) in cmake/Modules/UHDBoost.cmake seems to
solve the problem, both libuhd.so and libuhd.a are generated.
But now another problem arise, when I compile my static
application I get other link errors like:
usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdl.a(dlerror.o):
In function `dlerror':
(.text+0x1): undefined reference to `__dlerror'
Because the same application is succesfully compiled on the same
system (so system libraries are exactly the same) using libuhd
3.10.3 I think these errors could be related with something wrong
I did in compiling libuhd-3.15. Of course every time I need to
change libuhd version I uninstall (through make uninstall) the
undesired library.
So my question is, what is wrong with libuhd-3.15 or, better,
what I did wrong?
Thank you for your kindness.
Paolo
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
