Had a problem with that ebuild where the extconf.rb execution failed due to there being a missing "split" method on an object in mkmf, which may actually be a bug in ruby itself, but the glitch doesn't seem to appear in any other ruby ebuilds, so i fixed this one just in case im not the only one getting it. the fix basically entailed producing a patch that kulled out the "case" statement that gets run in windows & Cygwin, which is unnessecary for us anyway, and then cutting the respective line out of the ebuild that executed extconf.rb with special flags to make that trick work. attached is a _working_ tar which can be unpacked in ${PORTAGEOVERLAY}/dev-ruby/ to produce a working copy ( hopefully )
Created attachment 85910 [details] ruby-opengl-0.32g-r1.tar WORKSFORME tared up copy of modified ebuild and its patches, digests, and manifests.
Uh... please, attach a *plaintext* patch for whatever you are complaining about (tbh, not really clear what is the issue here, why don't you paste the errors you get?).
(In reply to comment #2) > Uh... please, attach a *plaintext* patch for whatever you are complaining about > (tbh, not really clear what is the issue here, why don't you paste the errors > you get?). > I uploaded a tar file as I _personally_ favour them over singluar files, for many reasons, 1 being that people often fail to tell what file name a file needs to be and where it needs to be placed, which is annoying if the ebuild code is not at all obvious like it sometimes is. >>> WORKDIR is up-to-date, keeping... >>> Compiling source in /var/tmp/portage/ruby-opengl-0.32g/work/opengl-0.32g ... *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/usr/bin/ruby18 now on second looks the problem may SIMPLY be in the ebuild alone, I fixed the problem with ext.rb not wanting to parse first before I decided to take a line out of the ebuild, so the patch may in fact be unnessecary. the problem is: ruby -i -pe 'sub "PLATFORM","RUBY_PLATFORM"' extconf.rb ruby extconf.rb results in extconf.rb failure. after hacking out the "other osses not linux" part of extconf.rb, it runs without a problem. Will resubmit attachements in plaintext as per request.
Created attachment 85913 [details] dev-ruby/ruby-opengl/ruby-opengl-0.32g-r1.ebuild the line that does "ruby -i -pe 'sub "PLATFORM","RUBY_PLATFORM"' extconf.rb" was removed from this file to make it work under ruby19 as well as ruby18 ( the ruby eclass makes it build for every instnace of ruby )
Created attachment 85914 [details, diff] dev-ruby/ruby-opengl/files/extconf-fix.patch this file is modified to not need to do PLATFORM detection at execution time ( which is the thing that stopped it executing ) , which was pointless anyway IMO, as gentoo, to the best of my knowledge, wont be running ruby stuff under windows or cygwin in the near future.
Oh yes, and just in case you were wondering, the mkmf.log file had no errors in it just in case you were wondering, only "do we have ITEM -- yes.. checked program was...etc " in it, with no complaints, ( under ruby18 at least ) , and the complaint it got in ruby19 ( which was a different glitch ) when executed with ruby19 -i -pe 'sub "PLATFORM","RUBY_PLATFORM"' extconf.rb ( as per the ebuild) yeilded only -e:1: undefined method `sub' for main:Object (NoMethodError), which is why i kulled that double call.
I've been playing with this some, too. The problem I run into is that after that command with the 'sub...' in it, the extconf.rb file ends up with RUBY_RUBY_PLATFORM in it, and things quickly die after that. On my systems, either PLATFORM or RUBY_PLATFORM would be OK, but RUBY_RUBY_PLATFORM makes no sense. I could force a build simply by removing the ' ... -pe ...' line, but I don't see how that can be the correct solution. (After all, the ebuild as written must work someplace).
(In reply to comment #7) > I've been playing with this some, too. The problem I run into is that after > that command with the 'sub...' in it, the extconf.rb file ends up with > RUBY_RUBY_PLATFORM in it, and things quickly die after that. On my systems, > either PLATFORM or RUBY_PLATFORM would be OK, but RUBY_RUBY_PLATFORM makes no > sense. I could force a build simply by removing the ' ... -pe ...' line, but I > don't see how that can be the correct solution. (After all, the ebuild as > written must work someplace). > yeah, I just thought to trump the whole RUBY_PLATFORM evalutation code, cos were not going to be using Windows Or Cygwin here in Gentoo now are we?
The `ruby -i -pe 'sub "PLATFORM","RUBY_PLATFORM"' extconf.rb' line seems to have been added in the 0.32d ebuild. However, since that time, extconf.rb has been updated to use RUBY_PLATFORM instead of PLATFORM, so this line is no longer necessary -- indeed, it causes problems. In other words, that line of the ebuild is an antique of a by-gone era, and should be removed. I'm surprised this issue wasn't caught before the ebuild was inserted into the portage tree.
removed the line from the ebuild.
Three months since caleb removed the line. It works for me. No response. Assuming that was fixed. Please reopen if the problem exists
