We have an application that calls boost::dll::symbol_location(). On windows, the returned path looks like \\?\C:\path-to-the-binary-object-holding-the-symbol. We don't see anything like that on linux or macOS. My knowledge of Windows is quite limited -- does this "\?" indicate an error of some kind?

We also have not seen this prefix in earler boost versions. I think we previously were using 1.66, but moved to 1.71 recently.

boost\dll\detail\windows\path_from_handle.hpp

        boost::detail::winapi::GetModuleFileNameW(handle, path_hldr, 
            DEFAULT_PATH_SIZE_);
        ec = last_error_code();
        if (!ec) {
            return boost::filesystem::path(path_hldr);
        }

The problem here is that code doesn't analyze return code. If GetLastError() was dirty before a call this code will fail even if GetModuleFileNameW() will success. Yes, on success, GetModuleFileNameW() doesn't reset last error to ERROR_SUCCESS.

Hello!

I make a so in ubuntu, the so call a python file (C++ call python) with python-C api ,like:
Py_Initialize();
PyRun_SimpleString("import sys");
PyRun_SimpleString("sys.path.append('.')");
PyImport_ImportModule("xxx");
.....
Py_Finalize();)
It's OK.

But when use boost::dll::import_alias() load the so, error occurs in the line "PyImport_ImportModule("xxx");", in the xxx.py, the import lines like "import open3d" occur "ImportError: _ctypes.cpython-38-x86_64-linux-gnu.so: undefined sybol :pyfloat_type".
It seems that import other 3rd modules (like open3d numpy) all occur errors.

Thank everyone!

The enum manipulation code of shared_library_load_mode produces an invalid-enum-load error with clang-10's UBSan in line 226 of shared_library_load_mode.hpp. This seems like a true positive, as the enumeration really becomes an invalid value at this stage.

This is the produced error output:

/usr/include/boost/dll/shared_library_load_mode.hpp:226:19: runtime error: load of value 4278190079, which is not a valid value for type 'boost::dll::load_mode::type'
SUMMARY: UndefinedBehaviorSanitizer: invalid-enum-load /usr/include/boost/dll/shared_library_load_mode.hpp:226:19 in 

A quick fix would be adding the invalid enum value that this manipulation code produces (4278190079) to the enum. enum above:

#else
    rtld_deepbind                         = RTLD_DEEPBIND,
#endif

    append_decorations                    = 0x00800000,
    search_system_folders                 = (append_decorations << 1),

    _ubsan_fix = 4278190079 // this line fixes the issue for the time being
#endif
};

Completely fixing this undefined behavior seems to require some changes in how the manipulation code is used... But with this fix, I can use UBSan again. I hope this report helps!

FreeBSD exposes fdlopen() which allows one to dlopen() from a file descriptor. That's the only way to load plugins in capsicum mode. dlopen() and all functions that try to access the filesystem through pathnames fail under capsicum mode (ENOTCAPABLE).

Boost.Dll doesn't need to add functionality that can only be supported under FreeBSD (fdlopen()), but it should be very useful if the ifdef portability blocks only exist to initialize boost::dll::shared_library and nothing else (a small fdlopen() in my source at the beginning and then the rest of the code is the same for all platforms).

Docs suggest that it should:

    /*!
    * Destroys the object by calling `unload()`. If library was loaded multiple times
    * by different instances, the actual DLL/DSO won't be unloaded until
    * there is at least one instance that references the DLL/DSO.
    *
    * \throw Nothing.
    */
    ~shared_library() BOOST_NOEXCEPT {}

non template free functions in dll/detail/demangling/msvc.hpp are not inline, so they cannot be used by multiple cpp files, or there will be a link error "symbol already defined"

I've got a library compiled to a DLL that works properly in C++ when loaded with boost::dll.

I'd like to load the same binary in Python using pybind11, which works fine by itself. However, the DLL compiled with a PYBIND11_MODULE in addition to a BOOST_DLL_ALIAS fails to load in C++ with boost::dll.

Throws boost::dll::shared_library::load() failed: The specified module could not be found.

The library is for use from C++ but needs some complex functional testing against Python prototype code. It's convenient to imagine a dual-use Python/C++ DLL that has both interfaces in a single binary build.

But maybe this isn't possible?

I've put a detailed description in this gist.

Hi,

on Windows I get the following compilation error.

