Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ruby 3.2 warning "undefining the allocator of T_DATA class swig_runtime_data" #115

Closed
robinst opened this issue Apr 11, 2022 · 7 comments
Closed

Ruby 3.2 warning "undefining the allocator of T_DATA class swig_runtime_data" #115

robinst opened this issue Apr 11, 2022 · 7 comments
Labels
swig

Comments

@robinst
Copy link
Owner

robinst commented Apr 11, 2022 •
edited
Loading

Originally posted by @jeremyevans in #85 (comment)

While not related to the previous issue, I found that taglib 1.1.0 issues a warning when loaded on Ruby 3.2.0-preview1:

/usr/local/lib/ruby/gems/3.2/gems/taglib-ruby-1.1.0/lib/taglib_base.so: warning: undefining the allocator of T_DATA class swig_runtime_data

No runtime warning when using Ruby 3.0 or 3.1. Ruby 3.2.0 won't be released until near the end of the year, so hopefully this can be addressed before then. This also looks like an issue in swig and not specifically in taglib-ruby.
@robinst robinst mentioned this issue Apr 11, 2022
Closed
@robinst
Copy link
Owner Author

robinst commented Apr 11, 2022 •
edited
Loading

Some reading:

Seems like swig will need a fix after this line: https://github.com/swig/swig/blob/5a10e103992c49b8b402745b294fcdd4ca48e705/Lib/ruby/rubyrun.swg#L415

Will try to reproduce and then raise an issue and maybe PR in swig.

@robinst robinst mentioned this issue Apr 11, 2022
Closed
robinst added a commit to robinst/swig that referenced this issue Apr 11, 2022
@robinst
Fix Ruby 3.2 warning "undefining the allocator of T_DATA class swig_r…
9b5d37f 
…untime_data"

Ruby 3.2 (still in development) started warning about this, see
https://bugs.ruby-lang.org/issues/18007.

Note that the extension docs mention it in
https://ruby-doc.org/core-3.1.1/doc/extension_rdoc.html#label-C+struct+to+Ruby+object:

> The klass argument is the class for the object. The klass should
> derive from `rb_cObject`, and the allocator must be set by calling
> `rb_define_alloc_func` or `rb_undef_alloc_func`.

So in this case we call `rb_undef_alloc_func` to fix the warning.
Verified that this works in robinst/taglib-ruby#115.

Fixes swig#2257.
@robinst robinst mentioned this issue Apr 11, 2022
Merged
@robinst
Copy link
Owner Author

robinst commented Apr 11, 2022

Raised an issue and a PR in the swig repo for this: swig/swig#2257

ojwb pushed a commit to swig/swig that referenced this issue Apr 11, 2022
@robinst @ojwb
Fix Ruby 3.2 warning "undefining the allocator of T_DATA class swig_r…
962f090 
…untime_data"

Ruby 3.2 (still in development) started warning about this, see
https://bugs.ruby-lang.org/issues/18007.

Note that the extension docs mention it in
https://ruby-doc.org/core-3.1.1/doc/extension_rdoc.html#label-C+struct+to+Ruby+object:

> The klass argument is the class for the object. The klass should
> derive from `rb_cObject`, and the allocator must be set by calling
> `rb_define_alloc_func` or `rb_undef_alloc_func`.

So in this case we call `rb_undef_alloc_func` to fix the warning.
Verified that this works in robinst/taglib-ruby#115.

Fixes #2257.
@robinst
Copy link
Owner Author

robinst commented Apr 12, 2022

The fix has been merged (that was quick!), so now we can wait for the next release of swig (4.1.0), regenerate wrappers and that should fix it.

@robinst robinst added the swig label Apr 12, 2022
@fusion2004
Copy link

fusion2004 commented Dec 12, 2022 •
edited
Loading

So I was poking at regenerating the wrappers and I quickly ran into the problem that the command encoder has been removed in 4.1.0! I tried poking at the two renames that use it (had never touched any SWIG code before so it took a while) and eventually discovered the problems of why we were using the command encoder in the first place (because we need to lowercase & also remove/add prefix/suffix).

I had the crazy idea of trying to add support to DOH in SWIG to support multiple encoders looking something like %(regex:/blah/bleh/|undercase)s, but I don't really know if that is feasible and I'm not very handy at C code.

Wondering if you had already looking into this and hit the same problems @robinst, and if you had any thoughts as to a better/easier fix. I'm very down to help implement whatever we come up with!

@robinst
Copy link
Owner Author

robinst commented Dec 18, 2022

Hey @fusion2004! Hadn't looked into this yet, but your comment was very helpful. I've looked into it now and I've found a way to do what we need with regex. I'll push the change shortly (still need to clean it up a bit).

@robinst robinst mentioned this issue Dec 19, 2022
Merged
@robinst
Copy link
Owner Author

robinst commented Dec 19, 2022

Ok, PR is up, have a look please: #122

@AlexanderPavlenko AlexanderPavlenko mentioned this issue Dec 22, 2022
Closed
@robinst
Copy link
Owner Author

robinst commented Dec 29, 2022

Fix released in version 1.1.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
swig
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@robinst @fusion2004