How to correctly use crate-type in [[example]]?

help
1

I'm having trouble declaring an example in the crate manifest.
The example compiles and works correctly on 'android' and 'linux' targets but I can't declare it in such a way that it is possible to compile and run the example for both operating systems.
To run and compile for target 'linux' I don't even need to declare it, just run the command cargo run --example window.
For the target 'android' I need to declare in the manifest:

[[example]]
name = "window"
crate-type = ["cdylib"]

The problem is that if I declare in the manisfet I can't run the example for the 'linux' target, the compilation happens normally, even if I declare "bin" in crate-type.
The error returned when I try to execute is: error: example target `window` is a library and cannot be executed.
How do I make crate-type work correctly?

2

Cargo examples need to be executables. You could make each example a new crate with it's own Cargo.toml. Then this crate could be a cdylib just as you would when defining a regular consumer of your crate.

3

I don't really understand what and why needs to be a cdylib.

Usually, it would be the lib, and if you need a cdylib for a special platform, then I'd do:

[lib]
"crate-type" = [
    "rlib",  # I am guessing for Linux?
    "cdylib",  # For Android
]

# No need to tweak the `[[example]]` for `window`

That being said, I find it odd to mix rlib and cdylib (if it were staticlib and cdylib it could make sense).

So I am gonna assume that for Android, there is a special runner in charge of using a generated cdylib artifact.

In that case, I'd do:

[[example]]
name = "window"
"crate-type" = [
    "bin",  # The default when not specified. Provided here for linux
    "cdylib",  # To be picked up by the android runner
]

Does this one work?

1 Like
4

It doesn't work, it looks like cargo completely ignores "bin", it always compiled the example as a dynamic library.
I don't understand what's going wrong with cargo.

target/debug/examples/libwindow-c4908d0be9723c3a.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=73b70a90d04d1e1f147737728d9bf2214a368eb2, with debug_info, not stripped
target/debug/examples/libwindow.d:                   ASCII text, with very long lines
target/debug/examples/libwindow.so:                  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=73b70a90d04d1e1f147737728d9bf2214a368eb2, with debug_info, not stripped
target/debug/examples/window-c4908d0be9723c3a.d:     ASCII text

If I remove [[example]] from the manifest it compiles normally, compiling a dynamic library without 'lib' and '.so' in the name.

target/debug/examples/window:                    ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6e34181e1c216cc96dd75eb627c22404f5825e27, for GNU/Linux 3.2.0, with debug_info, not stripped
target/debug/examples/window-80d4e6b28cb3ebcb:   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6e34181e1c216cc96dd75eb627c22404f5825e27, for GNU/Linux 3.2.0, with debug_info, not stripped
target/debug/examples/window-80d4e6b28cb3ebcb.d: ASCII text
target/debug/examples/window.d:                  ASCII text, with very long lines
5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.