Support linking to system-installed libwebp

[tranzystorekk]

Allow looking for libwebp via pkg-config and then using the system version if available

[NoXF]

there is no plan to support linking the system libwebp from pkg-config.

I think the current approach is more predictable and easy to use.

do you mind mentioning if there is a special need for linking the system libwebp?

[tranzystorekk]

It has been a while so the specific project eludes me for the moment, but packaging for Linux generally prefers supplying the system library than building and static linking a -sys crate version.

EDIT: I think I was packaging https://github.com/woelper/oculante/ and noticed that the final package doesn't dynlink to the provided libwebp

[NoXF]

so sorry for the late reply, I forgot until saw another issue😂

yes, cpp lib often uses lib which the system supplies, and may come with a lot of problems eg. deps version conflict and needing some special install sequence sometimes.

welcome to remind if you meet any problems with using

[yu-re-ka]

This would be useful for distributions packaging rust applications to be able to provide a centralized CVE management.
Now we have to go through each individual package and patch around to fix the CVE.

[NoXF]

yes, it is true. it does indeed be a problem. but in other words, using static links allows people to just update this single lib.

Let me think about it.

[mgorny]

We have a user who can't compile Fractal at all because of how libwebp-sys vendors libwebp:

  = note: /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/net-im/fractal-10_beta/work/fractal-10_beta-build/src/release/deps/fractal-04a900087bc94d70.webp-2d1de37ca81c5340.webp.44d3d419c7eb46ff-cgu.0.rcgu.o.rcgu.o: undefined reference to symbol 'WebPValidateConfig'
          /usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libwebp.so.7: error adding symbols: DSO missing from command line
          collect2: error: ld returned 1 exit status
          
  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)

error: could not compile `fractal` (bin "fractal") due to 1 previous error

My educated guess is that libwebp vendored inside libwebp-sys conflicts with shared libwebp that gtk4 links to. Really, please consider adding support for linking dynamically with system libraries. Besides creating a major security risk, loading two versions of the same library into a single problem is never a good idea.

[NoXF]

Hi @mgorny ,

My educated guess is that libwebp vendored inside libwebp-sys conflicts with shared libwebp that gtk4 links to

I don't think that's what caused it. libwebp-sys compiles to generate static link libraries from the vendor and set the rustc-link-search path to use it. see them in target/release/build/libwebp-sys-*/output and target/release/build/libwebp-sys-*/out.

I'm unaware of any modification system ld path like LD_PKGCONFIG_PATH, it should not affect the existing libwebp. It's not loading two versions to the system, just a dedicated compiled version of the current library, isolated from the system. Yes, it may have some problems when syncing the system‘s libwebp upgrade(another story), but it won't cause the problem you mentioned.

could you provide more information I do not realize or how to reproduce it? or try to test if this branch works
#25

[mgorny]

I haven't hit it myself, gotten a report from user. However, since Gentoo has a hard security policy against vendoring libraries, I don't see a point in trying to get unsupported and disallowed setup to work. My suggestion, however, would be not to name this crate *-sys, given it does not allow using a system library, and the name is misleading to users who may think they're choosing the right dependency.