include\boost\dll\detail\pe_info.hpp(291,13): error C3861: 'getline': identifier not found
include\boost\dll\detail\pe_info.hpp(291,13): error C3861: getline(fs, symbol_name, '\0');
include\boost\dll\detail\pe_info.hpp(291,13): error C3861: ^

When I change the include of cstring to string it works.

According to cppreference std::getline is defined in header string.
https://en.cppreference.com/w/cpp/string/basic_string/getline

In glibc 2.36 and later, librt.so has been merged into libc (a similar blog for libpthread, the test of Boost.Dll tries to dlopen(2) libdl.so will run into failure because it's not existed.

Since zlib is a dependency of Boost, can we change to that:

glibc 2.36 doesn't have libdl.so, it has been melted into libc
Change to libz.so
Index: boost-1.81.0/libs/dll/test/shared_library_load_test.cpp
===================================================================
--- boost-1.81.0.orig/libs/dll/test/shared_library_load_test.cpp
+++ boost-1.81.0/libs/dll/test/shared_library_load_test.cpp
@@ -231,7 +231,7 @@ int main(int argc, char* argv[])
             boost::dll::shared_library("winmm.dll");
             BOOST_TEST(false);
 #elif BOOST_OS_LINUX
-            boost::dll::shared_library("libdl.so");
+            boost::dll::shared_library("libz.so");
             BOOST_TEST(false);
 #endif
         } catch (...) {}
@@ -242,7 +242,7 @@ int main(int argc, char* argv[])
 #if BOOST_OS_WINDOWS
             boost::dll::shared_library("winmm", load_mode::search_system_folders | load_mode::append_decorations);
 #elif BOOST_OS_LINUX
