[question] Linking .so dependency for header only package best practice

[Tridacnid]

What's the correct way to specify linkage to a shared object library that's effectively a system lib but isn't in a globally search location like /usr/lib? I have a header only Conan package that wraps a C library installed to /opt/<subdir> and have used self.cpp_info.sharedlinkflags in the past but updating Conan from 1.22.2 to 1.28.1 breaks the build.

• I've read the CONTRIBUTING guide.

[czoido]

Hi @Tridacnid,
Your crash could be related with this: #6780
Could you please try to use self.cpp_info.exelinkflags instead and see if that solves your issue?

[Tridacnid]

That looks like it works correctly for both version of Conan. Thanks! What's the difference? When should I use sharedlinkflags vs exelinkflags?

[Tridacnid]

I'll bump this once to try to get an answer to my question above and then close it in a week. Is my guess that sharedlinkflags and exelinkflags represent the flags that should be used when the conan package is part of a shared object and an executable binary respectively? If that's correct, how come they're separated?

[memsharded]

Hi @Tridacnid

Is my guess that sharedlinkflags and exelinkflags represent the flags that should be used when the conan package is part of a shared object and an executable binary respectively?

Yes, if I understood it correctly, you are right. sharedlinkflags are for consumers building a shared library, while exelinkflags are for consumers building an executable. Some cases the same flag can be applied for both, but they are in fact different things and need to be defined separately. The most important piece to remember is that the information in package_info() defined in self.cpp_info is always information for consumers, the thing they need to use to consume the current package.

If that's correct, how come they're separated?

Not sure what you mean. Please let me know if the above clarifies the issue a bit.

[Tridacnid]

That answers it, thanks!