Open AlexisTM opened 3 years ago
Would this be due to an "old cmake version"?
It's unclear. The version of cmake that is in Ubuntu Focal is 3.16, so we don't regularly test with something older than that. If you build with a newer CMake, does the issue go away?
This is built on 18.04 as required due to some Nvidia dependencies. At the moment, we do not have the ability to update the cmake version due to some other libraries failing with newer cmake versions.
Ah, I think I see what is going on. The libcurl_vendor
package will only build something if it can't find the 'curl' system library (on Ubuntu 18.04, that would be libcurl4-openssl-dev
. Since we always have that installed on our local machines and CI, we never attempt to build libcurl_vendor
on Linux. I suspect if you install libcurl4-openssl-dev
, the problem will go away.
I will try that! [It is built in a docker and it is very likely for libcurl4 not to be installed]
@clalancette I confirm that installing libcurl4-openssl-dev
solves the problem.
OK, great. There is likely a bug here, so I'll leave this open. But since we don't see it "in real life", it is going to be low priority.
No issue, I have the workaround at the moment. Thanks for the support!
I'm seeing this error when I build ROS 2 core packages with the cmake arg -DFORCE_BUILD_VENDOR_PKG=ON
. My use case is to build a custom ROS 2 archive to distribute, and so I've turned that flag on to force all vendor packages to build in case users don't have them installed.
Looking into this a little, I guess it has something to do with the system installed version of cmake originally building against a different version or environment, compared to the vendored libcurl. E.g. It's easy to reproduce the error by running cmake
after sourcing a workspace in which libcurl_vendor was built:
$ cmake --version
cmake: /path/to/my/workspace/install/opt/libcurl_vendor/lib/libcurl.so.4: no version information available (required by cmake)
cmake version 3.16.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
I tried building cmake locally, and with it I don't see the "no version information available" errors. Although, it looks like cmake was built without linking against libcurl, so I'm not sure if it's a valid experiment.
@jacobperron On my side, I had the issue when building from source on Ubuntu 18.04 but not on 20.04. On 18.04, libcurl_vendor is built, on 20.04 it uses the system version. So there must be some cmake issues in the package, but I have no clue what it is. 😞
IIUC, the version of libcurl we're building is not compatible with the system installed version, which cmake depends on: https://gitlab.kitware.com/cmake/cmake/-/issues/20872
So, I'm not sure that building libcurl_vendor on systems that cause cmake to dynamically link against libcurl would ever work.
@jacobperron is right; I'm pretty sure the problem is that cmake itself depends on libcurl, and when we try to replace it with the vendored package it gets upset.
Honestly, I think the right solution here may be to stop vendoring libcurl
completely and just get it from the "system" (that would be apt
on Ubuntu/Debian, dnf
on RHEL, chocolatey
? on Windows, and brew
on macOS).
I was about to ask what was/is the original reason for vendoring curl?
This is the commit that added it: https://github.com/ros/resource_retriever/commit/290ff8205bc21e8679a63612988a3641da589f21 .
But it looks like the curl package is available on all of our target platforms. I'm going to give a shot at removing the vendor package completely and see if things still work on Windows, in particular.
I'm removing it locally for my project, since we can rely on the system version. But if we can remove it in general that would be cool.
Hi,
I receive the following warning when compiling ros2 as well as other code using the libcurl_vendor library.
I tried both the foxy branch as well as ros2 branch:
Foxy branch:
Ros2 branch:
CMake version:
Would this be due to an "old cmake version"?