Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2222614 - xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: iso_write_opts_set_max_ce_entries, version LIBISOFS6
Summary: xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: iso_w...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libisoburn
Version: 39
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Robert Scheck
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-13 10:00 UTC by Robert Scheck
Modified: 2024-03-23 00:26 UTC (History)
5 users (show)

Fixed In Version: libisoburn-1.5.6-5.el7 libisoburn-1.5.6-5.fc39 libisoburn-1.5.6-5.fc38 libisoburn-1.5.6-5.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-03-12 00:40:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Robert Scheck 2023-07-13 10:00:56 UTC
xorriso in Rawhide fails to work because of a missing symbol in libisoburn:

$ xorriso --help
xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: iso_write_opts_set_max_ce_entries, version LIBISOFS6

xorriso-1.5.6-1.fc39.x86_64
libisoburn-1.5.6-1.fc39.x86_64

Reproducible: Always

Comment 1 Robert Scheck 2023-07-13 10:02:23 UTC
Originally reported by Richard W.M. Jones at bug #2216134 comment #13

Comment 2 Thomas Schmitt 2023-07-13 10:45:31 UTC
Hi,

iso_write_opts_set_max_ce_entries is provided by libisofs-1.5.6
and advertised in its libisofs/libisofs.ver file.

The installed libisofs.so seems not to provide this symbol and thus
appears to be outdated.
The source tarball of libisofs-1.5.6 is supposed to produce
  libisofs.so.6.92.0
This page agrees:
  https://packages.fedoraproject.org/pkgs/libisofs/libisofs/fedora-rawhide.html#files

So is your libisofs.so.6 a link to this file ?

Do you get at least one match reported from this run:

  strings /usr/lib64/libisofs.so.6.92.0 | grep iso_write_opts_set_max_ce_entries 

The upstream source version is not to see as text in the .so file, i fear.
It is handed out to callers as three integer numbers.

The numbers are defined in the file
  /usr/include/libisofs/libisofs.h
of the libisofs-devel package that was used to produce libisofs.so.
They are supposed to have been:

  #define iso_lib_header_version_major  1
  #define iso_lib_header_version_minor  5
  #define iso_lib_header_version_micro  6

(I wonder why libisofs-devel provides file
   /usr/lib64/libisofs.so
which i would have expected with the libisofs package. If you have it
installed then check whether it finally points to libisofs.so.6.92.0 .)

Have a nice day :)

Thomas

Comment 3 Robert Scheck 2023-07-13 10:53:38 UTC
> The source tarball of libisofs-1.5.6 is supposed to produce libisofs.so.6.92.0

- libisofs-1.5.6-1.fc39.x86_64.rpm provides /usr/lib64/libisofs.so.6 and /usr/lib64/libisofs.so.6.92.0, see: https://koji.fedoraproject.org/koji/rpminfo?rpmID=34805992
- libisofs-devel-1.5.6-1.fc39.x86_64.rpm provides /usr/lib64/libisofs.so, see: https://koji.fedoraproject.org/koji/rpminfo?rpmID=34805996
- /usr/lib64/libisofs.so and /usr/lib64/libisofs.so.6 are boths symlinks to /usr/lib64/libisofs.so.6.92.0 and comply with Fedora Packaging Guidelines

> strings /usr/lib64/libisofs.so.6.92.0 | grep iso_write_opts_set_max_ce_entries

$ strings /usr/lib64/libisofs.so.6.92.0 | grep iso_write_opts_set_max_ce_entries 
iso_write_opts_set_max_ce_entries
$ 

Additionally, I am unable to reproduce this issue in a container with Fedora Rawhide. Sorry, Thomas for bothering you!

Richard, your report does not include the version of libisofs, could you provide this one as well, please? Is it possible that the local system is somehow screwed up?

Comment 4 Richard W.M. Jones 2023-07-13 10:56:46 UTC
I actually have:

libisofs-1.5.4-5.fc38.x86_64

Let me upgrade that ...

Comment 5 Richard W.M. Jones 2023-07-13 10:58:02 UTC
I now have:
xorriso-1.5.6-1.fc39.x86_64
libisoburn-1.5.6-1.fc39.x86_64
libisofs-1.5.6-1.fc39.x86_64

