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:
Mamoru thank you once again for identifying the root cause.
Vít
[1]