On Tue, Mar 10, 2020 at 9:28 AM Willem Jan Withagen <w...@digiware.nl> wrote: > >> problem that libblock_rbd.so is stripped in such a way that > >> the symbol I need is removed. > > > So either I'm doing it the wrong way, like special options on the > > symbols oid. > > > However, I think there's something wrong with your > > library, too. The library should be usable even if it's stripped.
Yes, strip only removes local symbols (.symtab), not exported ones (.dynsym). > I checked with objdump, and the symbol that I need is definitly not > present in the stripped version. How are you defining the symbol intended for export? Is the symbol a function or data? Does the compiler flag -fvisibility=hidden get used? Which symbol is missing and what are the symptoms? > And it does not really matter if I declare it static or not. Not declaring it "static" is necessary, if not sufficient. Looking at your code on github, here are some issues: * In block_if.h, you define an object blocklocal_backend. This is a header, and every compilation unit that pulls in the header will get its own copy of blocklocal_backend. You probably want 'extern block_backend_t blocklocal_backend;' instead. * You SET_DECLARE block_backend_set in block_if.c, but I think it needs to be in block_if.h. * There is some weirdness around linker sets being removed by the linker if they are empty, so you may want to add blockbackend_local to the linker set in the main program. (It's unclear to me why blockbackend_local is treated specially regardless.) However, I'm not quite sure why DATA_SET() in block_rbd.c is not creating __start_set_block_backend_set / __stop_set_block_backend_set exported symbols. As Alan asked, please provide 'nm -D foo.so'. Best, Conrad _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
