Versioned dylib .so symlinks don't make it to runfiles

[mfarrugi]

It looks like https://github.com/bazelbuild/rules_rust/blob/master/rust/rust.bzl#L342 is not quite right, and we need to fish out the .so.1.0 links from the binary.

@damienmg is there a straight forward way to getthe symlink paths? If not I will spend some time spelunking in whatever the cc_* rules currently expose.

[damienmg]

Sorry, what is the issue exactly?

[mfarrugi]

>> ldd bazel-bin/rust/examples/hello/hello_http 
        linux-vdso.so.1 =>  (0x00007ffc877b1000)
        libcrypto-opt.so.1.0.0 => not found
        libssl-opt.so.1.0.0 => not found
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9e98b0d000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9e98905000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9e986e9000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9e984d3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9e98146000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9e99129000)
        
>> tree bazel-bin/_solib_k8/ 
bazel-bin/_solib_k8
└── _U@openssl_S_S_Clib___Uexternal_Sopenssl_Slib
   ├── libcrypto.so -> /home/marco/.cache/bazel/_bazel_marco/7e11b588968d46a3fb2589ae35c89c95/external/openssl/lib/libcrypto.so
   └── libssl.so -> /home/marco/.cache/bazel/_bazel_marco/7e11b588968d46a3fb2589ae35c89c95/external/openssl/lib/libssl.so

The execroot and runfiles tree are missing the versioned symlinks 'libcrypto-opt.so.1.0.0' and 'libssl-opt.so.1.0.0' that the binary is looking for. It looks like the cc_* rules don't create the symlinks in the runfiles tree if they are not depended on.

[damienmg]

How are those symlink created in the first place, where is that example coming from?

Also pulling in @mhlopko who might knows something, is still in the Bazel team and in charge of C++ rules and a rust enthusiast :)

[mfarrugi]

iiuc the cc_* rules layout the _solib tree; the example's dependency chain looks like this:

cc_library( imports /opt/openssl ) <- rust_library ( openssl-sys ) <- ... <- rust_binary( hello_http )

[hlopko]

Is the problem that C++ rules don't expose versioned .so in their runfiles, or that rust rust rules don't do so?

[mfarrugi]

I believe it's the latter, because rust rules are not looking up the outputs in a robust way ( https://github.com/bazelbuild/rules_rust/blob/master/rust/rust.bzl#L145).

…

On Mon, Jun 4, 2018, 02:57 Marcel Hlopko ***@***.***> wrote: Is the problem that C++ rules don't expose versioned .so in their runfiles, or that rust rust rules don't do so? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACLjeKk7fL0ovAYNPSJpWbuW459_eXIwks5t5NpHgaJpZM4UW3Il> .

[mfarrugi]

There's also other fun dylib naming schemes that we don't handle, eg. llvm's

BugpointPasses.so
libclang.so.4 	
libLTO.so.4 	
LLVMHello.so 	

@mhlopko Is this something that rules_rust should always handle, or something that we would be able to depend on from cc sandwich?

[djmarcin]

I also ran into this recently and sent #513 which I think might fix this -- at least it did for me.