but I still see a problem (slightly different this time):

$ xorriso --version
xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: burn_write_opts_set_bdr_obs_exempt, version LIBBURN4

Comment 6 Richard W.M. Jones 2023-07-13 11:00:10 UTC
There is also libburn:

libburn-1.5.4-6.fc38.x86_64

Upgrading to:

libburn-0:1.5.6-1.fc39.x86_64

FIXES the problem.  I wonder if it'd be better to use some versioned
Requires lines in xorriso.spec?  Or else get upstream to use proper
symbol versioning (they seem to be using some half-assed versioning).

Comment 7 Thomas Schmitt 2023-07-13 11:35:29 UTC
Hi,

Richard W.M. Jones wrote:
> libisofs-1.5.4-5.fc38.x86_64
> libburn-1.5.4-6.fc38.x86_64

So the "symbol lookup error" comes before the internal tests of libisoburn
and xorriso get an opportunity to complain about insufficiently modern
libisofs and libburn.

But shouldn't the package system know that libisoburn-1.5.6 wants the
1.5.6 versions of the underlying companion libraries ?


> Or else get upstream to use proper
> symbol versioning (they seem to be using some half-assed versioning).

There is only one version strain libisofs.so.6 which is kept compatible
for older API/ABI users.
The .ver files of libisoburn, libisofs, and libburn were introduced mainly
to prevent rogue function calling which circumvented the defined API and
accessed internal functions from outside the library.

A first version check happens at compile time of libisoburn which would
fail if not the development headers of the needed libisofs and libburn
versions are included.
Another version check happens at run time when the library gets
initialized. But this check is not reached because the library loader
already prevented the program start.

If you can point me to docs or examples how to let the error message
tell something like "LIBISOFS.6.91.0/1.5.4" instead of "LIBISOFS6" then
i will consider to improve the .ver files.

Have a nice day :)

Thomas

Comment 8 Robert Scheck 2023-07-13 11:50:29 UTC
RPM creates automatic dependencies for soname versions, like *.so.6. From my understanding if you break/change ABI, you should bump the soname version, e.g. to *.so.7.

Comment 9 Richard W.M. Jones 2023-07-13 11:54:10 UTC
Every time you add a new symbol to the library you should version it with
the version where it appears.  Here's an example from libvirt:

https://github.com/libvirt/libvirt/blob/master/src/libvirt_public.syms

Dan wrote about that here:

https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/

Comment 10 Richard W.M. Jones 2023-07-13 11:56:35 UTC
There's no need to bump the SONAME, in fact that would be wrong since these are
not breaking changes.  Simple symbol versioning can cope with this.

Comment 11 Robert Scheck 2023-07-13 12:23:04 UTC
Thank you for correcting me! :)

Comment 12 Thomas Schmitt 2023-07-13 13:02:23 UTC
Hi,

Robert Scheck wrote:
> From my
> understanding if you break/change ABI, you should bump the soname version,
> e.g.  to *.so.7.

The ABI is not broken but only expanded. New functions get in, but old
function stay and keep their parameter prototypes and the meaning of old
parameter tuples.

If i'd bump the SONAME then old applications like Xfburn would need to
stay with the old library versions. As it is now, Xfburn made for
libisofs-1.4.8 can use the new libisofs and benefit from possible bug
fixes of old API functions.


Richard W.M. Jones wrote:
> Every time you add a new symbol to the library you should version it with
> the version where it appears.

I will study the given links and try to improve.

-------------------------------------------------------------------------

But in any case i advise to let the package manager know about the version
demands of libisoburn towards libisofs and libburn. Especially since the
code enforces sufficiently new versions at run time even if no symbols
are missing.
You may generally assume that the needed versions are those which were
released together with libisoburn. I.e demand equal or higher than the
own version of libisoburn.

Caveat:
Recompiling with the devel headers of new libburn and libisofs causes in
old libisoburn the need for the new libisofs.so and libburn.so.

Have a nice day :)

Thomas

