[question] packaging C library - linking failing on a project that tries to use it
See original GitHub issueHello,
I am trying to build an external C
library and I followed the various guides. Specifically:
https://docs.conan.io/en/latest/howtos/makefiles.html
The library in question is https://github.com/fanf2/hg64
my conanfile is the following:
from conans import ConanFile, AutoToolsBuildEnvironment
from conans import tools
class Hg64(ConanFile):
name = "hg64"
version = "1.0.0"
description = "A sketches histogram library."
topics = ("performance", "histograms", "quantiles")
homepage = "https://github.com/fanf2/hg64"
license = "SPDX"
settings = "os", "arch", "compiler", "build_type"
_source_subfolder = "source_subfolder"
def export_sources(self):
for patch in self.conan_data.get("patches", {}).get(self.version, []):
if "patch_file" in patch:
patch_file = patch["patch_file"]
self.copy(patch_file)
def source(self):
tools.get(**self.conan_data["sources"][self.version], destination=self._source_subfolder, strip_root=True)
for patch in self.conan_data.get("patches", {}).get(self.version, []):
if "patch_file" in patch:
print(f"patching patch_file: {patch['patch_file']}")
tools.patch(**patch, base_path=self._source_subfolder)
def build(self):
with tools.chdir("source_subfolder"):
atools = AutoToolsBuildEnvironment(self)
atools.make()
self.run("ar -rcs libhg64.a random.o hg64.o")
def package(self):
self.copy("*.h", dst="include", src="source_subfolder")
self.copy("*.a", dst="lib")
def package_info(self):
self.cpp_info.includedirs = ["include"]
I build it as follows:
conan create gsr/hg64/conanfile.py company/master -pr:b=default -pr:h=default -s "&:build_type=Release"
and it creates the package successfully. If I look at the folder where it installed it, I see what I am expecting:
dabe@af41c569972b:~/conan/conan-packages/recipes (hg64)$ ll /home/dabe/.conan/data/hg64/1.0.0/_/_/package/7ad4b4ec31d9148d733986b5f567502885e20657/include/
total 16
-rw-r--r-- 1 dabe dabe 1061 Oct 14 17:39 random.h
-rw-r--r-- 1 dabe dabe 3420 Oct 14 17:39 hg64.h
drwxr-xr-x 2 dabe dabe 4096 Oct 14 17:50 .
drwxr-xr-x 4 dabe dabe 4096 Oct 14 17:50 ..
dabe@af41c569972b:~/conan/conan-packages/recipes (hg64)$ ll /home/dabe/.conan/data/hg64/1.0.0/_/_/package/7ad4b4ec31d9148d733986b5f567502885e20657/lib/
total 112
-rw-r--r-- 1 dabe dabe 103214 Oct 14 17:50 libhg64.a
drwxr-xr-x 4 dabe dabe 4096 Oct 14 17:50 ..
drwxr-xr-x 2 dabe dabe 4096 Oct 14 17:50 .
Now the real problem is that when I try to use it from another project, I am able to find the headers, but the library doesn’t link.
I use it like this on another project:
conan install .. company/master --profile=company-default -s '&:build_type=Debug'
The error is pretty self explanatory:
ld.lld: error: undefined symbol: hg64_destroy(hg64*)
and if I look at the generated compilation line, I see no mention of my library.
In my Cmake I use it as:
find_package(hg64 REQUIRED)
SET(TARGET_LINK_LIBS
hg64::hg64
Cmake itself runs fine, so I expect that the generated files in the generator folder might not be correct. I am sure it might be a very small mistake, some expert eye could find quickly.
if I describe the package I have:
dabe@af41c569972b:~/gsr/conan/conan-packages/recipes (hg64)$ conan search hg64/1.0.0@company/master
Existing packages for recipe hg64/1.0.0@company/master:
Package_ID: 7ad4b4ec31d9148d733986b5f567502885e20657
[settings]
arch: x86_64
build_type: Release
compiler: gcc
compiler.libcxx: libstdc++11
compiler.version: 10.3
os: Linux
Outdated from recipe: False
which seems a bit light
Is there anything odd in my recipe?
Thank you in advance
- [ X ] I’ve read the CONTRIBUTING guide.
Issue Analytics
- State:
- Created a year ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
Happy to hear that! Then I am closing this ticket, don’t hesitate to open new ones for any further questions.
thank you @memsharded very helpful advice. It turns out my problem wasn’t really related to conan. My library is a
C
library and although I managed to package it correctly after your suggestions, I was not including it properly fromC++
fixed the problem. Thanks to your suggestion I will definitely include a test package as well.