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

[Michael Orlitzky]

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

Thanks for the pointer. If I read that right, it's not even *installing* the
oct files from the build tree. Instead it's cd'ing into the installation image
and using INSTALL_PROGRAM as a fancy "cp" to copy foo.so to foo.oct.

Of course I'm guessing, but I suppose this was done to abstract away the
actual names of the shared libraries (which are platform dependent).
Fortunately that information is already available to the build system. I've
attached a patch that exploits the knowledge of the shared library name, and
replaces most of the install-oct rule with a single "mv". It doesn't seem to
have broken anything else, but someone with more octave experience will have
to confirm.


(file #52806)
    _______________________________________________________

Additional Item Attachment:

File name: 0001-autotools-don-t-rely-on-libtool-internals-during-ins.patch
Size:3 KB
   
<https://file.savannah.gnu.org/file/0001-autotools-don-t-rely-on-libtool-internals-during-ins.patch?file_id=52806>



    _______________________________________________________

Reply to this item at:

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

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