[CMake] Help: erroneous '-ltbb' getting injected into link command implicitly

[Luis Caro Campos]

Hi,

In my case, I don't think I was ever able to "remove" the "-ltbb" from the
linker statement. However, by doing a target_link_libraries against the
actually file with the pull path, that seemed to do the job and the linker
picked that one instead of the system one. Please note that in my case, I
made sure tbb was not installed by the system packager manager, so "-ltbb"
caused a linker error as it couldn't find what it needed.

I would try one of these 3 things:
target_link_libraries(Mytarget "/path/to/libtbb.so") #full path

link_directories("/path/to/tbblib") #somewhere in the source tree that
affects your target

The third alternative would be to use rpath-link linker argument, and pass
the path to tbb. This would work if the implicit dependency is because of a
dependency expressed in another library you link against.

In the build tree, "ldd" tool on Linux should help you determine whether
your tbb or the system one is picked. On the install tree, depends on the
rpath !


Regards,
Luis


On 13 Oct 2017 15:22, "Chris Green" <greenc at fnal.gov> wrote:



On 10/13/17 3:06 AM, Luis Caro Campos wrote:

Hi Chris,

Are you, by any chance, using (via find_package), another library that may
have been built with tbb support?

We using libraries from another package that depends on them, but I didn't
think we were using CMake mechanisms to find them. Regardless, I've no idea
how to fix it when I do find it. I thought making sure LIBRARY_PATH wasn't
set would do the trick, but apparently not.

I've had the exact same problem you describe with OpenCV, when my own
targets link against the opencv ones.

If you're able to let me know how you solved the problem and stopped CMake
doing the translation, I'd be grateful.

Thanks,

Chris.

Regards,
Luis

On 13 Oct 2017 01:21, "Chris Green" <greenc at fnal.gov> wrote:

> Hi,
>
> Using CMake 3.9.2, I'm trying to ascertain where an instance of '-ltbb' is
> getting injected into the link command line of some of our executables.
> This is bad because we can't find it anywhere in our source (we have a
> config CMake that uses the full path to the library), and the system TBB
> library is being picked up which is wrong (old version compiled with wrong
> compiler to wrong C++ standard). I have verified that we have no explicit
> use of '-ltbb' anywhere, and also that LIBRARY_PATH is not being set in the
> environment. Two questions arise:
>
>    1. How can I trace what is going into the link.txt files, and whence?
>    2. Are there any remaining mechanisms for explicit conversion from
>    X/Y/Z/libQ.so to -lQ that I'm unaware of?
>
> It should be noted as a matter of form that the link.txt contains a
> *whole* lot of stuff that wasn't explicitly put there by the
> target_link_libraries() command, and that turns out to be superfluous.
>
> Any help in this matter would be gratefully received, because too much of
> this is currently a black box to me and I'm lost.
>
> Thanks,
>
> Chris.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171013/320f10e4/attachment-0001.html>