ruby-oci8-2.0.3 is marked stable. That is good, but the unstable ruby-oci8-2.0.3-r1 adds support for ruby19 and I can't get that to build on ~amd64. It hangs here: ... /usr/bin/ruby19 /var/tmp/portage/dev-ruby/ruby-oci8-2.0.6-r1/work/ruby19/ruby-oci8-2.0.6/ext/oci8/extconf.rb checking for load library path... LD_LIBRARY_PATH is not set. <hang> If I remove ruby19 from USE_RUBY, it works. So how about this: ruby-oci8-2.1.3 is the current release that is most fit for ~arch, while ruby-oci8-2.0.3 is the stable branch. Lets just move the of ruby-oci8-2.0.3-r1.ebuild to ruby-oci8-2.1.3.ebuild, as ruby19 is ~arch right now. I don't know how to fix the hang though. You guys probably know what the problem is off the top of your head. :) Reproducible: Always Steps to Reproduce: emerge ruby-oci8 in the ~amd64 arch with ruby19. Actual Results: Hangs as explained in the description. Expected Results: Compile properly
Assignee: troy@dublan.net did not match anything
(In reply to comment #0) > ruby-oci8-2.0.3 is marked stable. 2.0.6 is the oldest ebuild in the official tree. > ruby-oci8-2.0.3-r1 adds support for ruby19 and I can't get that to build on 2.0.6-r1 is the latest ebuild in the tree.
(In reply to comment #1) > Assignee: troy@dublan.net did not match anything @Troy: I guess your email address changed and we should update metadata?
(In reply to comment #0) > You guys probably know what the problem is off the top of your head. :) I've never seen this in any other package... The two most common pitfalls with ruby19 are that . is no longer in the load path and encoding issues in general. Can't see either of them producing a hang, though.
I've just added ruby-oci8-2.1.3 to the tree. Please let us know if that actually works and/or what needs changing.
(In reply to comment #3) > (In reply to comment #1) > > Assignee: troy@dublan.net did not match anything > > @Troy: I guess your email address changed and we should update metadata? Yes, it has, and yes, please.
(In reply to comment #4) > (In reply to comment #0) > > > You guys probably know what the problem is off the top of your head. :) > > I've never seen this in any other package... The two most common pitfalls > with ruby19 are that . is no longer in the load path and encoding issues in > general. Can't see either of them producing a hang, though. It hangs on checking LD_LIBRARY_PATH, interestingly only for ruby19. If I set LD_LIBRARY_PATH in the environment, it works fine. But defining LD_LIBRARY_PATH goes against Gentoo's well-designed environment where the Oracle libraries are already in ld.so.conf and have no need to be defined in LD_LIBRARY_PATH. If I go out to the build directory and run setup.rb config in ruby19 without the LD_LIBRARY_PATH, it works fine: ------ merida ruby-oci8-2.1.3 # pwd /var/tmp/portage/dev-ruby/ruby-oci8-2.1.3/work/ruby19/ruby-oci8-2.1.3 merida ruby-oci8-2.1.3 # echo $LD_LIBRARYPATH merida ruby-oci8-2.1.3 # ruby setup.rb config ---> lib ---> lib/dbd <--- lib/dbd ---> lib/oci8 <--- lib/oci8 <--- lib ---> ext ---> ext/oci8 /usr/bin/ruby19 /var/tmp/portage/dev-ruby/ruby-oci8-2.1.3/work/ruby19/ruby-oci8-2.1.3/ext/oci8/extconf.rb checking for load library path... LD_LIBRARY_PATH... checking ld.so.conf... yes ... ------ So, something weird is going on within the ebuild environment that is making it hang. I guess I need to dig deeper to see what it's checking.
(In reply to comment #5) > I've just added ruby-oci8-2.1.3 to the tree. Please let us know if that > actually works and/or what needs changing. Thanks! That's great. We just need to iron out the ebuild hang with ruby19 and it'll be perfect. Since ruby-oci8-2.0.3-r1 had the same problem with the LD_LIBRARY_PATH environment in the ~amd64 ruby19 environment, it's probably not a big deal it's broken for now.
(In reply to comment #7) > So, something weird is going on within the ebuild environment that is making > it hang. I guess I need to dig deeper to see what it's checking. I'm seeing the same thing (hang with portage, good run without it). I'm guessing that it may be related to the sandbox code. I tried to have a look but the OraConf code isn't happy code :-( One thing that might help is to avoid setup.rb altogether and just follow the path the gem would follow. I think dev-ruby/ruby-augeas-0.4.1 is a good blueprint of what to do.
I tried it on my Funtoo system and it works fine. Hrm.
(In reply to comment #10) > I tried it on my Funtoo system and it works fine. Hrm. Sigh, duh, I have LD_LIBRARY_PATH set. Sorry, I was reviewing this problem and it's been a while.
Sorry this bug has sat here for so long. I finally got around to updating the ebuild to use the gem instead. In my tests, the extconfig.rb builds a makefile that uses both LD_LIBRARY_PATH and ld.so.conf. In my tests, my builds for ruby19, ruby20, and ruby21 all work, and the native libraries work, and Sequel works with it. (Sequel is something we should probably get into the Portage tree.) I will attach the ebuild below.
Created attachment 393806 [details] dev-ruby/ruby-oci8-2.1.7.ebuild
Added to the tree. Thanks!