Comment 13 Robert Scheck 2023-07-13 13:08:14 UTC
(In reply to Thomas Schmitt from comment #12)
> But in any case i advise to let the package manager know about the version
> demands of libisoburn towards libisofs and libburn. Especially since the
> code enforces sufficiently new versions at run time even if no symbols
> are missing.

If you expose the symbols like at libvirt, they'll make it into the RPM, see e.g. https://koji.fedoraproject.org/koji/rpminfo?rpmID=34946998

Comment 14 Richard W.M. Jones 2023-07-13 13:28:38 UTC
> If you expose the symbols like at libvirt, they'll make it into the RPM, see e.g.
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=34946998

Exactly this, yes.  There are still some tricky cases with symbol versioning, but
for this case where you're just adding a new API then it will work and RPM will
do the right thing.

Comment 15 Thomas Schmitt 2023-07-14 07:52:55 UTC
Hi,

i tested the following change in the libisofs/libisofs.ver file of the
development version of libisofs. It moves the four new API symbols of
release 1.5.6 into a new node "LIBISOFS6_1.5.6".

Although i cannot find an explicit statement in
  https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_chapter/ld_3.html#SEC25
that old programs can stand such a move, i get no error when running
a xorriso binary that was made when all symbols were in node "LIBISOFS6".
(I verified by removal that it really wants to link the new experimental
libisofs.)

Nevertheless i am still reluctant to publish this back-in-time change
with the next libisofs release. Unless i see explicit confirmation that
it is indeed supposed to work for programs which had seen the library
stemming from the old .ver file, i would prefer to begin adding new linker
script nodes only with the next release and to keep the four new API
symbols of 1.5.6 in the old "LIBISOFS6" node.

(If it is indeed specified to work with retroactively changed version
nodes, then i would be able to reflect the API history back to version
0.6.2 of 2008. Question is whether this is desirable and worth any risk.)

Do you have means to test whether the change to libisofs.ver will indeed
cause a resulting libisoburn RPM to demand the installation of the
libisofs-1.5.6 RPM ?
It works fine: Can you add the change as patch to Fedora ?

Next libisofs release is not expected to come soon.

Have a nice day :)

Thomas

--- libisofs/libisofs.ver.C30714        2023-07-14 08:57:18.499926315 +0200
+++ libisofs/libisofs.ver       2023-07-14 09:11:10.591929457 +0200
@@ -21,7 +21,6 @@ el_torito_set_load_seg;
 el_torito_set_load_size;
 el_torito_set_no_bootable;
 el_torito_set_selection_crit;
-iso_assess_written_features;
 iso_conv_name_chars;
 iso_crc32_gpt;
 iso_data_source_new_from_file;
@@ -230,7 +229,6 @@ iso_node_xinfo_make_clonable;
 iso_node_zf_by_magic;
 iso_nowtime;
 iso_obtain_msgs;
-iso_read_image_feature_named;
 iso_read_image_features_destroy;
 iso_read_image_features_get_size;
 iso_read_image_features_has_eltorito;
@@ -238,7 +236,6 @@ iso_read_image_features_has_iso1999;
 iso_read_image_features_has_joliet;
 iso_read_image_features_has_rockridge;
 iso_read_image_features_rr_loaded;
-iso_read_image_features_text;
 iso_read_image_features_tree_loaded;
 iso_read_opts_auto_input_charset;
 iso_read_opts_free;
@@ -350,7 +347,6 @@ iso_write_opts_set_joliet_long_names;
 iso_write_opts_set_joliet_longer_paths;
 iso_write_opts_set_joliet_utf16;
 iso_write_opts_set_max_37_char_filenames;
-iso_write_opts_set_max_ce_entries;
 iso_write_opts_set_ms_block;
 iso_write_opts_set_no_force_dots;
 iso_write_opts_set_old_empty;
@@ -384,3 +380,12 @@ iso_zisofs_set_params;
 serial_id;
 local: *;
 };
+
+LIBISOFS6_1.5.6 {
+global:
+iso_assess_written_features;
+iso_read_image_feature_named;
+iso_read_image_features_text;
+iso_write_opts_set_max_ce_entries;
+} LIBISOFS6;
+

