Mercurial > pub > dyncall > dyncall
diff dynload/dynload.3 @ 315:3840e0188520
- allowing lookup of running executable's path by passing NULL to dynload's dlGetLibraryPath()
author | Tassilo Philipp |
---|---|
date | Wed, 06 Nov 2019 14:13:49 +0100 |
parents | 7c6f19d42b31 |
children | 3df50603afa9 |
line wrap: on
line diff
--- a/dynload/dynload.3 Wed Nov 06 12:32:53 2019 +0100 +++ b/dynload/dynload.3 Wed Nov 06 14:13:49 2019 +0100 @@ -80,7 +80,9 @@ .Ar bufSize >= return value >= 1, a null-terminted string with the path to the library should be in .Ar sOut . -If it returns 0, the library name wasn't able to be found. Please note that this might happen in some rare cases, so make sure to always check. +If it returns 0, the library name wasn't able to be found. Please note that this might happen in some rare cases, so make sure to always check. Passing a null pointer as +.Ar pLib +returns the path to the executable (not guaranteed to be absolute). .Pp The dlSyms* functions can be used to iterate over symbols. Since they can be used on libraries that are not linked, they are made for symbol name lookups, not to get symbols' addresses. For that refer to @@ -101,14 +103,22 @@ .Sh BUGS .Fn dlGetLibraryPath is not thread-safe on Darwin (macOS, iOS, ...) and OpenBSD. +.Pp .Fn dlSymsInit is not thread-safe on Darwin. +.Pp .Fn dlGetLibraryPath will not work on the following platforms when the library in question doesn't have the (default) .Fn _init and .Fn _fini symbols exported (rare, but possible): Haiku (all versions), OpenBSD < 3.7, NetBSD < 5.1, FreeBSD < 4.8 +.Pp +Getting the executable's path by passing NULL in +.Ar pLib +to +.Fn dlGetLibraryPath +fails on the following platforms: Haiku (all versions), OpenBSD < 3.7, NetBSD < 5.1, FreeBSD < 4.8 .Sh CONFORMING TO The dynload library conforms to c99. .Ed