Указать линкеру искать свежесобранную либу в target/release/deps

Есть несколько способов это сделать, например определить переменную окружения export LIBRARY_PATH или передать аргумент в gcc через файл .cargo/config или еще можно как-то это сделать через build.rs, но я не пробовал.

Мне не понятно зачем тебе вообще все это нужно. Использовать cdylib из кода на расте это же сущий ад, надо будет заново определять все типы, везде будет куча unsafe, легко совершить ошибку и попортить память и т.д. Почему бы не использовать rlib из раста а cdylib из C и других языков.

Например у тебя в прошлом треде есть такой код:
pub extern "C" fn fwod_from_file(fwod_file: &str) {
так делать нельзя потому что &str это указатель на слайс а не char*, если написал extern «C» то используй только типы совместимые с кодом на C, в этом случае CStr.

Разумная критика. Услышана и принята к сведению.

Сейчас как раз копаю в сторону build.rs (чтобы сделать максимально юзеро-независимый и портабельный вариант). Если получится - выложу тут пример.

Из Rust cdylib на данный момент используется по той причине, что мне же надо как-то проверять свой говнокод.

Тесты, честно, я никогда не писал. На моей практике встречались ситуации, когда надо было тестировать отдельно приватные методы классов, которые, зараза, приватные и просто так не будут вызваны из кода, а объект в целом проверять нет смысла по многим причинам. Может, осилю доки Rust и сделаю тесты и бенчмарки как положено.

Когда же удастся сделать рабочую либу - можно будет для Rust собрать lib/dylib/rlib и сделать просто:

extern crate fwod;

надо было тестировать отдельно приватные методы классов, которые, зараза, приватные и просто так не будут вызваны из кода, а объект в целом проверять нет смысла по многим причинам. Может, осилю доки Rust и сделаю тесты и бенчмарки как положено.

Дык, там нечего осиливать. Тесты объявленные внутри модуля имеют доступ ко всем необходимым приватным потрохам.

Касательно совместимости с C: очень интересно и реквестирую тык в доки, если можно, так как указания прямого соответствия типам C я нигде не заметил.

https://doc.rust-lang.org/std/ffi/index.html

Ну и типы из libc.

Касательно совместимости с C: очень интересно и реквестирую тык в доки

В книге есть глава где много инфы на эту тему: https://doc.rust-lang.org/book/ffi.html

Из Rust cdylib на данный момент используется по той причине, что мне же надо как-то проверять свой говнокод.

Это не самый лучший вариант, например тот код с &str будет замечательно работать в приложении на Rust потому что компилятор знает что такое &str и что с ним делать, и ты бы не заметил что тут есть проблема. А компилятор C или другого языка не знает ничего про str и vec, и ты бы сразу заметил что ничего не работает. Поэтому я бы рекомендовал тестировать C интерфейсы из программы на C.

Да, я хочу написать портабельную либу, чтобы с ней могли линковаться все.

Мне кажется что ты пытаешься решить две задачи одновременно:
1) написать библиотеку с интересующим тебя функционалом
2) сделать так чтобы твою библиотеку можно было использовать из всех языков

Обе задачи сложны сами по себе и мне кажется если пытаться делать все сразу то это только увеличит сложность на порядок и результат получится не очень красивый.
Если бы я делал что-то подобное, я бы разделил библиотеку на две: Сначала сделал обычную rlib с нужным мне функционалом, все протестировал, убедился что она работает как надо, а потом бы написал отдельную cdylib которая импортирует первую rlib и содержит только extern "C" обертки над нужными функциями. Тогда программы на расте будут всегда линковаться с первой rlib и использовать нормальный интерфейс без extern без unsafe без CStr и прочей ерунды, а программы на других языках будут линковаться с cdylib и пользоваться привычным для них интерфейсом. Мне кажется так делают и в C++, сначала пишут нормальную библиотеку с классами наследованием и прочими плюшками, а потом прикручивают сбоку C интерфейс.