-            boost::dll::shared_library("dl", boost::dll::load_mode::search_system_folders | load_mode::append_decorations);
+            boost::dll::shared_library("z", boost::dll::load_mode::search_system_folders | load_mode::append_decorations);
 #endif
         } catch (...) {
             BOOST_TEST(false);

See https://ci.appveyor.com/project/apolukhin/boost-dll/builds/20870450/job/4044pxejtggcqrun

Especially see

testing.capture-output ..\..\..\bin.v2\libs\dll\test\cpp_mangle_test.test\clang-win-7.0.0\debug\address-model-64\cxxstd-17-iso\threading-multi\cpp_mangle_test.run
====== BEGIN OUTPUT ======
Library: "..\..\..\bin.v2\libs\dll\test\clang-win-7.0.0\debug\address-model-64\cxxstd-17-iso\threading-multi\cpp_plugin-clangw7-mt-d-x64-1_69.dll"
Symbols: 
??0some_class@some_space@@QEAA@$$QEAU01@@Z
??0some_class@some_space@@QEAA@H@Z
??0some_class@some_space@@QEAA@XZ
??0some_father@some_space@@QEAA@XZ
??1some_class@some_space@@UEAA@XZ
??1some_father@some_space@@QEAA@XZ
??4some_class@some_space@@QEAAAEAU01@$$QEAU01@@Z
??4some_father@some_space@@QEAAAEAU01@AEBU01@@Z
??_7some_class@some_space@@6B@
?father_value@some_space@@3HA
?func@some_class@some_space@@QECAHHH@Z
?func@some_class@some_space@@QEDANNN@Z
?func@some_class@some_space@@UEAAHHH@Z
?func@some_class@some_space@@UEAANNN@Z
?get@some_class@some_space@@QEBAHXZ
?overloaded@@YAXH@Z
?overloaded@@YAXN@Z
?scoped_fun@some_space@@YAAEBHXZ
?set@some_class@some_space@@QEAAXH@Z
?set_value@some_class@some_space@@SAXAEBH@Z
?size_of_some_class@some_space@@3_KA
?unscoped_c_var@@3NB
?unscoped_var@@3HA
?use_variant@@YAXAEAV?$variant@HN@boost@@@Z
?use_variant@@YAXAEAV?$variant@NH@boost@@@Z
?value@some_class@some_space@@2HA
?variable@some_space@@3NA
this_
cpp_mangle_test.cpp(48): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(57): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(61): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(66): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(72): test '!v1.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(73): test '!v2.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(74): test 'v1 != v2' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(77): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(82): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(90): test '!ctor1.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(93): test '!ctor2.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(97): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(100): test '!v.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(105): test '!dtor.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(110): test '!var1.empty()' failed in function 'int main(int, char **)'
cpp_mangle_test.cpp(111): test '!var2.empty()' failed in function 'int main(int, char **)'
16 errors detected.
 
EXIT STATUS: 1 
====== END OUTPUT ======

Compiling this file with "clang-cl -std:c++latest", it will get the following error(the error doesn't show up when using -std:c++20 or older):

+ clang-cl cpp_test_library.cpp -TP /Z7 /Od /Ob0 /W3 /GR /MDd /EHs -std:c++latest -D_CRT_USE_BUILTIN_OFFSETOF -c -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED '-I..\..\..'
cpp_test_library.cpp(37,56): warning: volatile-qualified parameter type 'const volatile int' is deprecated [-Wdeprecated-volatile]
BOOST_SYMBOL_EXPORT void overloaded(const volatile int i)
                                                       ^
cpp_test_library.cpp(102,61): error: non-const lvalue reference to type 'some_space::some_class' cannot bind to a temporary of type 'some_space::some_class'
some_class& some_class::operator=(some_class &&ref) {return ref;}
                                                            ^~~
1 warning and 1 error generated.
+ clang-cl cpp_test_library.cpp -TP /Z7 /Od /Ob0 /W3 /GR /MDd /EHs -std:c++20 -D_CRT_USE_BUILTIN_OFFSETOF -c -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED '-I..\..\..'
cpp_test_library.cpp(37,56): warning: volatile-qualified parameter type 'const volatile int' is deprecated [-Wdeprecated-volatile]
BOOST_SYMBOL_EXPORT void overloaded(const volatile int i)
                                                       ^
1 warning generated.

In line 102, ref is an rvalue reference (a temporary) and it's being returned as an lvalue reference that cannot have its lifetime extended.
A workaround is to change the return type to be a const lvalue reference so the lifetime can be extended (or actually honor the move semantics of the parameter).

https://github.com/boostorg/dll/blob/develop/test/Jamfile.v2#L22

Boost.Build doesn't currently check for this, but it's likely to behave very strangely.
(i.e. both debug and release will be present.)

When invoking the copy assignment operator (or the copy constructor) of the 'shared_library' class, eventually there is a call to 'boost::dll::detail::path_from_handle'. On android this call ends up dereferencing the handle returned by 'dlopen', which is not allowed since this patch: https://android.googlesource.com/platform/bionic/+/ae74e87%5E!/.

As a side-note, I believe the 'BOOST_OS_ANDROID' macro is not longer used.

We are using dll boost project to access shared libraries symbols on Linux EL7 (ELF)
We notice that we symbols with PROTECTED visibility attribute are not listed on library_info symbols.
Protected symbols are exported and can be accessed when loading shared libraries using dlopen/dlsym, so I understand they should be included on symbols list retrieved using library_info.

We try changing is_visible method on dll/detail/elf_info.hpp, and changing the condition to:
return ((sym.st_other & 0x03) == STV_DEFAULT_ || (sym.st_other & 0x03) == STV_PROTECTED_ ) && (sym.st_info >> 4) != STB_LOCAL_ && !!sym.st_size;
and it seems to work.

Moved from: https://svn.boost.org/trac10/ticket/13192

Hi, I'm using the modular boost and there <boost/utility/explicit_operator_bool.hpp> does not exist anymore since it has been moved to <boost/core/explicit_operator_bool.hpp>, could you please update the include in line 19 of shared_library.hpp?

Thanks! Greetings from Munich!

Moved from https://svn.boost.org/trac10/ticket/12886

When i adding '#define BOOST_DLL_USE_STD_FS' in simple project, then i get compilation error.

//#include <string> // << Uncomment this line and compilation is ok

#ifndef BOOST_DLL_USE_STD_FS
#define BOOST_DLL_USE_STD_FS
#endif

#include <boost/dll.hpp>

int main()
{
	return 0;
}

I found that adding include before definition BOOST_DLL_USE_STD_FS solves this problem.

Next i looked on diffs between DLL in Boost 1.72 and 1.73 releases and seen that include of was in x_info_interface.hpp and that header does not exists anymore.

Best regards, Dmitry Egorov.

DeImangle does not match when smart_library calls import_Imangled with const T* or std ::string.I solved this problem by modifying the type_rule function of itanium.h file. The modified code is as follows:

template
std::string type_rule(const std::string & type_name)
{
using namespace std;

//- return type_name +
// - const_rule() +
// - volatile_rule() +
// - reference_rule();
+ (void)type_name;
+ return boost::core::demangle(typeid (T).name()) + const_rule() + volatile_rule() + reference_rule();
}

On MinGW-w64, the BOOST_DLL_ALIAS does not export symbol. I presume this is because the macro only declares avariable and GCC strips it.

#define BOOST_DLL_ALIAS_SECTIONED(FunctionOrVar, AliasName, SectionName)                        \
    namespace _autoaliases {                                                                    \
        extern "C" BOOST_SYMBOL_EXPORT const void *AliasName;                                   \
    } /* namespace _autoaliases */                                                              \
    /**/

If I try to do manually the same in a source file. It confirms my thoughts:

Using a defined function

extern "C" {

__declspec(dllexport)
int my_super_mario_function()
{
    return 0;
}

}

Once built, the symbol appears correctly:

$ g++ -std=c++17 -shared -o plugin.dll plugin.cpp -fvisibility=hidden -lboost_system-mt && nm plugin.dll | grep my_
0000000067e8142d t _GLOBAL__sub_I__ZN6custom11my_functionEv
0000000067e813b0 T _ZN6custom11my_functionEv
0000000067e813cb T my_super_mario_function

Using a simple declaration

extern "C" {

__declspec(dllexport)
int my_super_mario_function();

}

In that case, no symbol is exported.

$ g++ -std=c++17 -shared -o plugin.dll plugin.cpp -fvisibility=hidden -lboost_system-mt && nm plugin.dll | grep my_
0000000067e81422 t _GLOBAL__sub_I__ZN6custom11my_functionEv
0000000067e813b0 T _ZN6custom11my_functionEv

However, assigning a value seems to work, but a bit ugly.

namespace custom {

void my_function()
{
        puts("CALLED");
}

} // !custom

extern "C" {

__declspec(dllexport) void* my_super_function = reinterpret_cast<void*>(&(custom::my_function));

}

The symbol is there:

$ g++ -std=c++17 -shared -o plugin.dll plugin.cpp -fvisibility=hidden -lboost_system-mt && nm plugin.dll | grep my_
0000000067e81422 t _GLOBAL__sub_I__ZN6custom11my_functionEv
0000000067e813b0 T _ZN6custom11my_functionEv
0000000067e85010 D my_super_function

What can we do to fix that issue? Is there a compile flag that export declared symbol?

The trivial example doesn't compile for Windows Embedded Compact 2013 SDK, normal Windows SDK works well.

#include <boost/dll.hpp>
int wmain() {}

1>  t.cpp
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(415): error C2061: syntax error : identifier 'LPVOID'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2146: syntax error : missing ';' before identifier 'LockResource'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2433: 'LPVOID' : 'inline' not permitted on data declarations
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2065: 'HGLOBAL' : undeclared identifier
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2146: syntax error : missing ')' before identifier 'hResData'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2059: syntax error : ')'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2143: syntax error : missing ';' before '{'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(563): error C2447: '{' : missing function header (old-style formal list?)
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(624): error C2061: syntax error : identifier 'LPDWORD'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(645): error C2061: syntax error : identifier 'LPDWORD'
1>C:\Program Files (x86)\Vector Vrtp\SDKs\WEC800_VRTP_SDK\sdk\Inc\kfuncs.h(656): error C2061: syntax error : identifier 'LPDWORD'

The enum type has no underlying type specified but the bitwise negation operator converts a negated unsigned int to type which almost certainly results in a type outside the range of the enum. UBSAN (clang++-8) catches this: /opt/boost_1_67_0/include/boost/dll/shared_library_load_mode.hpp:226:19: runtime error: load of value 4278190079, which is not a valid value for type 'boost::dll::load_mode::type'

Solution: Specify the type (unsigned) explicitly.

In boost/dll/detail/posix/program_location_impl.hpp for FreeBSD the buffer size is 10240. Is that correct or a typo and it should be 1024?

Hello,
using boost::dll in my XPCF dynamic component framework (boost::dll is used in https://github.com/b-com-software-basis repository xpcf in the ModuleManager.cpp file), a module (i.e. a shared library) developer has met the following issue :

• The instantiated component C inherits a I interface, in the component implementation, the declaration of a pure virtual method of I (declared as override in the component header) was not in the component:: scope
• Dynamically loading the module failed and the output message from boost::dll is "boost::dll::shared_library::load() failed (dlerror system message: .../shared/debug/module: cannot open shared object file: No such file or directory): Bad file descriptor"

The issue appeared on linux (on Mac, clang complains for missing symbols at the module link time, hence prevent the issue to append).

Investigating inside shared_library_impl.hpp, it appears that errors (in this case dlerror = missing symbol) with load_mode = append_decorations are not handled in the scope.
Leaving the append_decoration scope in error, there is a try to open the file with the specified path (which is incomplete as it misses the lib prefix and the .so suffix), that results in the erroneous error message "bad file descriptor".

I'd expect boost::dll to check if the current error is a bad _file_descriptor, in such a case to try opening the exactly specified path. Otherwise, other errors should be returned immediately before the append_decorations scope ends.

Or maybe, if append_decorations fails, boost should return the error without trying to open the exact specified path : it is the user responsibility to provide an abstract shared library name when used in conjunction with append_decorations ?

Environment:
g++ version is 7.3.0, boost 1.68 built with c++14 option on ubuntu 18.04.

Best regards

using boost::typeindex::ctti_type_index;
using boost::typeindex::stl_type_index;
cout << "type name:" << stl_type_index::type_id<const char*>() << endl;//print "char const*"
cout << "type name:" << ctti_type_index::type_id<const char*>() << endl;//print "const char*

//mangled_storage_base.hpp output "char const*"
void add_symbols(const std::vectorstd::string & symbols) //demangle symbol is "char const *"

//demangle symbol
inline char const * demangle_alloc( char const * name ) BOOST_NOEXCEPT
{
int status = 0;
std::size_t size = 0;
return abi::__cxa_demangle( name, NULL, &size, &status );
}

//mangled_storage_base.hpp demangled symbol is "const char*"
std::string get_name() const
{
using boost::typeindex::ctti_type_index;
auto tx = ctti_type_index::type_id();
auto val = (aliases_.count(tx) > 0) ? aliases_.at(tx) : tx.pretty_name();
return val;
}

ctti_type_index and stl_type_index export characters are inconsistent, how to use typeid() of ctti_type_index to determine whether typeid() of stl_type_index exists?

I noticed this when I turned most of my code into a callback based api.
The problem happens when classes are involved.

clang version 7.0.0-3~ubuntu0.18.04.1 (tags/RELEASE_700/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

/include/boost/dll/smart_library.hpp:446:1: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
auto get(const smart_library& sm, const std::string &name, typename boost::enable_if<boost::is_function<T>>::type* = nullptr)

• Hi, I would like to build with c ++ 11. Can you guys fix this problem?? I think decltype would be enough.

template<class T>
auto get(const smart_library& sm, const std::string &name, typename boost::enable_if<boost::is_function<T>>::type* = nullptr) -> decltype(sm.get_function<T>(name))
{
    return sm.get_function<T>(name);
}

See:

AFAIK link.h is not a POSIX header, Haiku for example have no such header:
haikuports/haikuports#3998

This causes portability problems.

The "Importing a C function from windows dll" example currently leads to bogus assembly generation with visual studio 16.5.

I refactored the code a bit to get an easily digestible assembly snippet, but the issue can also be reproduced with the code from the example copied verbatim and made GetStdHandle_t a goddamn pointer.

using GetStdHandle_t =  void *(__stdcall *)(unsigned int);
namespace dll = boost::dll;

struct stable_layout
{
    dll::shared_library lib;
    GetStdHandle_t getStdHandle;

    stable_layout()
        : lib("Kernel32.dll", dll::load_mode::search_system_folders)
        , getStdHandle(nullptr)
    {}
};

void func_lookup(stable_layout &self)
{
    self.getStdHandle = self.lib.get<GetStdHandle_t>("GetStdHandle");
}

if compiled with cl /I..\boost\include /DBOOST_DLL_USE_STD_FS=1 /std:c++17 /EHsc /Zi x.cpp func_lookup will be lowered to the following x86 assembly:

push    ebp
mov     ebp,esp
push    ecx
mov     eax,dword ptr ss:[ebp+0x8]  ; [ebp+0x8]: "self" parameter on stack
mov     dword ptr ss:[ebp-0x4],eax
push    x.5A9E50                    ; 5A9E50: "GetStdHandle"
mov     ecx,dword ptr ss:[ebp-0x4]
call    x.543BFC                    ; 543BFC: shared_library::get
                                    ; function address is returned in eax
mov     ecx,dword ptr ss:[ebp+0x8]
mov     edx,dword ptr ds:[eax]      ; dereference of eax/function address
mov     dword ptr ds:[ecx+0x4],edx  ; [ecx+0x4]: self.getStdHandle
mov     esp,ebp
pop     ebp
ret

The lowered x64 assembly is also borked. Boost version 1.72; x.cpp. MS DevCom Ticket

I have a plugin.so file with the following function:

namespace plugin
{
  void InitPlugin(const std::string &path)
  {
  }
}

I am trying to load the function using import_mangled. I am aware that it is experimental.

boost::dll::experimental::smart_library lib("./plugin.so");
typedef void (InitPlugin_t)(const std::string&);
auto initPlugin = boost::dll::experimental::import_mangled<InitPlugin_t>(lib, "plugin::InitPlugin");

This works fine with g++, but fails with clang. Both under Ubuntu 22.04.
plugin.so exports a function named:
plugin::InitPlugin(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)

However it looks like import_mangled under clang is looking for a function named:
plugin::InitPlugin(std::basic_string<char, std::char_traits, std::allocator > const&)
Notice that the namespace __cxx11 is missing.

It seems to come from a difference between how __PRETTY_FUNCTION__ is implemented in g++ and clang.

Hi Antony,
do you think there is some value to replace some of boost::dll boost dependencies with std:: ones when available ?
Typically, I think about shared_ptr, type_traits, move, asserts and so on..

So the trouble is here:

.../vcpkg_installed/x64-linux/include/boost/dll/import.hpp:132:30: error: expected unqualified-id
BOOST_DLL_IMPORT_RESULT_TYPE import(const boost::dll::fs::path& lib, const char* name,
                             ^
.../vcpkg_installed/x64-linux/include/boost/dll/import.hpp:146:18: fatal error: 'T' file not found
    return import<T>(lib, name.c_str(), mode);

Some plugins are never safe to unload (e.g. if you're using Qt, Qt will start threads that are never joined and register thread-local variables in other threads, and it's unsafe to unload Qt code then). I'd like to use Boost.DLL for its portable API, but right now I need to use code like this to provoke an intentional leak:

auto lib = new dll::shared_library;
// ...

Here's code in the wild making use of this workaround: https://gitlab.com/emilua/qt6/-/blob/23baacf56b79d8355082df97bd1d0c2fa6c64ec1/src/qt_handle.cpp#L25

I'd rather do something like this:

dll::shared_library lib;
// ...
lib.release();

Can we have the release() function for shared_library?

Consider the following example:

boostdll::experimental::smart_library lib;
lib.load("test.dll");

int f(char a[]);
decltype(f)* pf = lib.get_function<decltype(f)>("f");

This fails to find function f as it's demangled as int __cdecl f(char * __ptr64 const), but MSVC parser doesn't accept that trailing const

The boost dll documentation documentation suggests to link against dl on Linux: https://www.boost.org/doc/libs/1_84_0/doc/html/boost_dll/getting_started.html.

Would there be reason not to do this already in the Boost dll CMakeLists.txt when using the CMake integration?

'Getting started' page says:

'Importing code requires linking with boost_filesystem and boost_system libraries.

but libdl.so is not in NEEDED section of libboost_system.so, which obviously results with linking error:

/usr/bin/c++ -g -rdynamic CMakeFiles/common-logic.dir/main.cpp.o -o common-logic -lboost_filesystem -lboost_system
/usr/bin/ld: CMakeFiles/common-logic.dir/main.cpp.o: in function boost::dll::detail::reset_dlerror()': /usr/include/boost/dll/detail/system_error.hpp:27: undefined reference to dlerror'

(and for all other functions: dlopen, dlsym etc)

Please either update guideline to inform users to link their relevant OS library themselves, or maybe add said OS library (libdl.so, other OS equivalent) as library dependency for boost_system so that it's pulled automatically.

It seems like there are ELF libraries do not have any symbols in the symtab table. This is the case for some libraries shipped with my distro (libaio1 in Debian Buster to be specific). However, the dynsym table does contain a list of exported symbols. I think it would be great if library_info::symbols could return those, potentially only as fall-back if the symtab table is empty. Currently, it does not return them, not even if I explicitly call library_info::symbols(".dynsym").

In some cases, I'd expect to be able to compute the complete full path of the shared library as an boost::filesystem::path prior to load the library.
I'd like to have a method (maybe static ?) such as
boost::filesystem::path shared_library::append_decorations(const boost::filesystem::path & path) exposed in shared_library class.