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

[Markus Mützel]

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

I haven't tested the latest patch yet. But I'm not sure if it is the right
approach when it comes to portability.

The following naming conventions seem to be used at least by autotools and
cmake for "mingw*" targets for a library "foo" in their current versions
(other naming conventions might be used by other build tools or other Windows
targets like e.g. "msvc"):
* static library: libfoo.a
* shared library: libfoo.dll
* import library: libfoo.dll.a
All of those are sometimes versioned as e.g. something like libfoo-1.dll.
Those naming conventions might be implementation details though. (Maybe even
more so than the .la file format.)

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

You might be right that the import libraries are technically static libraries
(from a file format point of view). But they are rarely referred to as such
because they are used for something rather different.

There is nothing that corresponds to Windows import libraries on Linux. As far
as I know, `LIBEXT` is the default extension for static libraries (i.e., `.a`
for mingw* targets). I don't know if there is a readily available variable
that tells which extension libtool is using for import libraries.


    _______________________________________________________

Reply to this item at:

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

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