----- Original Message ----- > From: "Pavel Valena" <[email protected]> > To: "Ruby SIG mailing list" <[email protected]> > Sent: Friday, November 13, 2020 9:39:36 PM > Subject: Re: Ruby 3.0 > > ----- Original Message ----- > > From: "Vít Ondruch" <[email protected]> > > To: [email protected] > > 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" <[email protected]> > > >>>>> To: "Dan Čermák" <[email protected]> > > >>>>> Cc: "Ruby SIG mailing list" <[email protected]> > > >>>>> Sent: Thursday, November 5, 2020 8:30:25 PM > > >>>>> Subject: Re: Ruby 3.0 > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Dan Čermák" <[email protected]> > > >>>>>> To: "Vít Ondruch" <[email protected]> > > >>>>>> Cc: [email protected] > > >>>>>> Sent: Thursday, November 5, 2020 4:41:46 PM > > >>>>>> Subject: Re: Ruby 3.0 > > >>>>>> > > >>>>>> Hi Vít, > > >>>>>> > > >>>>>> Vít Ondruch <[email protected]> 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. >
Additionally, 'st.h' is missing for rubygem-ruby-libvirt: https://copr.fedorainfracloud.org/coprs/build/1768458 gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -DRUBY_EXTCONF_H=\"extconf.h\" -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 common.o -c common.c common.c:27:10: fatal error: st.h: No such file or directory 27 | #include <st.h> | ^~~~~~ > > >>> > > >>> ~~~ > > >>> > > >>> 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/[email protected]/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 > > > -- Pavel Valena Software Engineer, Red Hat Brno, Czech Republic _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
