----- Original Message ----- > From: "Vít Ondruch" <vondr...@redhat.com> > To: ruby-sig@lists.fedoraproject.org > Sent: Friday, November 13, 2020 2:23:55 PM > Subject: Re: Ruby 3.0 > > > Dne 13. 11. 20 v 11:25 Mamoru TASAKA napsal(a): > > Mamoru TASAKA wrote on 2020/11/13 19:18: > >> Vít Ondruch wrote on 2020/11/13 17:46: > >>> > >>> Dne 13. 11. 20 v 3:56 Pavel Valena napsal(a): > >>>> ----- Original Message ----- > >>>>> From: "Pavel Valena" <pval...@redhat.com> > >>>>> To: "Dan Čermák" <dan.cer...@cgc-instruments.com> > >>>>> Cc: "Ruby SIG mailing list" <ruby-sig@lists.fedoraproject.org> > >>>>> Sent: Thursday, November 5, 2020 8:30:25 PM > >>>>> Subject: Re: Ruby 3.0 > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Dan Čermák" <dan.cer...@cgc-instruments.com> > >>>>>> To: "Vít Ondruch" <vondr...@redhat.com> > >>>>>> Cc: ruby-sig@lists.fedoraproject.org > >>>>>> Sent: Thursday, November 5, 2020 4:41:46 PM > >>>>>> Subject: Re: Ruby 3.0 > >>>>>> > >>>>>> Hi Vít, > >>>>>> > >>>>>> Vít Ondruch <vondr...@redhat.com> writes: > >>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> Here is once again freshly updated Ruby. The changes are > >>>>>>> available here: > >>>>>>> > >>>>>>> https://src.fedoraproject.org/rpms/ruby/pull-request/70 > >>>>>>> > >>>>>>> and you can find the scratch build in Koji: > >>>>>>> > >>>>>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=54978639 > >>>>>>> > >>>>>>> From the notable changes, there is ongoing effort to gemify > >>>>>>> StdLib. > >>>>>>> > >>>>>>> As always, please let me know if you encounter any issues with the > >>>>>>> package. > >>>> It seems I'm still not able to build gems like eventmachine: > >>> > >>> > >>> I wonder what precisely is "gems like eventmachine"
Sorry, I've made a mistake- eventmachine's error is different than before, and now it's the only one of this nature (AFAIK). Current stats: 113 failed-all.txt - all failed logs 29 failed-deps.txt - missing dependent packages (Ruby 3.0 rebuild) 3 failed-extens.txt - extensions could not be built 6 failed-rspec.txt - rspec could not be installed 75 failed-unknown.txt - unknown reason of failure (I'm doing automatic rebases on this set of packages as well, so the failure could be one of those) Now I'm working on those rspec ones (also testing enhanced rspec specs, which probably caused this failure, PRs comming), as well as on the 'unknown' errors. I'll keep you posted. > >>> > >>> > >>>> > >>>> https://download.copr.fedorainfracloud.org/results/pvalena/rubygems-testing/fedora-rawhide-x86_64/01767294-rubygem-eventmachine/builder-live.log.gz > >>>> https://copr.fedorainfracloud.org/coprs/pvalena/rubygems-testing/build/1767294/ > >>>> > >>>> Error I'm getting is > >>>> ``` make: I.: No such file or directory ``` > >>>> note the missing - > >>> > >>> > >>> I think the issue is not in the `-` but in what is missing prior it. > >>> If you see this line, isn't there something strange? Right, I didn't realize :). Sorry for not investigating first, but I didn't have enough time, and I wanted to give you feedback soon. > >>> > >>> ~~~ > >>> > >>> I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. > >>> -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL > >>> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL > >>> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T > >>> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT > >>> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 > >>> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL > >>> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW > >>> -DHAVE_CONST_CLOCK_MONOTONIC -fPIC -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 -m64 -o binder.o -c binder.cpp > >>> > >>> ~~~ > >>> > >>> > >>> For comparison, the same line from last official Fedora build: > >>> > >>> > >>> ~~~ > >>> > >>> g++ -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include > >>> -I. -DHAVE_OPENSSL_SSL_H -DHAVE_OPENSSL_ERR_H -DWITH_SSL > >>> -DBUILD_FOR_RUBY -DHAVE_RB_THREAD_CALL_WITHOUT_GVL > >>> -DHAVE_RB_THREAD_FD_SELECT -DHAVE_TYPE_RB_FDSET_T > >>> -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_TIME_NEW -DHAVE_INOTIFY_INIT > >>> -DHAVE_INOTIFY -DHAVE_WRITEV -DHAVE_PIPE2 -DHAVE_ACCEPT4 > >>> -DHAVE_CONST_SOCK_CLOEXEC -DOS_UNIX -DHAVE_EPOLL_CREATE -DHAVE_EPOLL > >>> -DHAVE_CLOCK_GETTIME -DHAVE_CONST_CLOCK_MONOTONIC_RAW > >>> -DHAVE_CONST_CLOCK_MONOTONIC -DHAVE_MAKE_PAIR -fPIC -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 -m64 -o binder.o -c binder.cpp > >>> > >>> ~~~ > >>> > >>> > >>> If you checked the Makefile, these are the corresponding lines: > >>> > >>> > >>> ~~~ > >>> > >>> .cpp.o: > >>> $(ECHO) compiling $(<) > >>> $(Q) $(CXX) $(INCFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(COUTFLAG)$@ > >>> -c $(CSRCFLAG)$< > >>> > >>> ~~~ > >>> > >>> > >>> And > >>> > >>> > >>> ~~~ > >>> > >>> CXX = > >>> > >>> ~~~ > >>> > >>> > >>> So one of the reasons is that we don't have C++ compiler available > >>> during Ruby build and therefore there are not stored the appropriate > >>> values into RbConfig (I mildly remember, that there could have been > >>> also patch to remove the need for C++ or it was reported somewhere, > >>> but I don't remember more details). > >>> > >>> The other reason is that somebody changed something somewhere and > >>> apparently something relies on it. The question is what. I would > >>> appreciate if somebody helped me to understand what have changed. > >>> > >>> One could also expect, that the extconf.rb + mkmf would include > >>> check for compiler availability and let the compilation fail > >>> earlier, but this is not the case unfortunately. So if somebody > >>> could investigate, if eventmachine and possibly also other package > >>> could check on compiler availability, that could help to prevent > >>> non-obvious issues like this. Yes, that's strange, I know there was such a check, let me investigate. > >>> > >>> Checking the mkmf.log, it is also interesting to see, that most of > >>> the configuration check are done using `gcc`, while there also other > >>> checks: > >>> > >>> ~~~ > >>> > >>> " -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 -L. -Wl,-z,relro > >>> -Wl,--as-needed -Wl,-z,now > >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > >>> -fstack-protector-strong -rdynamic -Wl,-export-dynamic -m64 -lssl > >>> -lcrypto -lcrypto -lssl -lruby -Wall -lm -lc" > >>> checked program was: > >>> /* begin */ > >>> 1: #include "ruby.h" > >>> 2: > >>> 3: int main() {return 0;} > >>> /* end */ > >>> > >>> ~~~ > >>> > >>> They are missing the `gcc` on the beginning and they appears to be > >>> silently ignored. But these corresponds to: > >>> > >>> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7ce1d8fe7176d4d14d/ext/extconf.rb#L274 > >>> > >>> > >>> https://github.com/eventmachine/eventmachine/blob/b50c135dfdd4e7b20c8e0b7ce1d8fe7176d4d14d/ext/extconf.rb#L281 > >>> > >>> > >>> So these are somehow expected to fail, but they should probably fail > >>> in different way. > >>> > >>> > >>> Vít > >>> > >> > >> So CONFIG["CXX"] is not yet set ( in /usr/lib64/ruby/rbconfig.rb on > >> x86_64) (see: > >> https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/message/HJHP53TYDQ2NTWZB3WDNL6X4RCVYRAID/ > >> > >> ) and still rubygem-eventmachine fails to find CXX compiler, while > >> rawhide ruby-libs rpm has CONFIG["CXX"] value. > > > > Thx for reminder :) > > > > Apparently this commit changed CXX value: > > https://github.com/ruby/ruby/commit/50b18e81295ad2d45975e4d8ea1e0c7e85140b97 > > > > > This kind of commits does not make me happy :( While the intention is > good, they don't take into consideration any distribution. It is > tailored to the old fashion way of "download tarball & configure & make > & make install", everything runs on single machine :/ > > Does anybody have a tip how to convince upstream, that this does not > scale? Does anybody want to ask upstream to revert this commit on my behalf? Sure, I can do the poking. I'll CC you as well. Thanks all for the analysis! Regards, Pavel > > > Vít > > > > > > Regards, > > 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