Comment 16 Daniel Berrangé 2023-07-14 08:32:15 UTC
(In reply to Thomas Schmitt from comment #15)
> Hi,
> 
> i tested the following change in the libisofs/libisofs.ver file of the
> development version of libisofs. It moves the four new API symbols of
> release 1.5.6 into a new node "LIBISOFS6_1.5.6".
> 
> Although i cannot find an explicit statement in
>   https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_chapter/ld_3.html#SEC25
> that old programs can stand such a move, i get no error when running
> a xorriso binary that was made when all symbols were in node "LIBISOFS6".

Moving symbols between version nodes is *NOT* backwards compatible, and
is equivalent to an ABI break.

The possible combinations are as follows

 * Lib has no sym version, app has no sym version -> OK
 * Lib has no sym version, app has sym version A -> FAIL (can't remove sym versions from an existing library that an app has linked to)
 * Lib has sym version A, app has no sym version ->  OK  (this lets you add sym version to a existing library without breaking existing apps)
 * Lib has sym version A, app has sym version A -> OK  (versions match)
 * Lib has sym version A, app has sym version B -> FAIL (can't change sym versions in a library that an app has linked to)

NB, when I say "app" above, it could also just be another library.


WRT you testing xorriso binary, while that binary links to libisofs.so, it only does so indirectly via libisoburn.so, and that's what has the versioned symbol references.


Picking one arbitrary function 'iso_read_image_features_has_rockridge', we see the exported symbol in libisofs.so:

$ eu-readelf -a /usr/lib64/libisofs.so.6 | grep GLOBAL | grep iso_read_image_features_has_rockridge
  407: 000000000001d670     12 FUNC    GLOBAL DEFAULT       14 iso_read_image_features_has_rockridge@@LIBISOFS6


and see the corresponding usage in libisoburn.so:

$ eu-readelf -a /usr/lib64/libisoburn.so.1 | grep UNDEF | grep iso_read_image_features_has_rockridge
   10: 0000000000000000      0 FUNC    GLOBAL DEFAULT    UNDEF iso_read_image_features_has_rockridge@LIBISOFS6 (3)

and nothing in xorriso at all

$ eu-readelf -a /usr/bin/xorrisofs  | grep UNDEF | grep ISOFS

Merely running xorrisofs might not show the symbol breakage unless you exercise a code path that uses the symbol in question, as LD will lazy-resolve symbols

Setting the env variable 'LD_BIND_NOW=1' will force ld.so to resolve all symbols immediately at startup instead of on-demand.


> Nevertheless i am still reluctant to publish this back-in-time change
> with the next libisofs release. Unless i see explicit confirmation that
> it is indeed supposed to work for programs which had seen the library
> stemming from the old .ver file, i would prefer to begin adding new linker
> script nodes only with the next release and to keep the four new API
> symbols of 1.5.6 in the old "LIBISOFS6" node.

Yes that is the correct thing to do. Once a mistake has been made with the symbol addition that has gone into a formal release, it needs to be preserved to maintain ABI compatibility

Comment 17 Thomas Schmitt 2023-07-14 09:31:58 UTC
Hi,

Daniel Berrangé wrote:
> Moving symbols between version nodes is *NOT* backwards compatible, and
> is equivalent to an ABI break.

That's not what i see in my experiment of today, but it matches my
scruples.

> WRT you testing xorriso binary, while that binary links to libisofs.so, it
> only does so indirectly via libisoburn.so, and that's what has the versioned
> symbol references.

Not in my experiment. libisoburn and xorriso were not recompiled after
i changed libisofs.ver and installed the resulting library.
Either the change did not come into effect (despite new timestamps of
libisofs.so.6.92.0 and confirmation that xorriso does not start without
that file) or on my Debian the checking is not as strict as supposed.

> Setting the env variable 'LD_BIND_NOW=1' will force ld.so to resolve all
> symbols immediately at startup instead of on-demand.

The error message which triggered this bug report indicates that the
symbol iso_write_opts_set_max_ce_entries was attempted to be loaded
long before a call to that function was attempted.
This astonished me, because i am used to the internal version check
reporting an error at startup if libisofs version does not match.
Can it be that LD_BIND_NOW=1 was in effect when Richard W.M. Jones
encountered the error ?

Whatever, your description and my scruples match. I will not publish
libisofs.ver with the retroactive node LIBISOFS6_1.5.6 but only change
my cheat sheet so that the next new symbol gets into LIBISOFS6_1.5.8.
(1.5.7 is a development version not intended to be released.)

-----------------------------------------------------------------------

So there remains the Fedora specific problem that the libisoburn-1.5.6
RPM does not demand libisofs-1.5.6 and libburn-1.5.6.
I am curious how this can be solved.

Further i wonder how i would talk RPM production into demanding the next
version libisofs-1.5.8 if no new symbols would be added to 1.5.8, but
some backward compatible parameter change would have happened.
In libisofs-1.5.6 changelog there is

  * New iso_write_opts_set_system_area() option bits 16:
    GPT "Legacy BIOS bootable" and 17: GPT writable

and in the API description libisofs.h:

 * @param options
 *        Can cause manipulations of submitted data before they get written:
 [...]
 *        bit16= "Legacy BIOS bootable" in GPT
 *              @since 1.5.6
 *              If this bit is set and a GPT partition for the ISO 9660
 *              filesystem gets written, then set the GPT partition flags bit 2
 *              "Legacy BIOS bootable".
 *        bit17= ISO not read-only
 *              @since 1.5.6
 *              Do not set GPT partition flag bit 60 "read-only" for the
 *              ISO 9660 filesystem partition, if such a partition gets
 *              written.

If xorriso sends these bits to libisofs-1.5.4, then the desired effects
would silently not happen.

To prevent such misconfiguration, the run-time check of libisoburn would
refuse to let it start.
Example:
After changing the softlink libisofs.so.6 to point to the next older
version libisofs.so.6.91.0 i get this:

  $ xorriso -version
  xorriso 1.5.6 : RockRidge filesystem manipulator, libburnia project.

  xorriso : FATAL : Cannot initialize libraries. Reason given:
  libjte-2.0.0 ok, libisofs-1.5.5 - TOO OLD -, need at least libisofs-1.5.7 ,
  libburn-1.5.7 ok, for libisoburn-1.5.6

(libjte is a specialty of Debian and brought in at compile time only when
its development header and .so exist.)

In the end i still think that the RPM building process needs to know
what dependencies are prescribed in the upstream README and enforced in
the code rather than to rely on the linker script which seems not able to
express all my development habits.

Have a nice day :)

Thomas

Comment 18 Daniel Berrangé 2023-07-14 10:38:48 UTC
(In reply to Thomas Schmitt from comment #17)
> > WRT you testing xorriso binary, while that binary links to libisofs.so, it
> > only does so indirectly via libisoburn.so, and that's what has the versioned
> > symbol references.
> 
> Not in my experiment. libisoburn and xorriso were not recompiled after
> i changed libisofs.ver and installed the resulting library.
> Either the change did not come into effect (despite new timestamps of
> libisofs.so.6.92.0 and confirmation that xorriso does not start without
> that file) or on my Debian the checking is not as strict as supposed.

So I've just done a test as follows..

From a 1.5.6 release I applied this change to move a random pile of symbols:

diff --git a/libisofs/libisofs.ver b/libisofs/libisofs.ver
index 7216da6..0683b29 100644
--- a/libisofs/libisofs.ver
+++ b/libisofs/libisofs.ver
@@ -170,6 +170,10 @@ iso_local_get_perms_wo_acl;
 iso_local_set_acl_text;
 iso_local_set_attrs;
 iso_local_set_attrs_errno;
+local: *;
+};
+
+LIBISOFS6_FISH {
 iso_md5_clone;
 iso_md5_compute;
 iso_md5_end;
@@ -382,5 +386,4 @@ iso_zisofs_get_params;
 iso_zisofs_get_refcounts;
 iso_zisofs_set_params;
 serial_id;
-local: *;
-};
+} LIBISOFS6;


Then built the binary as normal

  ./configure
  make

We can see a symbol has got a new version "LIBISOFS6_FISH"

$ eu-readelf -a libisofs/.libs/libisofs.so | grep GLOBAL | grep iso_read_opts_set_default_gid
  183: 000000000001cc30     20 FUNC    GLOBAL DEFAULT       13 iso_read_opts_set_default_gid@@LIBISOFS6_FISH

and when I try to run xorriso bniary it fails

$ LD_LIBRARY_PATH=./libisofs-1.5.6/libisofs/.libs/ xorriso
xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: iso_read_opts_set_default_gid, version LIBISOFS6

And can see that libisoburn.so wants the old version

$ eu-readelf -a /lib64/libisoburn.so.1 | grep iso_read_opts_set_default_gid | grep UNDEF
    2: 0000000000000000      0 FUNC    GLOBAL DEFAULT    UNDEF iso_read_opts_set_default_gid@LIBISOFS6 (3)


> 
> So there remains the Fedora specific problem that the libisoburn-1.5.6
> RPM does not demand libisofs-1.5.6 and libburn-1.5.6.
> I am curious how this can be solved.

Fedora just needs to put explicit manual versioned deps on the RPMs in question

Comment 19 Thomas Schmitt 2023-07-14 11:22:19 UTC
Hi,

Daniel Berrangé wrote:
> Fedora just needs to put explicit manual versioned deps on the RPMs in
> question

Now we only have to convince Robert and Richard. :))


