Dne 07. 12. 21 v 13:20 Vít Ondruch napsal(a):
Dne 06. 12. 21 v 18:18 Vít Ondruch napsal(a):
>
> Dne 06. 12. 21 v 17:55 Vít Ondruch napsal(a):
>>
>> Dne 06. 12. 21 v 14:25 Mamoru TASAKA napsal(a):
>>> Mamoru TASAKA wrote on 2021/12/06 22:02:
>>>> Vít Ondruch wrote on 2021/12/06 20:07:
>>>>>
>>>>> Dne 03. 12. 21 v 21:36 Pavel Valena napsal(a):
>>>>>> On Fri, Dec 3, 2021 at 2:23 PM Vít Ondruch
<vondruch(a)redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Dne 03. 12. 21 v 13:40 Pavel Valena napsal(a):
>>>>>>>> On Fri, Dec 3, 2021 at 1:20 PM Vít Ondruch
>>>>>>>> <vondruch(a)redhat.com> wrote:
>>>>>>>>> Dne 03. 12. 21 v 11:47 Pavel Valena napsal(a):
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I've rebuilt it in my ruby-testing COPR:
>>>>>>>>>>
https://copr.fedorainfracloud.org/coprs/build/2999821
>>>>>>>>>>
>>>>>>>>>> And I'm also rebuilding dependent packages
(`ruby-devel` for
>>>>>>>>>> now) in
>>>>>>>>>> the rubygems-testing COPR:
>>>>>>>>>>
https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/builds/
>>>>>>>>>>
>>>>>>>>>> (starting with build 3000168)
>>>>>>>>> Nice, thx.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I'll let you know in case there're build
failures.
>>>>>>>>> There apparently are build failures.
>>>>>>>>>
>>>>>>>>> 1) It will probably need some bootstrap round, but
>>>>>>>> Sure, I'll run the builds several times & build
the most needed
>>>>>>>> packages manually (I also have a script for that; maybe
it
>>>>>>>> works).
>>>>>>>> Reliable build results will come after that.
>>>>>>>>
>>>>>>>>> 2) There seems to be something wrong with the binary
extensions:
>>>>>>>>>
>>>>>>>>>
https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testi...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That might be actually related to the issues I had
with
>>>>>>>>> building rbs and
>>>>>>>>> debug gems. I'll need to investigate.
>>>>>>>
>>>>>>> Interesting, trying eventmachine locally, it works ....
>>>>>> There may be newer versions of some gems in my COPR.
>>>>>
>>>>>
>>>>> That won't be the case, since eventmachine depends just on
>>>>> test-unit.
>>>>>
>>>>> Vít
>>>>>
>>>>
>>>>
https://download.copr.fedorainfracloud.org/results/mtasaka/ruby310-test/f...
>>>>
>>>>
>>>> ```
>>>> + find . -name mkmf.log
>>>> + xargs cat
>>>> LD_LIBRARY_PATH=.:/usr/lib64 pkg-config --exists openssl
>>>> LD_LIBRARY_PATH=.:/usr/lib64 pkg-config --libs openssl |
>>>> => "-lssl -lcrypto \n"
>>>> LD_LIBRARY_PATH=.:/usr/lib64 "gcc -o conftest -I/usr/include
>>>> -I/usr/include/ruby/backward -I/usr/include -I. -O2 -flto=auto
>>>> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
>>>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>>>> -Wp,-D_GLIBCXX_ASSERTIONS
>>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>>>> -fstack-protector-strong
>>>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
>>>> -fasynchronous-unwind-tables -fstack-clash-protection
>>>> -fcf-protection conftest.c -L. -L/usr/lib64 -Wl,-z,relro
>>>> -Wl,--as-needed -Wl,-z,now
>>>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
>>>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -lruby -lz
>>>> -lpthread -lrt -lrt -lgmp -ldl -lcrypt -lm -lm -lc"
>>>> /usr/bin/ld: cannot find -lz
>>>> /usr/bin/ld: cannot find -lgmp
>>>> collect2: error: ld returned 1 exit status
>>>> checked program was:
>>>> /* begin */
>>>> 1: #include "ruby.h"
>>>> 2:
>>>> 3: int main(int argc, char **argv)
>>>> 4: {
>>>> 5: return !!argv[argc];
>>>> 6: }
>>>> /* end */
>>>> ```
>>>>
>>>> -lz ? -lgmp?
>>>>
>>>> /usr/lib64/ruby/rbconfig.rb (in
>>>> ruby-libs-3.1.0-0.1.20211202gita84dc9d80d.fc36.x86_64) contains:
>>>> /usr/lib64/ruby/rbconfig.rb:82: CONFIG["MAINLIBS"] = "-lz
>>>> -lpthread -lrt -lrt -lgmp -ldl -lcrypt -lm "
>>>>
>>>> So perhaps this is the culprit. Currently it seems all non-noarch
>>>> builds fail.
>>>>
>>>
>>> Well, "-lz" and "-lgmp" also appears on
>>> ruby-libs-3.0.2-151.fc35.x86_64:
>>> 82: CONFIG["MAINLIBS"] = "-lz -lpthread -lrt -lrt -lgmp -ldl
>>> -lcrypt -lm "
>>>
>>> The "real" difference is perhaps that with ruby-libs-3.1.0-0.1,
>>> CONFIG["MAINLIBS"] is inherited by
>>> CONFIG["LIBRUBYARG_SHARED"].
>>>
>>> ruby-libs-3.1.0-0.1 CONFIG["LIBRUBYARG_SHARED"] says:
>>> CONFIG["LIBRUBYARG_SHARED"] = "-l$(RUBY_SO_NAME)
$(MAINLIBS)"
>>> ruby-libs-3.0.2 CONFIG["LIBRUBYARG_SHARED"] says:
>>> CONFIG["LIBRUBYARG_SHARED"] = "-l$(RUBY_SO_NAME)"
>>>
>>>
>>
>> Thank you for giving me a nudge. I was reusing the buildroot I had
>> used to build Ruby itself, so there were more libraries then
>> expected. Now I can reproduce locally.
>>
>>
>> Vít
>>
>
> So:
>
> 1) I have reported this upstream:
>
https://bugs.ruby-lang.org/issues/18391
>
> 2) For the time being, I'll try to revert the
>
https://github.com/ruby/ruby/pull/4632/commits/372d94b6ba73d85b2c63c70e87...
> or the whole PR.
The revert worked. But prior I was able to really test it, the issue
was fixed upstream [1] 😎.
Therefore the PR [2] was updated to the ec878dac90 and the scratch
build is running here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79676801
Mamoru thank you once again for identifying the root cause.
Vít
[1]
https://github.com/ruby/ruby/commit/ec878dac90df0ca5f39e72261b8d4e2898486a93
[2]
https://src.fedoraproject.org/rpms/ruby/pull-request/106
And disabling one offending test case on armv7hl, there is also
successful scratch build: