libloading/changelog.rs
1//! The change log.
2
3/// Release 0.9.0 (2025-11-05)
4///
5/// ## Breaking changes
6///
7/// * MSRV has been increased to 1.88.0;
8/// * This release adds a `std` feature. Most functionality remains available with this feature
9/// disabled, but anything involving `OsStr`, `OsString`, `Path` or `PathBuf` is only available
10/// with `std` feature enabled. If you are depending on `libloading` with `no-default-features`
11/// set to true, you may see compilation errors. Running with `std` feature enabled is still
12/// the strongly recommended option. no-std functionality has been contributed in [#184];
13/// * As a result of the change above, functions that previously using `AsRef<OsStr>` to
14/// describe the library path now require an implementor of [`AsFilename`](crate::AsFilename)
15/// instead. `AsFilename` has been implemented for the most likely types used previously. Please
16/// file an issue if you rely on a type that no longer works.
17/// * The `Error` enum's variants changed in incompatible ways. Furthermore it has been changed to
18/// return the underlying dlerror via the `source` method (matching behaviour on Windows.)
19/// * On Windows providing filenames with interior null bytes to `Library::open` and related
20/// functions will now report an error instead of silently truncating the provided input. This is
21/// a bug fix.
22///
23/// [#184]: https://github.com/nagisa/rust_libloading/pull/184
24///
25/// ## Non-breaking changes
26///
27/// * Symbol lookups via `Library::get` and related functions can now use a wider variety of string
28/// types, including `&CStr`. This, among other things, means that `c"symbol"` literals can be
29/// used without incurring any additional null-byte checking overhead or reallocations that were
30/// necessary for `&[u8]` argument used previously to support `b"literals"`. `&[u8]` is still
31/// accepted. This new functionality has been contributed in [#174] and [#184].
32///
33/// [#174]: https://github.com/nagisa/rust_libloading/pull/174
34///
35pub mod r0_9_0 {}
36
37/// Release 0.8.9 (2025-09-17)
38///
39/// ## Non-breaking changes
40///
41/// Migrate from windows-targets to windows-link for linking Windows API functions.
42pub mod r0_8_9 {}
43
44/// Release 0.8.8 (2025-05-27)
45///
46/// ## Non-breaking changes
47///
48/// Add `os::window::Library::pin`.
49pub mod r0_8_8 {}
50
51/// Release 0.8.7 (2025-04-26)
52///
53/// ## Non-breaking changes
54///
55/// Add support for the `*-pc-cygwin` target.
56pub mod r0_8_7 {}
57
58/// Release 0.8.4 (2024-06-23)
59///
60/// ## Non-breaking changes
61///
62/// Compilation when targeting Apple's visionos, watchos and tvos targets has been fixed.
63pub mod r0_8_4 {}
64
65/// Release 0.8.3 (2024-03-05)
66///
67/// ## Non-breaking changes
68///
69/// A `dev-dependency` on `windows-sys` that was unconditionally introduced in
70/// [0.8.2](r0_8_2) has been made conditional.
71pub mod r0_8_3 {}
72
73/// Release 0.8.2 (2024-03-01)
74///
75/// ## (Potentially) breaking changes
76///
77/// MSRV has been increased to 1.56.0. Since both rustc versions are ancient, this has been deemed
78/// to not be breaking enough to warrant a semver-breaking release of libloading. If you're stick
79/// with a version of rustc older than 1.56.0, lock `libloading` dependency to `0.8.1`.
80///
81/// ## Non-breaking changes
82///
83/// * The crate switches the dependency on `windows-sys` to a `windows-target` one for Windows
84/// bindings. In order to enable this `libloading` defines any bindings necessary for its operation
85/// internally, just like has been done for `unix` targets. This should result in leaner dependency
86/// trees.
87/// * `os::unix::with_dlerror` has been exposed for the users who need to invoke `dl*` family of
88/// functions manually.
89pub mod r0_8_2 {}
90
91/// Release 0.8.1 (2023-09-30)
92///
93/// ## Non-breaking changes
94///
95/// * Support for GNU Hurd.
96pub mod r0_8_1 {}
97
98/// Release 0.8.0 (2023-04-11)
99///
100/// ## (Potentially) breaking changes
101///
102/// * `winapi` dependency has been replaced with `windows-sys`.
103/// * As a result the MSRV has been increased to 1.48.
104///
105/// ## Non-breaking changes
106///
107/// * Support for the QNX Neutrino target has been added.
108pub mod r0_8_0 {}
109
110/// Release 0.7.4 (2022-11-07)
111///
112/// This release has no functional changes.
113///
114/// `RTLD_LAZY`, `RTLD_GLOBAL` and `RTLD_LOCAL` constants have been implemented for AIX platforms.
115pub mod r0_7_4 {}
116
117/// Release 0.7.3 (2022-01-15)
118///
119/// This release has no functional changes.
120///
121/// In this release the `docsrs` `cfg` has been renamed to `libloading_docs` to better reflect that
122/// this `cfg` is intended to be only used by `libloading` and only specifically for the invocation
123/// of `rustdoc` when documenting `libloading`. Setting this `cfg` in any other situation is
124/// unsupported and will not work.
125pub mod r0_7_3 {}
126
127/// Release 0.7.2 (2021-11-14)
128///
129/// Cargo.toml now specifies the MSRV bounds, which enables tooling to report an early failure when
130/// the version of the toolchain is insufficient. Refer to the [min-rust-version RFC] and its
131/// [tracking issue].
132///
133/// [min-rust-version RFC]: https://rust-lang.github.io/rfcs/2495-min-rust-version.html
134/// [tracking issue]: https://github.com/rust-lang/rust/issues/65262
135///
136/// Additionally, on platforms `libloading` has no support (today: `not(any(unix, windows))`), we
137/// will no longer attempt to implement the cross-platform `Library` and `Symbol` types. This makes
138/// `libloading` compile on targets such as `wasm32-unknown-unknown` and gives ability to the
139/// downstream consumers of this library to decide how they want to handle the absence of the
140/// library loading implementation in their code. One of such approaches could be depending on
141/// `libloading` itself optionally as such:
142///
143/// ```toml
144/// [target.'cfg(any(unix, windows))'.dependencies.libloading]
145/// version = "0.7"
146/// ```
147pub mod r0_7_2 {}
148
149/// Release 0.7.1 (2021-10-09)
150///
151/// Significantly improved the consistency and style of the documentation.
152pub mod r0_7_1 {}
153
154/// Release 0.7.0 (2021-02-06)
155///
156/// ## Breaking changes
157///
158/// ### Loading functions are now `unsafe`
159///
160/// A number of associated methods involved in loading a library were changed to
161/// be `unsafe`. The affected functions are: [`Library::new`], [`os::unix::Library::new`],
162/// [`os::unix::Library::open`], [`os::windows::Library::new`],
163/// [`os::windows::Library::load_with_flags`]. This is the most prominent breaking change in this
164/// release and affects majority of the users of `libloading`.
165///
166/// In order to see why it was necessary, consider the following snippet of C++ code:
167///
168/// ```c++
169/// #include <vector>
170/// #include <iostream>
171///
172/// static std::vector<unsigned int> UNSHUU = { 1, 2, 3 };
173///
174/// int main() {
175/// std::cout << UNSHUU[0] << UNSHUU[1] << UNSHUU[2] << std::endl; // Prints 123
176/// return 0;
177/// }
178/// ```
179///
180/// The `std::vector` type, much like in Rust's `Vec`, stores its contents in a buffer allocated on
181/// the heap. In this example the vector object itself is stored and initialized as a static
182/// variable – a compile time construct. The heap, on the other hand, is a runtime construct. And
183/// yet the code works exactly as you'd expect – the vector contains numbers 1, 2 and 3 stored in
184/// a buffer on heap. So, _what_ makes it work out, exactly?
185///
186/// Various executable and shared library formats define conventions and machinery to execute
187/// arbitrary code when a program or a shared library is loaded. On systems using the PE format
188/// (e.g. Windows) this is available via the optional `DllMain` initializer. Various systems
189/// utilizing the ELF format take a slightly different approach of maintaining an array of function
190/// pointers in the `.init_array` section. A very similar mechanism exists on systems that utilize
191/// the Mach-O format.
192///
193/// For the C++ program above, the object stored in the `UNSHUU` global variable is constructed
194/// by code run as part of such an initializer routine. This initializer is run before the entry
195/// point (the `main` function) is executed, allowing for this magical behaviour to be possible.
196/// Were the C++ code built as a shared library instead, the initialization routines would run as
197/// the resulting shared library is loaded. In case of `libloading` – during the call to
198/// `Library::new` and other methods affected by this change.
199///
200/// These initialization (and very closely related termination) routines can be utilized outside of
201/// C++ too. Anybody can build a shared library in variety of different programming languages and
202/// set up the initializers to execute arbitrary code. Potentially code that does all sorts of
203/// wildly unsound stuff.
204///
205/// The routines are executed by components that are an integral part of the operating system.
206/// Changing or controlling the operation of these components is infeasible. With that in
207/// mind, the initializer and termination routines are something anybody loading a library must
208/// carefully evaluate the libraries loaded for soundness.
209///
210/// In practice, a vast majority of the libraries can be considered a good citizen and their
211/// initialization and termination routines, if they have any at all, can be trusted to be sound.
212///
213/// Also see: [issue #86].
214///
215/// ### Better & more consistent default behaviour on UNIX systems
216///
217/// On UNIX systems the [`Library::new`], [`os::unix::Library::new`] and
218/// [`os::unix::Library::this`] methods have been changed to use
219/// <code>[RTLD_LAZY] | [RTLD_LOCAL]</code> as the default set of loader options (previously:
220/// [`RTLD_NOW`]). This has a couple benefits. Namely:
221///
222/// * Lazy binding is generally quicker to execute when only a subset of symbols from a library are
223/// used and is typically the default when neither `RTLD_LAZY` nor `RTLD_NOW` are specified when
224/// calling the underlying `dlopen` API;
225/// * On most UNIX systems (macOS being a notable exception) `RTLD_LOCAL` is the default when
226/// neither `RTLD_LOCAL` nor [`RTLD_GLOBAL`] are specified. The explicit setting of the
227/// `RTLD_LOCAL` flag makes this behaviour consistent across platforms.
228///
229/// ### Dropped support for Windows XP/Vista
230///
231/// The (broken) support for Windows XP and Windows Vista environments was removed. This was
232/// prompted primarily by a similar policy change in the [Rust
233/// project](https://github.com/rust-lang/compiler-team/issues/378) but also as an acknowledgement
234/// to the fact that `libloading` never worked in these environments anyway.
235///
236/// ### More accurate error variant names
237///
238/// Finally, the `Error::LoadLibraryW` renamed to [`Error::LoadLibraryExW`] to more accurately
239/// represent the underlying API that's failing. No functional changes as part of this rename
240/// intended.
241///
242/// [issue #86]: https://github.com/nagisa/rust_libloading/issues/86
243/// [`Library::new`]: crate::Library::new
244/// [`Error::LoadLibraryExW`]: crate::Error::LoadLibraryExW
245/// [`os::unix::Library::this`]: crate::os::unix::Library::this
246/// [`os::unix::Library::new`]: crate::os::unix::Library::new
247/// [`os::unix::Library::open`]: crate::os::unix::Library::new
248/// [`os::windows::Library::new`]: crate::os::windows::Library::new
249/// [`os::windows::Library::load_with_flags`]: crate::os::windows::Library::load_with_flags
250/// [`RTLD_NOW`]: crate::os::unix::RTLD_NOW
251/// [RTLD_LAZY]: crate::os::unix::RTLD_LAZY
252/// [RTLD_LOCAL]: crate::os::unix::RTLD_LOCAL
253/// [`RTLD_GLOBAL`]: crate::os::unix::RTLD_GLOBAL
254pub mod r0_7_0 {}
255
256/// Release 0.6.7 (2021-01-14)
257///
258/// * Added a [`os::windows::Library::open_already_loaded`] to obtain a handle to a library that
259/// must already be loaded. There is no portable equivalent for all UNIX targets. Users who do
260/// not care about portability across UNIX platforms may use [`os::unix::Library::open`] with
261/// `libc::RTLD_NOLOAD`;
262///
263/// [`os::windows::Library::open_already_loaded`]: crate::os::windows::Library::open_already_loaded
264/// [`os::unix::Library::open`]: crate::os::unix::Library::open
265pub mod r0_6_7 {}
266
267/// Release 0.6.6 (2020-12-03)
268///
269/// * Fix a double-release of resources when [`Library::close`] or [`os::windows::Library::close`]
270/// is used on Windows.
271///
272/// [`Library::close`]: crate::Library::close
273/// [`os::windows::Library::close`]: crate::os::windows::Library::close
274pub mod r0_6_6 {}
275
276/// Release 0.6.5 (2020-10-23)
277///
278/// * Upgrade cfg-if 0.1 to 1.0
279pub mod r0_6_5 {}
280
281/// Release 0.6.4 (2020-10-10)
282///
283/// * Remove use of `build.rs` making it easier to build `libloading` without cargo. It also
284/// almost halves the build time of this crate.
285pub mod r0_6_4 {}
286
287/// Release 0.6.3 (2020-08-22)
288///
289/// * Improve documentation, allowing to view all of the os-specific functionality from
290/// documentation generated for any target;
291/// * Add [`os::windows::Library::this`];
292/// * Added constants to use with OS-specific `Library::open`;
293/// * Add [`library_filename`].
294///
295/// [`os::windows::Library::this`]: crate::os::windows::Library::this
296/// [`library_filename`]: crate::library_filename
297pub mod r0_6_3 {}
298
299/// Release 0.6.2 (2020-05-06)
300///
301/// * Fixed building of this library on Illumos.
302pub mod r0_6_2 {}
303
304/// Release 0.6.1 (2020-04-15)
305///
306/// * Introduced a new method [`os::windows::Library::load_with_flags`];
307/// * Added support for the Illumos triple.
308///
309/// [`os::windows::Library::load_with_flags`]: crate::os::windows::Library::load_with_flags
310pub mod r0_6_1 {}
311
312/// Release 0.6.0 (2020-04-05)
313///
314/// * Introduced a new method [`os::unix::Library::get_singlethreaded`];
315/// * Added (untested) support for building when targeting Redox and Fuchsia;
316/// * The APIs exposed by this library no longer panic and instead return an `Err` when it used
317/// to panic.
318///
319/// ## Breaking changes
320///
321/// * Minimum required (stable) version of Rust to build this library is now 1.40.0;
322/// * This crate now implements a custom [`Error`] type and all APIs now return this type rather
323/// than returning the `std::io::Error`;
324/// * `libloading::Result` has been removed;
325/// * Removed the dependency on the C compiler to build this library on UNIX-like platforms.
326/// `libloading` used to utilize a snippet written in C to work-around the unlikely possibility
327/// of the target having a thread-unsafe implementation of the `dlerror` function. The effect of
328/// the work-around was very opportunistic: it would not work if the function was called by
329/// forgoing `libloading`.
330///
331/// Starting with 0.6.0, [`Library::get`] on platforms where `dlerror` is not MT-safe (such as
332/// FreeBSD, DragonflyBSD or NetBSD) will unconditionally return an error when the underlying
333/// `dlsym` returns a null pointer. For the use-cases where loading null pointers is necessary
334/// consider using [`os::unix::Library::get_singlethreaded`] instead.
335///
336/// [`Library::get`]: crate::Library::get
337/// [`os::unix::Library::get_singlethreaded`]: crate::os::unix::Library::get_singlethreaded
338/// [`Error`]: crate::Error
339pub mod r0_6_0 {}
340
341/// Release 0.5.2 (2019-07-07)
342///
343/// * Added API to convert OS-specific `Library` and `Symbol` conversion to underlying resources.
344pub mod r0_5_2 {}
345
346/// Release 0.5.1 (2019-06-01)
347///
348/// * Build on Haiku targets.
349pub mod r0_5_1 {}
350
351/// Release 0.5.0 (2018-01-11)
352///
353/// * Update to `winapi = ^0.3`;
354///
355/// ## Breaking changes
356///
357/// * libloading now requires a C compiler to build on UNIX;
358/// * This is a temporary measure until the [`linkage`] attribute is stabilised;
359/// * Necessary to resolve [#32].
360///
361/// [`linkage`]: https://github.com/rust-lang/rust/issues/29603
362/// [#32]: https://github.com/nagisa/rust_libloading/issues/32
363pub mod r0_5_0 {}
364
365/// Release 0.4.3 (2017-12-07)
366///
367/// * Bump lazy-static dependency to `^1.0`;
368/// * `cargo test --release` now works when testing libloading.
369pub mod r0_4_3 {}
370
371/// Release 0.4.2 (2017-09-24)
372///
373/// * Improved error and race-condition handling on Windows;
374/// * Improved documentation about thread-safety of Library;
375/// * Added `Symbol::<Option<T>::lift_option() -> Option<Symbol<T>>` convenience method.
376pub mod r0_4_2 {}
377
378/// Release 0.4.1 (2017-08-29)
379///
380/// * Solaris support
381pub mod r0_4_1 {}
382
383/// Release 0.4.0 (2017-05-01)
384///
385/// * Remove build-time dependency on target_build_utils (and by extension serde/phf);
386/// * Require at least version 1.14.0 of rustc to build;
387/// * Actually, it is cargo which has to be more recent here. The one shipped with rustc 1.14.0
388/// is what’s being required from now on.
389pub mod r0_4_0 {}
390
391/// Release 0.3.4 (2017-03-25)
392///
393/// * Remove rogue println!
394pub mod r0_3_4 {}
395
396/// Release 0.3.3 (2017-03-25)
397///
398/// * Panics when `Library::get` is called for incompatibly sized type such as named function
399/// types (which are zero-sized).
400pub mod r0_3_3 {}
401
402/// Release 0.3.2 (2017-02-10)
403///
404/// * Minimum version required is now rustc 1.12.0;
405/// * Updated dependency versions (most notably target_build_utils to 0.3.0)
406pub mod r0_3_2 {}
407
408/// Release 0.3.1 (2016-10-01)
409///
410/// * `Symbol<T>` and `os::*::Symbol<T>` now implement `Send` where `T: Send`;
411/// * `Symbol<T>` and `os::*::Symbol<T>` now implement `Sync` where `T: Sync`;
412/// * `Library` and `os::*::Library` now implement `Sync` (they were `Send` in 0.3.0 already).
413pub mod r0_3_1 {}
414
415/// Release 0.3.0 (2016-07-27)
416///
417/// * Greatly improved documentation, especially around platform-specific behaviours;
418/// * Improved test suite by building our own library to test against;
419/// * All `Library`-ies now implement `Send`.
420/// * Added `impl From<os::platform::Library> for Library` and `impl From<Library> for
421/// os::platform::Library` allowing wrapping and extracting the platform-specific library handle;
422/// * Added methods to wrap (`Symbol::from_raw`) and unwrap (`Symbol::into_raw`) the safe `Symbol`
423/// wrapper into unsafe `os::platform::Symbol`.
424///
425/// The last two additions focus on not restricting potential usecases of this library, allowing
426/// users of the library to circumvent safety checks if need be.
427///
428/// ## Breaking Changes
429///
430/// `Library::new` defaults to `RTLD_NOW` instead of `RTLD_LAZY` on UNIX for more consistent
431/// cross-platform behaviour. If a library loaded with `Library::new` had any linking errors, but
432/// unresolved references weren’t forced to be resolved, the library would’ve “just worked”,
433/// whereas now the call to `Library::new` will return an error signifying presence of such error.
434///
435/// ## os::platform
436/// * Added `os::unix::Library::open` which allows specifying arbitrary flags (e.g. `RTLD_LAZY`);
437/// * Added `os::windows::Library::get_ordinal` which allows finding a function or variable by its
438/// ordinal number;
439pub mod r0_3_0 {}