> iso_local_set_attrs_errno;
> +local: *;
> +};
> +
> +LIBISOFS6_FISH {
>  iso_md5_clone;
> [...]
> +} LIBISOFS6;

This fails here too.
A bit differently, probably because of the obviously lazy loading:

  .../xorriso: relocation error: .../libisoburn.so.1: symbol iso_text_to_sev,
  version LIBISOFS6 not defined in file libisofs.so.6 with link time reference

But if i re-install my experimental change as in comment 15, ./configure,
make, make install, then i get a work-willing xorriso. xorriso and
libisoburn are still not re-compiled or re-installed since the experiments
began.

So i assume that the lazy loading creates the illusion of compatibility.
And indeed, if i trigger the use of the new function by

  .../xorriso -compliance max_ce_entries=16 -outdev test.iso -map x /x

i get the expected error

  .../xorriso: relocation error: .../libisoburn.so.1:
  symbol iso_write_opts_set_max_ce_entries, version LIBISOFS6 not defined
  in file libisofs.so.6 with link time reference

Thanks for enlightening me.

Have a nice day :)

Thomas

Comment 20 Robert Scheck 2023-07-15 16:03:30 UTC
(In reply to Thomas Schmitt from comment #19)
> Now we only have to convince Robert and Richard. :))

As the package maintainer of libburnia in Fedora, I do not have an issue to add (run-time) requirements on package versions if its needed for some technical reasons, but I still wonder if soname versioning and symbols etc. shouldn't do the trick on upstream side, like they do for "all" other packages? Maybe I'm too less a developer to understand why it doesn't work here? Could you clarify if the expected requirements between the libburnia packages should be just "equal" or "equal or greater than" (assume the latter)? For the -devel packages, its "equal or greater than".

