More 1.9.3 fun

Mo Morsi mmorsi at redhat.com
Thu Jan 19 20:52:12 UTC 2012


On 01/19/2012 03:16 AM, Vít Ondruch wrote:
>>
>> So, obviously the bundle can't find the C extension.  According to
>> some research, I see this on rubygems.org
>>
>> "This works because rubygems copies the shared object from ext to lib
>> when the gem is installed."
>>
>> I'm not sure that's happening.
>
>
> Actually that's happening, just a bit differently. You see that you 
> have the 
> '/usr/local/lib/gems/exts/sqlite3-1.3.5/lib/sqlite3/sqlite3_native.so' 
> so it is in libs and if you run "$ ruby -r sqlite3 -e "puts 'it 
> works'"", RubyGems should prepare the load paths and everything should 
> work.
>
> Unfortunately Bundler does not use RubyGems to prepare the load paths 
> and it is doing everything by itself. Therefore Bundler doesn't know 
> about this modifications we made to RubyGems and cannot load the 
> library properly. Moreover, Bundler replace the RubyGems modified 
> 'require' by the Ruby's original version, so RubyGems cannot help here.
>
> We are looking into Bundler now to find a cure. Unfortunately, that 
> means you will not be able to use stock Bundler in Fedora anymore. The 
> only option is to push the RubyGems modifications upstream [1], and 
> later push the changes into Bundler's upstream. However, RubyGems 
> upstream is not very responsive in this matter. May be you can try to 
> support us a bit.
>

Yes, seems to be a pretty big blocker. The new paths should allow us to 
use both the version of bundler shipped via rpm and bundler if installed 
via gem.

We can push for different practices upstream but that is quite an effort 
w/ no guarantees, and most likely won't be implemented by F17. If we 
can't figure out a solution to get bundler working at a technical level, 
this will have to push the 1.9.3 release back.


   -Mo


More information about the ruby-sig mailing list