Skip to content

Problems installing 1.0.1 gem on Windows 10 (0.7.1 works fine) #102

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.

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

Open
Mcgeecorp opened this issue Dec 17, 2020 · 7 comments
Open

Problems installing 1.0.1 gem on Windows 10 (0.7.1 works fine) #102

Mcgeecorp opened this issue Dec 17, 2020 · 7 comments

Comments

@Mcgeecorp
Copy link

I am using rubyinstaller 2.7.2 with the msys2 devkit but have tried this with 2.4, 2.5 and 2.6 as well.

I am able to get a taglib-ruby gem to build and install if I specify version 0.7.1 but I get some "crazy errors" with version 1.0.1.

Any ideas?

@Sigill
Copy link
Collaborator

Sigill commented Dec 17, 2020

What version of taglib do you have?
taglib-ruby >= 1.0 requires taglib >= 1.11.1, as mentioned in the readme: https://github.com/robinst/taglib-ruby#installation.
If you don't have taglib 1.11.1, stick with taglib v0.7.1.

@Mcgeecorp
Copy link
Author

Mcgeecorp commented Dec 17, 2020

Yep, I am using 1.11.1

$ pacman -Qs taglib
local/mingw-w64-x86_64-taglib 1.11.1-1
A Library for reading and editing the meta-data of several popular audio formats (mingw-w64)

@Sigill
Copy link
Collaborator

Sigill commented Dec 17, 2020

Looks like the Filename type is a simple const char* on every platform, except on Windows where it is a custom class:
https://github.com/taglib/taglib/blob/e36a9cabb9882e61276161c23834d966d62073b7/taglib/toolkit/tiostream.h#L35

Unfortunately, this class lack some stuff in order to behave like a const char*.
The taglib-ruby wrapper generated by Swig expects the Filename type:

  • To be default-constructible.

    taglib_base_wrap.cxx:2927:20: error: no matching function for call to 'TagLib::FileName::FileName()'
     2927 |   TagLib::FileName result;
          |                    ^~~~~~
    

    But none is defined and the presence of a user defined copy-constructor prevents the compiler to generate one.

  • To be copy-assignable.

    taglib_base_wrap.cxx:2938:47: error: use of deleted function 'TagLib::FileName& TagLib::FileName::operator=(const TagLib::FileName&)'
     2938 |   result = ((TagLib::File const *)arg1)->name();
          |                                               ^
    

    But since the Filename class has const data members, it is not assignable.

Hopefully, this should be an easy fix, but it must be fixed in taglib.

@robinst
Copy link
Owner

robinst commented Jan 20, 2021

@Sigill Have you reported this to taglib?

@Sigill
Copy link
Collaborator

Sigill commented Jan 20, 2021

No, I have not.

@s0nspark
Copy link

s0nspark commented Feb 7, 2024

I reported this in the hope of getting Ruby bindings to build again on Windows ;-)

Can anyone speak to what combination of taglib-ruby / taglib will build or work on Windows in the meantime? I'm using Ruby 3.3 along with MSys2...

@ufleisch
Copy link
Contributor

ufleisch commented Feb 7, 2024

Sorry for the trouble with TagLib. Version 2.0 has breaking changes. Converting a file name on Windows to char * is probably not a good idea when you want to support file names with non-ASCII characters. You should make some conditional compilation for the Windows case as has been done in VLC MR #4877

// fileName is a TagLib::FileName
#if defined(_WIN32) && TAGLIB_VERSION >= VERSION_INT(2, 0, 0)
    std::string filename = fileName.toString().to8Bit(true);
#else
    std::string filename = std::string(fileName);
#endif

Concerning TagLib::FileName result;: I would be surprised if this was ever building on Windows since TagLib::FileName never had a default constructor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants