On Wed, 8 Jan 2014 09:47:38 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [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: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jan 08. 2014 15:21]:
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
Josef, we need a couple of more rpm macros to specify gem pathes here. I am quite far with the following set: %{!?gem_base: %global gem_base %(ruby -r rubygems -e 'print Gem::BasicSpecification.new.base_dir')} %{!?gem_extensions: %global gem_extensions %(ruby -r rubygems -e 'print Gem::BasicSpecification.new.extensions_dir')} %{!?gem_doc_ext: %global gem_doc_ext %(ruby -r rubygems -e 'bs = Gem::BasicSpecification.new; rp = bs.extensions_dir.rpartition(bs.base_dir); print rp[1]+"/doc"+rp[2]')} (gem native extensions doc directory is a mess since its not reflected in Gem::BasicSpecification :-/) However, I still run into [ 16s] rubygem-nokogiri-1.6.1-1.x86_64.rpm: directories not owned by a package: [ 16s] - /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux [ 16s] - /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0 which apparently is a ruby21 packaging bug: rpm -qf /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux file /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux is not owned by any package @coolo: I'll submit a new ruby21 with a fixed filelist. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 8 Jan 2014 16:49:02 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jan 08. 2014 15:21]:
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
Josef,
we need a couple of more rpm macros to specify gem pathes here. I am quite far with the following set:
%{!?gem_base: %global gem_base %(ruby -r rubygems -e 'print Gem::BasicSpecification.new.base_dir')} %{!?gem_extensions: %global gem_extensions %(ruby -r rubygems -e 'print Gem::BasicSpecification.new.extensions_dir')} %{!?gem_doc_ext: %global gem_doc_ext %(ruby -r rubygems -e 'bs = Gem::BasicSpecification.new; rp = bs.extensions_dir.rpartition(bs.base_dir); print rp[1]+"/doc"+rp[2]')}
(gem native extensions doc directory is a mess since its not reflected in Gem::BasicSpecification :-/)
However, I still run into
[ 16s] rubygem-nokogiri-1.6.1-1.x86_64.rpm: directories not owned by a package: [ 16s] - /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux [ 16s] - /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0
which apparently is a ruby21 packaging bug:
rpm -qf /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux file /usr/lib64/ruby/gems/2.1.0/extensions/x86_64-linux is not owned by any package
@coolo: I'll submit a new ruby21 with a fixed filelist.
Klaus
Great, thanks Klaus. Just submit it to staging project (if you do not have permission create sr and I will accept it or if I have permissions I add you there ) and I start fixing failing rubygems. It is really confusing that ruby now contain rubygems, but there is RbConfig and Gem::BasicSpecification. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 08.01.2014 16:52, Josef Reidinger wrote:
Great, thanks Klaus. Just submit it to staging project (if you do not have permission create sr and I will accept it or if I have permissions I add you there ) and I start fixing failing rubygems. It is really confusing that ruby now contain rubygems, but there is RbConfig and Gem::BasicSpecification.
You're the maintainer of the staging prj and free to add whoever helps - just fix the packages there and then make sure you get pushed everything changed. So far changed are: ruby ruby-common ruby21 Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 08 Jan 2014 16:58:03 +0100 Stephan Kulow <coolo@suse.de> wrote:
On 08.01.2014 16:52, Josef Reidinger wrote:
Great, thanks Klaus. Just submit it to staging project (if you do not have permission create sr and I will accept it or if I have permissions I add you there ) and I start fixing failing rubygems. It is really confusing that ruby now contain rubygems, but there is RbConfig and Gem::BasicSpecification.
You're the maintainer of the staging prj and free to add whoever helps - just fix the packages there and then make sure you get pushed everything changed.
So far changed are:
ruby ruby-common ruby21
Greetings, Stephan
OK, thanks, I add Klaus to maintainers. BTW how do you get list of changed packages? Is it in UI (really helps for staging projects ) or do you have script? Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 08.01.2014 17:04, Josef Reidinger wrote:
On Wed, 08 Jan 2014 16:58:03 +0100 Stephan Kulow <coolo@suse.de> wrote:
On 08.01.2014 16:52, Josef Reidinger wrote:
Great, thanks Klaus. Just submit it to staging project (if you do not have permission create sr and I will accept it or if I have permissions I add you there ) and I start fixing failing rubygems. It is really confusing that ruby now contain rubygems, but there is RbConfig and Gem::BasicSpecification.
You're the maintainer of the staging prj and free to add whoever helps - just fix the packages there and then make sure you get pushed everything changed.
So far changed are:
ruby ruby-common ruby21
Greetings, Stephan
OK, thanks, I add Klaus to maintainers.
BTW how do you get list of changed packages? Is it in UI (really helps for staging projects ) or do you have script?
I don't have either - that's why I gave you the packages I added :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jan 08. 2014 15:21]:
1) path contain x86_64-linux but %rb_arch is x86_64-linux-gnu
Looking through the rubygems source code, I came up with this solution: %{!?gem_platform: %global gem_platform %(ruby -r rubygems -r rbconfig -e 'print Gem::Platform.new(RbConfig::CONFIG["arch"]).to_s')} rubygem-nokogiri builds now locally for me. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 8 Jan 2014 17:26:26 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jan 08. 2014 15:21]:
1) path contain x86_64-linux but %rb_arch is x86_64-linux-gnu
Looking through the rubygems source code, I came up with this solution:
%{!?gem_platform: %global gem_platform %(ruby -r rubygems -r rbconfig -e 'print Gem::Platform.new(RbConfig::CONFIG["arch"]).to_s')}
rubygem-nokogiri builds now locally for me.
Klaus
great, feel free to submit it to staging project. I expect it raise more issues, but I can fix it with changes to macros and your example. I think at least we can add macros for rb_ver_major, rb_ver_minor and rb_ver_patch to allow version checking of ruby for easier version handling in ifs for multi ruby version spec files. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jan 08. 2014 17:33]:
great, feel free to submit it to staging project.
I submitted ruby21 (new gem21_* macros, add native gem extensions dir to file list), ruby (map gem21_* to gem_* macros), and rubygem-nokogiri (fixed pathes) to the Ruby21 staging project yesterday evening. Everying builds fine.
I expect it raise more issues, but I can fix it with changes to macros and your example. I think at least we can add macros for rb_ver_major, rb_ver_minor and rb_ver_patch to allow version checking of ruby for easier version handling in ifs for multi ruby version spec files.
I used '%if %{defined gem_base}' for now. We might as well port the gem_* macros to older Ruby versions as well. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Thu, 9 Jan 2014 09:23:55 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jan 08. 2014 17:33]:
great, feel free to submit it to staging project.
I submitted ruby21 (new gem21_* macros, add native gem extensions dir to file list), ruby (map gem21_* to gem_* macros), and rubygem-nokogiri (fixed pathes) to the Ruby21 staging project yesterday evening. Everying builds fine.
I expect it raise more issues, but I can fix it with changes to macros and your example. I think at least we can add macros for rb_ver_major, rb_ver_minor and rb_ver_patch to allow version checking of ruby for easier version handling in ifs for multi ruby version spec files.
I used '%if %{defined gem_base}' for now. We might as well port the gem_* macros to older Ruby versions as well.
Klaus
Thanks. I fix ruby21 patch which breaks packages that use mkmf.rb and also small fix to rrdtool. The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted' but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail. Does anyone have idea what is wrong with vim?[1] Josef BTW. It is stupid that python-jinga2 depends on vim just because it have vim syntax file which it want to install to vim directory. [1] https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:R... -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 09.01.2014 17:38, schrieb Josef Reidinger:
Thanks. I fix ruby21 patch which breaks packages that use mkmf.rb and also small fix to rrdtool.
The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted'
but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail. Does anyone have idea what is wrong with vim?[1]
the link line misses -lruby - possibly ruby20 was macro online and didn't require the library. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Thu, 09 Jan 2014 20:54:55 +0100 Stephan Kulow <coolo@suse.de> wrote:
Am 09.01.2014 17:38, schrieb Josef Reidinger:
Thanks. I fix ruby21 patch which breaks packages that use mkmf.rb and also small fix to rrdtool.
The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted'
but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail. Does anyone have idea what is wrong with vim?[1]
the link line misses -lruby - possibly ruby20 was macro online and didn't require the library.
Greetings, Stephan
I think it is not case as you do not want vim that depends on ruby at runtime, so there is some dynamic loading[1]. Also ruby20 doesn't have -lruby. I wrote mail to Ismail who maintain package, but his suggestion with SUSE_ASNEEDED=0 also doesn't help. I add him to CC so we can think together what can cause it and how to fix it. I definitively do not want to break vim :), but I would like to fix the last problem with ruby21. Josef http://vimdoc.sourceforge.net/htmldoc/if_ruby.html#ruby-dynamic -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 09.01.2014 21:33, schrieb Josef Reidinger:
On Thu, 09 Jan 2014 20:54:55 +0100 Stephan Kulow <coolo@suse.de> wrote:
Am 09.01.2014 17:38, schrieb Josef Reidinger:
Thanks. I fix ruby21 patch which breaks packages that use mkmf.rb and also small fix to rrdtool.
The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted'
but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail. Does anyone have idea what is wrong with vim?[1]
the link line misses -lruby - possibly ruby20 was macro online and didn't require the library.
Greetings, Stephan
I think it is not case as you do not want vim that depends on ruby at runtime, so there is some dynamic loading[1]. Also ruby20 doesn't have Well, it requires perl too. -lruby. I wrote mail to Ismail who maintain package, but his suggestion with SUSE_ASNEEDED=0 also doesn't help. I add him to CC so we can think together what can cause it and how to fix it. I definitively do not want to break vim :), but I would like to fix the last problem with ruby21.
I guess that dynamic loading got broken with RGenGC. At least the missing symbol is about WBs. Greetings, Stephan
On Thu, 09 Jan 2014 21:41:57 +0100 Stephan Kulow <coolo@suse.de> wrote:
Am 09.01.2014 21:33, schrieb Josef Reidinger:
On Thu, 09 Jan 2014 20:54:55 +0100 Stephan Kulow <coolo@suse.de> wrote:
Am 09.01.2014 17:38, schrieb Josef Reidinger:
Thanks. I fix ruby21 patch which breaks packages that use mkmf.rb and also small fix to rrdtool.
The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted'
but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail. Does anyone have idea what is wrong with vim?[1]
the link line misses -lruby - possibly ruby20 was macro online and didn't require the library.
Greetings, Stephan
I think it is not case as you do not want vim that depends on ruby at runtime, so there is some dynamic loading[1]. Also ruby20 doesn't have Well, it requires perl too. -lruby. I wrote mail to Ismail who maintain package, but his suggestion with SUSE_ASNEEDED=0 also doesn't help. I add him to CC so we can think together what can cause it and how to fix it. I definitively do not want to break vim :), but I would like to fix the last problem with ruby21.
I guess that dynamic loading got broken with RGenGC. At least the missing symbol is about WBs.
Greetings, Stephan
Yes, it looks like. So how can we proceed? Disable ruby interface to vim? Or change dynamic to common link to ruby? I don't have enough knowledge to fix it and google doesn't show me any solution. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 09.01.2014 21:48, Josef Reidinger wrote:
Yes, it looks like. So how can we proceed? Disable ruby interface to vim? Or change dynamic to common link to ruby? I don't have enough knowledge to fix it and google doesn't show me any solution.
I checked what vim is doing there and it's hacking *deeply* into the ruby internals by overwriting functions and #define variables and such. It's very likely that this will not work even if you fix the linking. So disable it as long as vim upstream hasn't picked up ruby 2.1 (actually it requires ruby 1.9.1...) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Stephan Kulow <coolo@suse.de> [Jan 10. 2014 08:45]:
On 09.01.2014 21:48, Josef Reidinger wrote:
Yes, it looks like. So how can we proceed? Disable ruby interface to vim? Or change dynamic to common link to ruby? I don't have enough knowledge to fix it and google doesn't show me any solution.
I checked what vim is doing there and it's hacking *deeply* into the ruby internals by overwriting functions and #define variables and such.
It's very likely that this will not work even if you fix the linking. So disable it as long as vim upstream hasn't picked up ruby 2.1 (actually it requires ruby 1.9.1...)
Actually, it's rather straightforward to fix it. Expect a patch soon. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Klaus Kaempf <kkaempf@suse.de> [Jan 10. 2014 09:02]:
Actually, it's rather straightforward to fix it. Expect a patch soon.
A fixed vim packages is now checked in. Enjoy, Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 10.01.2014 09:11, Klaus Kaempf wrote:
* Klaus Kaempf <kkaempf@suse.de> [Jan 10. 2014 09:02]:
Actually, it's rather straightforward to fix it. Expect a patch soon.
A fixed vim packages is now checked in.
Where? Not in staging:ruby21 Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Stephan Kulow <coolo@suse.de> [Jan 10. 2014 09:20]:
On 10.01.2014 09:11, Klaus Kaempf wrote:
* Klaus Kaempf <kkaempf@suse.de> [Jan 10. 2014 09:02]:
Actually, it's rather straightforward to fix it. Expect a patch soon.
A fixed vim packages is now checked in.
Where? Not in staging:ruby21
Yeah, sorry, OBS choked again with Server returned an error: HTTP Error 414: Request-URI Too Large Submitted now. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jan 09. 2014 17:39]:
BTW. It is stupid that python-jinga2 depends on vim just because it have vim syntax file which it want to install to vim directory.
This could be solved by splitting off a python-jinga2-vim package which has "Supplements: python-jinga2" and "Supplements: vim". (better ask on libzypp-devel for the exact dependencies) Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 10.01.2014 08:40, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jan 09. 2014 17:39]:
BTW. It is stupid that python-jinga2 depends on vim just because it have vim syntax file which it want to install to vim directory.
This could be solved by splitting off a python-jinga2-vim package which has "Supplements: python-jinga2" and "Supplements: vim". (better ask on libzypp-devel for the exact dependencies)
Won't help the build dependencies. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jan 09. 2014 17:39]:
The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted'
but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail.
rb_gc_writebarrier_unprotect_promoted is only defined in libruby2.1.so, but neither in libruby2.0.so nor in libruby1.9.so Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 10.01.2014 08:45, Klaus Kaempf wrote:
* Josef Reidinger <jreidinger@suse.cz> [Jan 09. 2014 17:39]:
The last missing piece to get ruby21 to factory is to fix vim. To be honest I have no idea what can be wrong as it writes [ 121s] objects/if_ruby.o: In function `rb_obj_wb_unprotect': [ 121s] /usr/include/ruby-2.1.0/ruby/ruby.h:1236: undefined reference to `rb_gc_writebarrier_unprotect_promoted'
but this method is correctly in ruby and I see no problem. If I compare build of vim with build with ruby20 then I see no difference except that it doesn't fail.
rb_gc_writebarrier_unprotect_promoted is only defined in libruby2.1.so, but neither in libruby2.0.so nor in libruby1.9.so
It's the new GC - check http://rubykaigi.org/2013/talk/S73, minute 25 "All of C-extensions need perfect Write-barriers". Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (3)
-
Josef Reidinger -
Klaus Kaempf -
Stephan Kulow