![]() Do I understand correctly that they're always built as shared libraries so that they can be loaded dynamically? Libtool handles a lot of things, but most of them aren't a concern for oct files. )? (We definitely don't have the resources to test that reliably.) Isn't that the reason something like `libtool` exists in the first place? ![]() > Is it possible to write those rules in a way that works correctly across different platforms and compilers (GCC, clang, Apple clang, Intel C++, IBM. That should allow building Octave with `slibtool` while maintaining compatibility with all platforms that we currently support. I pushed the following change that parses the. We probably shouldn't rely on those files being installed anyway. (If they are not, that is probably a bug in `slibtool`.) la files are still produced and are compatible with `libtool`. > `.la wrappers` on the one hand, yet fully ignore their content on the ![]() > libtool as much as possible, `slibtool`'s behavior is to always produce > and given its announced goal to remain compatible with the script-based > independent of the above wrappers with respect to its own functionality, > compiler driver in subsequent link steps. > passing the archive or library as an input argument in. > generating a shared library or static archive, and which is needed when > `.la wrappers` contain key information that is provided to libtool when >- `.la wrappers` are always generated, but by default are never installed
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |