[Octave-bug-tracker] [bug #61905] Build fails when using slibtool instead of GNU libtool

[Michael Orlitzky]

Follow-up Comment #28, bug #61905 (project octave):

[comment #27 comment #27:]
> 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,
...)? (We definitely don't have the resources to test that reliably.) Isn't
that the reason something like `libtool` exists in the first place?

Libtool handles a lot of things, but most of them aren't a concern for oct
files. Do I understand correctly that they're always built as shared libraries
so that they can be loaded dynamically?

If so, some of libtool's features that AREN'T needed are,

  * Build system support for --disable-shared
  * Old operating systems without support for shared libraries at all
  * Hacking of the library search path so that you can run the program
    before installing it (not an issue with dlopen).
  * Figuring out the correct prefix and suffix for the library files
    on the current system (always foo.oct).
  * Library (soname) versioning.

It DOES also play a part in the command used to build the libraries... and,
you've caught me: I can't make any promises about proprietary compilers that I
don't have access to. 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. 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. 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.

The admins of older systems that I know have all bootstrapped themselves a
modern(ish) toolchain, but YMMV. It would be a larger change and it would
require testing, obviously. I'm just throwing it out there =)


> > IMO this is a lesser evil and a bargain for removing the .la file parsing
from the install-oct target.
> 
> I agree that parsing the .la file might not be the best solution. But I'm
not sure which approach would be the better one in the long run: Relying on
the layout of the .la file, or implementing and maintaining build rules for
the different combinations of compilers and platforms ourselves instead of
relying on tools like `libtool`?

I'm only comparing the status quo against my most recent 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. 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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61905>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/