rav1e.0.5.0.dylib weird dependency prefixed with lib

[rubu]

Describe the bug More likely that this is an issue with cargo-c (or my misuse of it) not with rav1e but here goes - I was trying to build the C library for rav1e and install it in a custom directory like this: cargo cinstall --release --destdir=/Users/rudolfs/Development/Artifacts/ --prefix= I was setting prefix to nothing to avoid the usr/local structure in the destination directory. The files seem to be produced fine, both static and dynamic library, but otool -L shows that librav1e.0.5.0.dylib depends on lib/librav1e.0.5.0.dylib thus placing the dylib side by side with my binary can't load it (I attached a screenshot with the commands and outputs as well). I though that maybe this comes from the default libdir value so I tried cargo cinstall --release --destdir=/Users/rudolfs/Development/Artifacts/ --prefix= --libdir= but then otool -L shows /librav1e.0.5.0.dylib (note the starting slash. How can I overcome this?

Also, is there some additional dependency missing? The static librav1e.a is 87 mb while the dylib is just 2 mb, is the magic dependency which I'm seeing (but it's not installed to the destination directory) the actual dylib?

To Reproduce Invoke cargo cinstall --release --destdir=/Users/rudolfs/Development/Artifacts/ --prefix= with some meaningful value for --destdir.

Expected behavior A shared library with proper dependencies.

Required Information Toolchain (if is a build problem):

$ cargo --version -> cargo 1.59.0
$ rustc --version -> rustc 1.59.0
$ nasm --version # if on x86_64

Version:

$ rav1e --version

Operating system:

$ uname -a -> Darwin Rudolfss-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000 arm64

[lu-zero]

The default libdir is still lib.

[rubu]

@lu-zero ok, I assumed that, but then can what is the correct way to build a non prefixed binary (with non prefixed I mean that the dependency would be without the libdir or a starting slash)?

[lu-zero]

In general it is not a good idea, you may try passing --libdir= as well and see how it goes.

[rubu]

@lu-zero as I wrote in the bug, and empty libdir added a starting slash, but now I made it work by using cargo cinstall --release --destdir=/Users/rudolfs/Development/Artifacts/ --prefix= --libdir=./, but then again It does not feel proper, I can agree with that.

I could roll with the static lib, i am simply a bit confused about the size differences (2mb for dylib vs 80mb for .a) - is there some kind of magic underneath since otool does not show any extra dependencies. Anyhow closing this, since I now kinda understand the cause, if you can comment on the size difference that would be great.

[lu-zero]

What happens when you strip the library? 80mb sound right with debug symbols on.

[rubu]

Is stripping available via cargo-c? I just did strip -xS -o librav1e.stripped.a librav1e.a z which reduced the size from 80mb to 60mb. There is a lot of weird output while stripping though:

ld: warning: linker symbol '$ld$hide$os10.4$___powitf2' hides a non-existent symbol '___powitf2'
ld: warning: linker symbol '$ld$hide$os10.5$___powitf2' hides a non-existent symbol '___powitf2'
ld: warning: linker symbol '$ld$hide$os10.4$___powixf2' hides a non-existent symbol '___powixf2'
ld: warning: linker symbol '$ld$hide$os10.5$___powixf2' hides a non-existent symbol '___powixf2'
ld: warning: linker symbol '$ld$hide$os10.4$___subvdi3' hides a non-existent symbol '___subvdi3'
ld: warning: linker symbol '$ld$hide$os10.5$___subvdi3' hides a non-existent symbol '___subvdi3'
ld: warning: linker symbol '$ld$hide$os10.4$___subvsi3' hides a non-existent symbol '___subvsi3'
ld: warning: linker symbol '$ld$hide$os10.5$___subvsi3' hides a non-existent symbol '___subvsi3'
ld: warning: linker symbol '$ld$hide$os10.4$___subvti3' hides a non-existent symbol '___subvti3'
ld: warning: linker symbol '$ld$hide$os10.5$___subvti3' hides a non-existent symbol '___subvti3'

a lot of similar messages for a lot of symbols. But I don't think I am doing the stripping right, since if after the stripping I compare nm -gU between the stripped static and the dylib, the dylib only has the the actual API symbols while the static library has tons of symbols.