On Wed, 8 Jan 2014 09:47:38 +0100 Klaus Kaempf <[email protected]> wrote:
> * Josef Reidinger <[email protected]> [Jan 07. 2014 17:06]: > > > > Hi, > > I am interested as I would like to see impact of new garbage > > collector. For me it looks like problem with different location of > > C extensions for ruby 2.1 > > 2.0 install it > > to /usr/lib64/ruby/gems/2.0.0/gems/nokogiri-1.6.1/ext/nokogiri/nokogiri.so > > and 2.1 install it > > to > > /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/nokogiri-1.6.1/nokogiri/nokogiri.so > > > > so it looks like we need to have smart macro for it or find > > different solution. > > Josef, > > ping me if you need help. > > Klaus Thanks for offer. I investigate issue now and it is quite mess. Ruby in 2.1 change destination where lives extensions. In ruby 2.1 it lives in e.g. for nokogiri at /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/nokogiri-1.6.1/nokogiri/nokogiri.so (before it lives in e.g in /usr/lib64/ruby/gems/2.0.0/gems/sqlite3-1.3.7/ext/sqlite3/sqlite3_native.so ) So tricky part is how to match these new path which exist from ruby 2.1. Similar think happen with doc of extensions. Now more challenges: 1) path contain x86_64-linux but %rb_arch is x86_64-linux-gnu 2) there is no simple macro to recognize if rb_ver is bigger or equal then 2.1.0 3) RbConfig::CONFIG do not specify ruby extensions dir => RbConfig::CONFIG.values.grep /extensions/ => [] 4) specific arch string is not in CONFIG (only x86_64-linux-gnu) => RbConfig::CONFIG.values.grep /x86_64-linux([^-]|$)/ => [] Few ideas I have: 1) use package list - fill it only if extensions exists and then use it in files list -> problem with unknown arch string Any ideas that helps with above challenges will be helpful Josef -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
