Vít Ondruch via ruby-sig wrote on 2025/01/08 20:28:
Dne 08. 01. 25 v 12:17 Mamoru TASAKA via ruby-sig napsal(a):
Vít Ondruch via ruby-sig wrote on 2025/01/08 0:46:
Hi everybody,
Ruby 3.4 is out and it is time for Ruby mass rebuild. First of all, I'd like to
thank to Mamoru for the preparation and lot of fixes all around. I really
appreciate that.
I think we are well prepared for the rebuild, therefore I have requested
side-tag:
~~~
$ fedpkg request-side-tag
Side tag 'f42-build-side-103200' (id 103200) created.
Use 'fedpkg build --target=f42-build-side-103200' to use it.
Use 'koji wait-repo f42-build-side-103200' to wait for the build repo to be
generated.
~~~
Ruby 3.4 is already merged [1] and build there:
https://koji.fedoraproject.org/koji/builds?inherited=0&tagID=103200&order=-build_id&latest=1
Packages which had depedency for libruby.so.3.3 previously are now succesfully
rebuilt,
except for rubygem-serialport , which is now tracked on:
https://bugzilla.redhat.com/show_bug.cgi?id=2329359
Now 86 pkgs (including ruby.src) have dependency for libruby.so.3.4,
and I think we are ready for merging into rawhide tree.
Thank you for you help! Much appreciated. I am going through my last round of
checks. For example now I am looking into ruby-devel depending packages and
specifically into libsolv. I always wonder why the Ruby binding does not have
the libruby.so dependency. In my experience, there are more packages like this.
Any clue? In the worst case, these will be soon rebuilt due to Fedora mass
rebuild, but I'd still like to understand.
Basically, (for example: xapian-bindings-ruby.x86_64 from xapian-bindings),
such package does not explicitly link against -lruby (intentionally?).
So such package (or .so files in such package) does not have dependency for
libruby.so
in terms of rpm dependency,
and has unresolved depdendency when trying to check by
$ ldd -r <such binary>:
[root@localhost ~]# rpm -q xapian-bindings-ruby
xapian-bindings-ruby-1.4.26-2.fc41.x86_64
[root@localhost ~]# ldd -r /usr/lib64/ruby/vendor_ruby/_xapian.so
linux-vdso.so.1 (0x00007ffc71faa000)
libxapian.so.30 => /lib64/libxapian.so.30 (0x00007f2c86200000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2c85e00000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2c86449000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2c85c0c000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2c8641a000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2c86410000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2c861de000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2c8662c000)
undefined symbol: rb_eArgError (/usr/lib64/ruby/vendor_ruby/_xapian.so)
undefined symbol: rb_eNoMemError (/usr/lib64/ruby/vendor_ruby/_xapian.so)
undefined symbol: rb_cFloat (/usr/lib64/ruby/vendor_ruby/_xapian.so)
undefined symbol: rb_eRangeError (/usr/lib64/ruby/vendor_ruby/_xapian.so)
undefined symbol: rb_eFatal (/usr/lib64/ruby/vendor_ruby/_xapian.so)
undefined symbol: rb_cNilClass (/usr/lib64/ruby/vendor_ruby/_xapian.so)
...
...
But this is "okay" in the meaning that such bindings are used through something
like
$ ruby -e 'require xapian'
then executing ruby (main) binary will load libruby.so.3.X at that time,
so after that trying to dlopen() _xapian.so will succeed because libruby.so.3.X
is
already loaded.
(So there surely is the opinion that such package should explicitly make
such binding linked aganist main library like libruby.so.)
(And of course, such binary will fail at "runtime" when soname changed
libruby.so removes
some symbols which such bindings required, not at "build time")
Vít
Mamoru
--
_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
