I think libtool shouldn't be used at all for these *.oct libraries the extra libtool pieces just get in the way. But I'm not sure if it is the right approach when it comes to portability. Since those artifacts are harmless in the meantime (and may never materialize in the first place), I don't see this as a huge problem, but I'm biased.
#Gnu octave download Patch#
The potential downside to the patch is that some other stray libtool artifacts may be discovered on an obscure platform, and the glob will have to be updated to remove them. I'm only comparing the status quo against my most recent patch. la file, or implementing and maintaining build rules for the different combinations of compilers and platforms ourselves instead of relying on tools like `libtool`? But I'm not sure which approach would be the better one in the long run: Relying on the layout of the. la file parsing from the install-oct target. > IMO this is a lesser evil and a bargain for removing the. It would be a larger change and it would require testing, obviously. The admins of older systems that I know have all bootstrapped themselves a modern(ish) toolchain, but YMMV. Some of the more basic flags (like -c and -o) are covered by the POSIX description of "cc", so IIRC you're mainly relying on -shared and -fpic. For example, you don't want to pass -fpic to a compiler that doesn't support it but that can be tested with autoconf, with or without libtool. But the command-line that libtool constructs is a fairly standard one consisting of $CC, $CFLAGS, $LDFLAGS, $LIBS, etc, all in the proper order - most of the magic therefore takes place in constructing those variables. and, you've caught me: I can't make any promises about proprietary compilers that I don't have access to. It DOES also play a part in the command used to build the libraries. * Figuring out the correct prefix and suffix for the library files * Hacking of the library search path so that you can run the programīefore installing it (not an issue with dlopen). * Old operating systems without support for shared libraries at all * Build system support for -disable-shared If so, some of libtool's features that AREN'T needed are, 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.
0 kommentar(er)
