bugGNU Octave - Bugs: bug #66908, Possibly incorrect soname for...

 
 

bug #66908: Possibly incorrect soname for liboctave

Submitter:  Orion Poplawski <opoplawski>
Submitted:  Thu 13 Mar 2025 03:02:21 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Fixed Assigned to:  None
Originator Name:  orion Open/Closed:  * Closed
Release:  * 10.0.90 Release: 
Operating System:  * GNU/Linux Fixed Release:  10.1.0
Planned Release:  10.1.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 13 Mar 2025 08:32:20 PM UTC, comment #12: 

I checked in change to update liboctave version to 12.0.0.  See https://hg.savannah.gnu.org/hgweb/octave/rev/ad86df9a9368.

Marking as Ready for Test.

I needed to blow away my current build directory ('make maintainer-clean') and start over with bootstrap script.

Rik <rik5>
Group administrator
Thu 13 Mar 2025 07:36:50 PM UTC, comment #11: 


comment #9:

> So it seems best to just set it to 12.0.0 and try to get it right in the future?


YES!  Setting the version to 12.0.0 results in the library name also ending in '.so.12.0.0'.  Libtool was doing the correct thing when we said the CURRENT version was 12 but AGE was 2, so it should be possible for programs to link to 'so.10'.

I'll make that change momentarily.

Rik <rik5>
Group administrator
Thu 13 Mar 2025 06:59:11 PM UTC, comment #10: 

This doesn't solve the problem here, but I think we should make the liboctave/module.mk file consistent with the others.

The prefix for Automake variables in the other libraries is


%canon_reldir_LIBRARYNAME_VARIABLES
For example
%canon_reldir%_liboctgui_la_CPPFLAGS


In liboctave, we re-use "%canon_reldir%" for the library name which happens to be correct because the directory is the same as the library name, but it is a little confusing.

I propose making changes like the one below:


-%canon_reldir%_%canon_reldir%_la_CPPFLAGS = \
+%canon_reldir%_liboctave_la_CPPFLAGS = \


See attached changeset.