Comment 21 Thomas Schmitt 2023-07-16 08:53:22 UTC
Hi,

Robert Scheck wrote:
> I still wonder if soname versioning and symbols etc. shouldn't do
> the trick on upstream side

Daniel Berrangé explained and demonstrated why it is not advisable to
retroactively change the linker script libisofs.ver so that the new
symbols of 1.5.6 would appear in an own node.
My own experiments were a bit obscured by symbol loading on demand
but in the end i got the same load error when asking xorriso to do some
real work.
(I now addedd LD_BIND_NOW=1 to all my development test runs of xorriso
and cdrskin which shall check whether the binaries start up. Luckily
i never made a mistake in libisofs.ver which would have slipped through
this loophole.)

Fedora could decide that libisofs-1.5.6 is fresh enough to make the
change of comment 15 in libisofs.ver and to rebuild all packages which
depend on libisofs.
But this would make libisofs-1.5.6 in Fedora unusable for all programs
which were compiled with upstream libisofs-1.5.6.

> Could you clarify if the expected requirements between the libburnia
> packages should be just "equal" or "equal or greater than" (assume the
> latter)? For the -devel packages, its "equal or greater than".

Currently the right setting is "equal or greater than 1.5.6" for libisofs
and libburn.
Quite a safe and surely a convenient bet would be "equal or greater than
the own libisoburn version", if that is possible.

