Hello Nick Thank you for your answer.
Your suggestion was correct indeed. I want just to add some more details.
Adding the lines
set(MY_LIB_OPT -Wl,--whole-archive libuhd -Wl,--no-whole-archive)
target_link_libraries(myapp ${MY_LIB_OPT} <...the rest of your libs...>)
war the first step, but the compilation process ended with the linker error
/usr/local/lib/libuhd.a(load_modules.cpp.o): In function
`load_module_path(boost::filesystem::path const&)'
load_modules.cpp:(.text+0x45): undefined reference to `dlopen'
Now, from my own experience, this error happen because the proper static
library (in this case libdl.a) is not linked.
A very simple modification to my CMakeLists.txt was
find_library(DL_STATIC NAMES libdl.a)
set(MY_LIB_OPT -Wl,--whole-archive libuhd -Wl,--no-whole-archive
${DL_STATIC})
target_link_libraries(myapp ${MY_LIB_OPT} <...the rest of your libs...>)
But again I had a linker error
/usr/local/lib/libuhd.a(load_modules.cpp.o): In function
`load_module_path(boost::filesystem::path const&)':
load_modules.cpp:(.text+0x45): warning: Using 'dlopen' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libdl.a(dlopen.o):
In function `dlopen':
(.text+0x5): undefined reference to `__dlopen'
The dlopen function is used in lib/utils/load_modules.cpp and if you
look a this file you can see that the load_module functions are all
under ifdef statements, so... why don't try to undefine the macro
HAVE_DLOPEN and see what happen? I did it by commenting in
lib/utils/CMakeLists.txt the proper lines, and it worked.
I tried the same application using both libuhd.so and libuhd.a;
I perfectly understand that this is not a solution, but only a very
quick and dirt hack, moreover this hack will not work as soon as you
application require loading modules at runtime, however I like to share
these considerations with you hoping that they will be useful to someone
else.
Have a good day
On 17/04/19 19:57, Nick Foster wrote:
> I suspect the same solution I gave a couple weeks ago will work here:
>
> set(MY_LIB_OPT -Wl,--whole-archive libuhd -Wl,--no-whole-archive)
> target_link_libraries(myapp ${MY_LIB_OPT} <...the rest of your libs...>)
>
> On Wed, Apr 17, 2019 at 3:02 AM Paolo Palana via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi to all the mailing list.
>
> I've a question about the correct way to use a static version of
> libuhd
> (namely libuhd.a)
>
> For experimental reason I need a way to build an executable of
> mine that
> "embed" a specific version of libuhd. I enabled (throutg
> -DENABLE_STATIC_LIBS=ON) the compilation of the static library and
> I get
> the libuhd.a file.
>
> After that I modified my CMakeLists.txt to link against libuhd.a. The
> compilation and link process goes smooth. So far so good.
>
> The problem arise when I execute the program. No radio (x310 in my
> case)
> is found. I traced the problem.
>
> The shared version of libuhd (libuhd.so) has a init function (that
> should be register_x300_device, defined in x300_impl.cpp). that is
> called before main This function is no longer called when I compile
> using libuhd.a, may be because there is no the dynamic loader
> involved.
>
> The question is. Can I call it from my code? And if yes how? I tried
> different ways, but no success.
>
> Thank you for your attention.
>
> My version is 003-010-003-000.
>
> Paolo
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