(file #57011)

Rik <rik5>
Group administrator
Thu 13 Mar 2025 06:55:34 PM UTC, comment #9: 

So it seems best to just set it to 12.0.0 and try to get it right in the future?

John W. Eaton <jwe>
Group administrator
Thu 13 Mar 2025 06:49:06 PM UTC, comment #8: 

comment #6:

> Did we (I) make a mistake in updating the version during the 9.x release series?


Yes, that's a mistake.  I was reading the libtool manual trying to debug this issue, and I'm finally getting to some understanding of the numbering scheme.

Having the age at 0, as it was for the 9.1 release, says that the API is not compatible with anything less than "current".  In other words, everything with a MAJOR number less than 11 would need to be re-compiled to link against this library.  The bumping of age to 1, and then to 2, now implies that oct-files built with MAJOR-AGE (11-2 = 9) are still link-compatible with this library.

Rik <rik5>
Group administrator
Thu 13 Mar 2025 06:17:05 PM UTC, comment #7: 

Running "make V=1" and capturing the logs I can see that the link command for all of the ".la" versions of the libraries uses the "-version-info" flag correctly.

When creating the shared library the "-version-info" is not repeated.  The version number is entering through


-Wl,liboctave.so.10 -o liboctave/.libs/liboctave.so.10.2.0


All libraries have these two command-line options, but it is only liboctave where the version numbers are not the ones we specified.

It seems there must be some special instructions we are giving in liboctave/module.mk.

Rik <rik5>
Group administrator
Thu 13 Mar 2025 06:08:56 PM UTC, comment #6: 

Did we (I) make a mistake in updating the version during the 9.x release series?  I see the following:


.../9.1.0/liboctave.so.11.0.0
.../9.2.0/liboctave.so.11.0.1
.../9.3.0/liboctave.so.11.0.2
.../9.4.0/liboctave.so.11.0.2


but looking at the rules for updating versions


The rules for updating these version numbers are:

  * Start with the existing version information for each libtool library in
    the form `CURRENT:REVISION:AGE`.

  * Update the version information only immediately before a public release of
    the software.  This should happen at the time the first release candidate
    is made.  More frequent updates are unnecessary, and only guarantee that
    the current interface number gets larger faster.

  * If any interfaces have been added, removed, or changed since the last
    update, then increment current and set revision to 0 (`c:r:a` becomes
    `c+1:0:a`).

  * If current was _not_ incremented in the previous step, but the library
    source code has changed in any way since the last update, then increment
    revision (`c:r:a` becomes `c:r+1:a`).

  * If any interfaces have been added since the last public release, then
    increment age (`c:r:a` becomes `c:r:a+1`).

  * If any interfaces have been removed or changed since the last public
    release, then set age to 0 (`c:r:a` becomes `c:r:0`).


I don't see how age can be incremented without also incrementing current because age is supposed to be incremented if interfaces have been added, but if that happened, a previous rule should have caused current to be incremented.

John W. Eaton <jwe>
Group administrator
Thu 13 Mar 2025 05:44:04 PM UTC, comment #5: 

Confirming that the version 10 information really does seem to be embedded in the library


readelf -d liboctave.so.10.2.0 | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [liboctave.so.10]


Rik <rik5>
Group administrator
Thu 13 Mar 2025 05:23:09 PM UTC, comment #4: 

Looking quickly at libtool documentation.  There are two command-line options that are relevant: -release and -version-info.  The generated command is using -version-info which appears to be correct.  According to libtool manual:


If you want to use libtool’s versioning system, then you must specify the version information
to libtool using the -version-info flag during link mode (see Section 4.2 [Link mode],
page 19).
This flag accepts an argument of the form ‘current[:revision[:age]]’. So, passing
-version-info 3:12:1 sets current to 3, revision to 12, and age to 1.


Rik <rik5>
Group administrator
Thu 13 Mar 2025 04:01:19 PM UTC, comment #3: 

Sorry, the last verbatim block in the previous comment was missing some info.  It should have been


/bin/bash ./libtool  --tag=CXX   --mode=link g++ -fPIC -pthread -fopenmp -Wall -W -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -g -O2 -version-info 12:0:2  -bindir /usr/local/octave/10.0.90/bin    -o liboctave/liboctave.la -rpath /usr/local/octave/10.0.90/lib/octave/10.0.90 liboctave/liboctave_la-liboctave-build-info.lo liboctave/liboctave_la-version.lo liboctave/array/libarray.la liboctave/external/blas-xtra/libxerbla.la liboctave/external/ranlib/libranlib.la liboctave/external/libexternal.la liboctave/numeric/libnumeric.la liboctave/operators/liboperators.la liboctave/system/libsystem.la liboctave/util/libutil.la liboctave/wrappers/libwrappers.la libgnu/libgnu.la -lcurl  -lcholmod  -lumfpack  -lamd  -lcamd  -lcolamd  -lccolamd  -lcxsparse  -lsuitesparseconfig  -lspqr  -larpack  -lqrupdate -lblas -llapack  -lfftw3_threads -lfftw3  -lfftw3f_threads -lfftw3f  -llapack -lblas -lreadline  -lpcre2-8   -lpthread  -L/usr/lib/gcc/x86_64-linux-gnu/14 -L/usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/14/../../.. -lgfortran -lm -lquadmath -lpthread -lm                  -lreadline         -lpthread -lm
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/14/crtbeginS.o /usr/lib/gcc/x86_64-linux-gnu/14/crtoffloadbegin.o  liboctave/.libs/liboctave_la-liboctave-build-info.o liboctave/.libs/liboctave_la-version.o  -Wl,--whole-archive liboctave/array/.libs/libarray.a liboctave/external/blas-xtra/.libs/libxerbla.a liboctave/external/ranlib/.libs/libranlib.a liboctave/external/.libs/libexternal.a liboctave/numeric/.libs/libnumeric.a liboctave/operators/.libs/liboperators.a liboctave/system/.libs/libsystem.a liboctave/util/.libs/libutil.a liboctave/wrappers/.libs/libwrappers.a libgnu/.libs/libgnu.a -Wl,--no-whole-archive  -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -lspqr -larpack -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -llapack -lblas -lpcre2-8 -L/usr/lib/gcc/x86_64-linux-gnu/14 -L/usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/14/../../.. -lgfortran -lquadmath -lreadline -lstdc++ -lm -lgomp -lpthread -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/14/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/crtn.o /usr/lib/gcc/x86_64-linux-gnu/14/crtoffloadend.o  -fopenmp -g -O2   -pthread -fopenmp -Wl,-soname -Wl,liboctave.so.10 -o liboctave/.libs/liboctave.so.10.2.0


to show the libtool command and then the actual command libtool executes to build the library files.

John W. Eaton <jwe>
Group administrator
Thu 13 Mar 2025 03:58:52 PM UTC, comment #2: 

I just did a fresh build in a new completely empty build directory using the octave-10.0.90 tar file and I see the following files in liboctave/.libs in my build tree:


$ ls liboctave/.libs/
liboctave.la  liboctave.lai  liboctave_la-liboctave-build-info.o  liboctave_la-version.o  liboctave.so        liboctave.so.10  liboctave.so.10.2.0


but the liboctave.la file contains this info:


$ cat liboctave/.libs/liboctave.la
# liboctave.la - a libtool library file
# Generated by libtool (GNU libtool) 2.4.7 Debian-2.4.7-7
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='liboctave.so.10'

# Names of this library.
library_names='liboctave.so.10.2.0 liboctave.so.10 liboctave.so'

# The name of the static archive.
old_library=''

# Linker flags that cannot go in dependency_libs.
inherited_linker_flags=' -pthread -fopenmp'

# Libraries that this one depends upon.
dependency_libs=' -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -lspqr -larpack -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -llapack -lblas -lpcre2-8 -lgfortran -lquadmath -lreadline'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for liboctave.
current=12
age=2
revision=0

# Is this an already installed library?
installed=no

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/local/octave/10.0.90/lib/octave/10.0.90'


In the Makefile, I see


liboctave_liboctave_current = 12
liboctave_liboctave_revision = 0
liboctave_liboctave_age = 2
liboctave_liboctave_version_info = $(liboctave_liboctave_current):$(liboctave_liboctave_revision):$(liboctave_liboctave_age)
liboctave_liboctave_la_LDFLAGS = \
  -version-info $(liboctave_liboctave_version_info) \
  $(NO_UNDEFINED_LDFLAG) \
   \
  -bindir $(bindir) \
  $(LIBOCTAVE_LINK_OPTS) \
  $(WARN_LDFLAGS)


The only use of liboctave_liboctave_la_LDFLAGS is here:


liboctave_liboctave_la_LINK = $(LIBTOOL) $(AM_V_lt) --tag=CXX \
        $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=link $(CXXLD) \
        $(AM_CXXFLAGS) $(CXXFLAGS) $(liboctave_liboctave_la_LDFLAGS) \
        $(LDFLAGS) -o $@


and the only use of liboctave_liboctave_la_LINK is here:


) -rpath $(octlibdir) $(liboctave_liboctave_la_OBJECTS) $(liboctave_liboctave_la_LIBADD) $(LIBS)