In general i release libisofs, libburn, and libisoburn as bundle with
the same version numbers. In theory it is possible that not a single
novelty would be to publish in libisofs or libburn.
In that case i would have to ponder whether to omit the release of that
library and to keep the dependency demand of libisoburn at the old version
number. If i decide so, then the package maintainer of libisoburn would
notice when trying to build it.

I have to stress again, that libisoburn.so internally stores the version of
the libisofs.h and libburn.h headers seen at compile time and will refuse
to start with lower versions of the .so libraries even if those lower
versions would suffice.
See the refusal example in comment 17 where libisoburn-1.5.6 had seen the
newest development headers and thus demands version 1.5.7:

  xorriso : FATAL : Cannot initialize libraries. Reason given:
  libjte-2.0.0 ok, libisofs-1.5.5 - TOO OLD -, need at least libisofs-1.5.7 ,
  libburn-1.5.7 ok, for libisoburn-1.5.6

(Actually the example was posted to show what happens if a really outdated
libisofs is encountered.)

Have a nice day :)

Thomas

Comment 22 Thomas Schmitt 2023-07-16 10:04:12 UTC
Hi,

thinking more about it, my upstream idea of dependencies is best matched
by:

For the -devel packages of libisofs and libburn: "equal".
For the runtime libraries: "equal or greater".

Of course the maintainance needs of a distro might prefer "or greater"
for recompiling. In that case the runtime demand must be adjusted to the
version of the actually used development headers.

Have a nice day :)

Thomas

Comment 23 Fedora Release Engineering 2023-08-16 08:12:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 24 Fedora Update System 2024-03-03 12:55:22 UTC
FEDORA-EPEL-2024-4043d91825 (libisoburn-1.5.6-5.el7) has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4043d91825

Comment 25 Fedora Update System 2024-03-03 12:55:24 UTC
FEDORA-EPEL-2024-0577296243 (libisoburn1-1.5.6-5.el8) has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0577296243

Comment 26 Fedora Update System 2024-03-03 12:55:24 UTC
FEDORA-2024-6f3b8b1d39 (libisoburn-1.5.6-5.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-6f3b8b1d39

Comment 27 Fedora Update System 2024-03-03 12:55:25 UTC
FEDORA-2024-81ce31f2d2 (libisoburn-1.5.6-5.fc38) has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-81ce31f2d2

Comment 28 Fedora Update System 2024-03-04 01:20:42 UTC
FEDORA-EPEL-2024-4043d91825 has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4043d91825

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 29 Fedora Update System 2024-03-04 01:24:33 UTC
FEDORA-EPEL-2024-0577296243 has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0577296243

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 30 Fedora Update System 2024-03-04 01:58:07 UTC
FEDORA-2024-1cf1c2f170 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1cf1c2f170`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1cf1c2f170

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 31 Fedora Update System 2024-03-04 02:07:02 UTC
FEDORA-2024-6f3b8b1d39 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6f3b8b1d39`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6f3b8b1d39

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 32 Fedora Update System 2024-03-04 02:25:05 UTC
FEDORA-2024-81ce31f2d2 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-81ce31f2d2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-81ce31f2d2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 33 Fedora Update System 2024-03-12 00:40:45 UTC
FEDORA-EPEL-2024-4043d91825 (libisoburn-1.5.6-5.el7) has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 34 Fedora Update System 2024-03-12 01:01:48 UTC
FEDORA-EPEL-2024-0577296243 (libisoburn1-1.5.6-5.el8) has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 35 Fedora Update System 2024-03-19 01:09:46 UTC
FEDORA-2024-6f3b8b1d39 (libisoburn-1.5.6-5.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 36 Fedora Update System 2024-03-19 01:59:44 UTC
FEDORA-2024-81ce31f2d2 (libisoburn-1.5.6-5.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 37 Fedora Update System 2024-03-23 00:26:40 UTC
FEDORA-2024-1cf1c2f170 (libisoburn-1.5.6-5.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.