Use logger in a dynamically loaded shared library

[WiSaGaN]

Since a dynamically loaded shared library is compiled separately from the executable. The linker would need to resolve the logger in the library to the instance in the executable at run-time when we invoke "dlopen".
Having a way to ask dynamic library not allocate but to look for in run-time would make log usable in dynamically loaded library.

[sfackler]

If you compile the main application and the shared library to both be dynamically linked to the log crate, they should work together.

[WiSaGaN]

The shared library is compiled separately. It's used with a "dlopen" in executable.

[sfackler]

I know. Configure both the main program and the shared library to dynamically rather than statically link to their dependencies and the dynamic linker should make everything work when you dlopen the plugin.

[WiSaGaN]

@sfackler say I have executable Foo, and dynamic library Bar, which is loaded by Foo using "dlopen" at run-time. Do you mean I should let Bar link to crate Log dynamically?

[WiSaGaN]

Use cargo rustc -- -C link-args='-rdynamic' to compile the application with logger. ldd will dynamically link the library logger symbol to the application's location at run-time.
Closing this.

[aaeATS]

I stumbled across this thinking its the perfect solution for my issue, but I could not get this to work.

I have a main application that initializes a logger, and then plugins to that application that are compiled as shared libraries and loaded at runtime using the libloading crate. Any logging statements using the macros from within these plugins are not picked up by my logger, even when using the compilation notes above. I'm sorry to bring up this issue years later, but any help would be appreciated. Thanks!

[jlgerber]

I have stumbled across this as well.

[aaeATS]

I have stumbled across this as well.

For what its worth - I switched to using env_logger crate. Then, in both my main application and my dynamically loaded libraries I call env_logger::builder().format_timestamp(None).init(); at the top, and everything seems to log the way I was originally hoping. Feels clunky, but it works for me.

Good luck

[lazytiger]

Just put this file in your application project.

use log::{LevelFilter, Log, Metadata, Record};

#[repr(C)]
pub struct LogParam {
    pub enabled: extern "C" fn(&Metadata) -> bool,
    pub log: extern "C" fn(&Record),
    pub flush: extern "C" fn(),
    pub level: LevelFilter,
}

struct DLog;

static mut PARAM: Option<LogParam> = None;

pub fn init(param: LogParam) {
    let level = param.level;
    unsafe {
        if PARAM.is_some() {
            eprint!("log should only init once");
            return;
        }
        PARAM.replace(param);
    }
    if let Err(err) = log::set_logger(&LOGGER).map(|_| log::set_max_level(level)) {
        eprint!("set logger failed:{}", err);
    }
}

fn param() -> &'static LogParam {
    unsafe { PARAM.as_ref().unwrap() }
}

impl Log for DLog {
    fn enabled(&self, metadata: &Metadata) -> bool {
        (param().enabled)(metadata)
    }

    fn log(&self, record: &Record) {
        (param().log)(record)
    }

    fn flush(&self) {
        (param().flush)()
    }
}

static LOGGER: DLog = DLog;

#[no_mangle]
extern "C" fn enabled(meta: &Metadata) -> bool {
    log::logger().enabled(meta)
}

#[no_mangle]
extern "C" fn log(record: &Record) {
    log::logger().log(record)
}

#[no_mangle]
extern "C" fn flush() {
    log::logger().flush()
}

pub fn log_param() -> LogParam {
    LogParam {
        enabled,
        log,
        flush,
        level: log::max_level(),
    }
}

And then write a function like this in your dll project to be called in the application.

#[no_mangle]
extern "C" fn init_logger(param: LogParam) {
    init(param);
}

When the application opens the dll, just call the init_logger in the application domain like this

init_logger(log_param());

log_param function called in the application, so the function points to the application function.
init function called in the dll, but the param given from the application, so they are the same.