I used "make V=1" and my log file of the build has this info about building liboctave.so:


/bin/bash ./libtool  --tag=CXX   --mode=link g++ -fPIC -pthread -fopenmp -Wall -W -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -fvisibility=hidden -g -O2 -version-info 12:0:2  -bindir /usr/local/octave/10.0.90/bin    -o liboctave/liboctave.la -rpath /usr/local/octave/10.0.90/lib/octave/10.0.90 liboctave/liboctave_la-liboctave-build-info.lo liboctave/liboctave_la-version.lo liboctave/array/libarray.la liboctave/external/blas-xtra/libxerbla.la liboctave/external/ranlib/libranlib.la liboctave/external/libexternal.la liboctave/numeric/libnumeric.la liboctave/operators/liboperators.la liboctave/system/libsystem.la liboctave/util/libutil.la liboctave/wrappers/libwrappers.la libgnu/libgnu.la -lcurl  -lcholmod  -lumfpack  -lamd  -lcamd  -lcolamd  -lccolamd  -lcxsparse  -lsuitesparseconfig  -lspqr  -larpack  -lqrupdate -lblas -llapack  -lfftw3_threads -lfftw3  -lfftw3f_threads -lfftw3f  -llapack -lblas -lreadline  -lpcre2-8   -lpthread  -L/usr/lib/gcc/x86_64-linux-gnu/14 -L/usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/14/../../.. -lgfortran -lm -lquadmath -lpthread -lm                  -lreadline         -lpthread -lm


Note that the 12:0:2 version info is passed to libtool but it generates an output file with 10.2.0.  Is that just what is supposed to happen when you use current=12 and age=2?  I admit I don't understand all the details about shared library versions, which is one of the reasons for using libtool.  If we are doing something wrong here, then I need someone with more knowledge about libtool and shared library versioning to tell me the right thing to do instead.

John W. Eaton <jwe>
Group administrator
Thu 13 Mar 2025 03:16:47 PM UTC, comment #1: 

Thanks for reporting this issue.  I see the same in the version I installed locally from the tar file but the stable sources have this info in the module.mk file for liboctave:


## Increment the following version numbers as needed and according
## to the rules in the etc/HACKING.md file:

%canon_reldir%_%canon_reldir%_current = 12
%canon_reldir%_%canon_reldir%_revision = 0
%canon_reldir%_%canon_reldir%_age = 2


So I'm not sure what is going wrong there but we'll fix it for the release.

John W. Eaton <jwe>
Group administrator
Thu 13 Mar 2025 03:02:21 PM UTC, original submission:  

Testing updating the Fedora octave package I notice the following soname changes:

liboctave.so.11 -> liboctave.so.10
liboctgui.so.12 -> liboctgui.so.13

The liboctave change does not appear correct to me - generally you expect an ever increasing number.

Orion Poplawski <opoplawski>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57011:  rename_liboctave.cset added by rik5 (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by opoplawski (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-03-18 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2025-03-13 rik5 StatusIn Progress Ready For Test
        Fixed ReleaseNone 10.1.0
        Planned ReleaseNone 10.1.0
    2025-03-13 rik5 Attached File- Added rename_liboctave.cset, #57011
    2025-03-13 jwe StatusConfirmed In Progress
    2025-03-13 jwe StatusNone Confirmed

    Back to the top

    Powered by Savane 3.14-962f.
    Corresponding source code