From: Jeremy Evans Date: 2011-07-28T09:50:25+09:00 Subject: [ruby-core:38572] [Ruby 1.9 - Feature #5097] Supported platforms of Ruby 1.9.3 Issue #5097 has been updated by Jeremy Evans. File ruby193.log added File ruby193.diff added > Jeremy Evans wrote: > > Attached is the make check output on OpenBSD amd64. I'm also attaching a diff with the patches I used: > > > > * bootstraptest/test_thread.rb: Skip 2 tests. The first one appears to hang, the second crashes with a sigaltstack error. > > signalstack error seems because of the lack of OpenBSD specific setting. > see thread_pthread.c:506 and edit it. I don't think the problem is there, as reading the documentation the call there (pthread_stackseg_np(pthread_self(), &stk)) appears to be correct. The error I get in the 2nd bootstrap test is "rb_register_sigaltstack. malloc error", which comes from signal.c: 439 newSS.ss_sp = th->altstack = malloc(ALT_STACK_SIZE); 440 if (newSS.ss_sp == NULL) 441 /* should handle error */ 442 rb_bug("rb_register_sigaltstack. malloc error\n"); If you change the rb_bug call to a return, the 2nd bootstrap test passes. I'm not sure if that's a valid fix, as it probably affects signal handling for the thread. I first tried to change it to raise NoMemError, but that causes a segfault. Like the comment there states, the error should be handled, but I'm not sure how best to do that. I don't think this is an error caused by OpenBSD, just one that only manifests itself on OpenBSD. The 1st bootstrap error appears to be the threads not exiting when the process exits, causing the threads to hang. It can be reproduced with a single thread (ruby19 -e "Thread.new{loop{Thread.pass}}"). The hang doesn't happen if you use while instead of loop (ruby19 -e 'Thread.new{Thread.pass while true}'). Any ideas? > > * configure: Use -pthread instead of -lpthread when linking. From OpenBSD man pages: "On OpenBSD, the -pthread option should be used to link threaded code, isolating the program from operating system details." > > A patch should be for portable and for configure.in. I think I've got a working patch, it's attached. > > Use OpenBSD shared library naming convention (libruby19.so.1.0, as 1.9.2 used libruby19.so.0.0). > > What is LIBruby19_VERSION? You can ignore that. On OpenBSD, the ports system sets the shared library numbers, because most software doesn't handle the library versioning correctly (bumping the minor for new functions, bumping the major for removed functions or changes in functions). But that's not something you are going to want pulled upstream. > > Don't include OpenBSD version number in $arch. OpenBSD version numbers do not have any relationship to API/ABI compatibility. > > On *BSD/Mac OS X includes version to arch. > It seems independent from API/ABI compatibility. Including the version number means that every time the version number changes, all dependent ports that use sitearchdir need to be modified slightly. What's the rational behind including the operating system version if not for API/ABI compatibility? > > * ext/socket/lib/socket.rb: Don't check ipv6_recvpktinfo. This fixes a failure in one of the socket tests: > > Why this fixes the problem? > We can't merge this without understanding. I think this is a general bug in the code. If ipv6_recvpktinfo is true (which it is on OpenBSD since OpenBSD supports IPV6_PKTINFO), the Addrinfo for IPV6 address "::" is not added as a socket to use. The code looks like this: 516 elsif ai.ipv6? && ai.ip_address == "::" && !ipv6_recvpktinfo 517 local_addrs.each {|a| 518 next if !a.ipv6? 519 ip_list << Addrinfo.new(a.to_sockaddr, :INET6, :DGRAM, 0); 520 } 527 sockets = ip_sockets_port0(ip_list, false) 544 pktinfo_sockets = {} 545 sockets.each {|s| 546 ai = s.local_address 547 if ipv6_recvpktinfo && ai.ipv6? && ai.ip_address == "::" 548 s.setsockopt(:IPV6, ipv6_recvpktinfo, 1) 549 pktinfo_sockets[s] = true 550 end 551 } The pktinfo_sockets hash here is never used. And even if it was, because you are not adding the '::' address to ip_addrs if ipv6_recvpktinfo, no socket is being created for it, so you will never hit lines 548-549. The attached patch removes the "&& !ipv6_recvpktinfo" from 516 and the pktinfo_sockets hash handling. > > Even with the attached patch, there are 5 failures. 3 failures are weird linking errors in the rake tests I don't understand ("ruby lib version (1.9.3) doesn't match executable version (1.9.4)"). > > Hmm, I don't know about it. This appeared to be caused by my use of a non-pristine checkout. I did a pristine checkout and they went away. > > 2 failures appear to be caused by using GNU make syntax in the makefiles. On 1.9.2, BSD make was able to work with the makefiles, but starting on 1.9.3, it appears GNU make is required. Either makefiles should use not use GNU extensions or ruby should use gmake instead of make on BSD systems. > > It's strange because on FreeBSD and NetBSD, BSD make works correctly. There is the same bug in about 4 files that causes this, the submitted patch includes the fixes and makes everything compile with OpenBSD make. This is because the old=new modifier must be the last modifier in a BSD make variable substituion, and both those files contained a trailing :, which I'm guessing indicates another modifier. I guess OpenBSD make is more strict than the other BSD makes, but the last modifier behavior is specified in the FreeBSD make man page as well. I ran make check and found the following errors: 4 errors in test/unit's test::parallel tests caused by bugs, a patch for these is included. 3 errors in rake's tests that are caused by assuming that ruby is installed as "ruby". If you configure with --program-suffix, these fail. A patch for these is included. The rlimit hang is caused because setting the RLIMIT_NOFILE to 0 causes ruby to hang on exit in OpenBSD. Setting it to 1 does not cause it to hang. I added a patch that modifies the test code to use 1 instead of 0, but if you'd like a patch to process.c to use 1 if 0 is given on OpenBSD, I can do that. With the attached patch, there are no errors. There is a error in one of the timeout tests in the log, but that's spurious: $ ruby19 -v test/test_timeout.rb ruby 1.9.3dev (2011-07-28) [x86_64-openbsd5.0] Run options: # Running tests: ... Finished tests in 1.422562s, 2.1089 tests/s, 2.8118 assertions/s. 3 tests, 4 assertions, 0 failures, 0 errors, 0 skips ---------------------------------------- Feature #5097: Supported platforms of Ruby 1.9.3 http://redmine.ruby-lang.org/issues/5097 Author: Yui NARUSE Status: Assigned Priority: Normal Assignee: Yui NARUSE Category: Target version: 1.9.3 Let's decide the supported platforms. == Background http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatforms == Process If you want to support a platform, please declare. But when a platform dependent bug is reported, it will be assigned to you. == Current Maintainer mswin32, mswin64 (Microsoft Windows): NAKAMURA Usaku (usa) mingw32 (Minimalist GNU for Windows): Nobuyoshi Nakada (nobu) IA-64 (Debian GNU/Linux): TAKANO Mitsuhiro (takano32) Symbian OS: Alexander Zavorine (azov) AIX: Yutaka Kanemoto (kanemoto) FreeBSD: Akinori MUSHA (knu) Solaris: Naohisa Goto RHEL, CentOS KOSAKI Motohiro Platforms which doesn't have a maintainer are following: * Debian * Ubuntu * Mac OS X (LLVM related issues) * cygwin (don't work) * NetBSD (works) * OpenBSD (it may not work) * DragonFlyBSD (don't work) -- http://redmine.ruby-lang.org