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

[Michael Orlitzky]

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

[comment #25 comment #25:]
> I haven't tested the latest patch yet. But I'm not sure if it is the right
approach when it comes to portability.

Probably not. I think libtool shouldn't be used at all for these *.oct
libraries; the extra libtool pieces just get in the way. Unless you're
targeting systems from the early 90s, $(CC) <whatever> works fine and gives
you only the file you want in the place you expect. Losing the automake magic
for those libs would hurt a bit, but the corresponding rule can basically be
copy & pasted out of the generated Makefile.in.

> The following naming conventions seem to be used at least by autotools and
cmake for "mingw*" targets

Those are all covered...


> Afaict from a Google search, the naming conventions are the following for a
msvc target (using cmake?). (That could be wrong though):
> * static library: foo-static.lib
> * shared library: foo.dll
> * import library: foo.lib

Those .lib files would not be. But the worst thing that can possibly happen is
that some unused files get installed until the next release when the rule can
be updated. IMO this is a lesser evil and a bargain for removing the .la file
parsing from the install-oct target.


    _______________________________________________________

Reply to this item at:

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

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