Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^2: Audio::TagLib and Strawberry Perl - New Details

by Anonymous Monk
on Aug 20, 2012 at 23:52 UTC ( #988533=note: print w/replies, xml ) Need Help??

in reply to Re: Audio::TagLib and Strawberry Perl - New Details
in thread Audio::TagLib and Strawberry Perl

Hi All,

Browsing through the Makefile, I see: DLSRC = dl_win32.xs.

That file (dl_win32.xs) does NOT exists on my system, after a bit of WEB searching I find no definite answers.

I have found one, it looks old (A warm day in June, 1995), I did reluctantly place it in the Audio::TagLib build directory without hopes, fortunately I was not let down, it didn't help!
Reluctant because I think/suspect this has been added to Strawberry Perl (or Perl it's self).

If I am understanding correctly, this loads dll's like MSVCRT, One that I suspect that may be causing these issues.

I obliviously don't have the skills to debug this without some assistance.

fh :)_~

  • Comment on Re^2: Audio::TagLib and Strawberry Perl - New Details

Replies are listed 'Best First'.
Re^3: Audio::TagLib and Strawberry Perl - New Details
by syphilis (Chancellor) on Aug 21, 2012 at 04:49 UTC
    I can build taglib-1.7.2 by running:
    cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=C:/MinGW/msys/1.0/lo +cal -DCMAKE_RELEASE_TYPE=Release .
    followed by:
    mingw32-make install
    I created copies (in the same directory) of the installed libtag.dll.a and libtag_c.dll.a named libtag.a and libtag_c.a.
    I then bypass all the crud in the Makefile.PL that the author provided by using this Makefile.PL:
    use ExtUtils::MakeMaker; WriteMakefile( NAME => 'Audio::TagLib', MIN_PERL_VERSION => '5.008001', VERSION_FROM => 'lib/Audio/', LICENSE => 'perl', INC => '-IC:/MinGW/msys/1.0/local/include -IC:/sisy +phusion/Audio-Taglib-1.61/include', LIBS => '-LC:/MinGW/msys/1.0/local/lib -ltag', ( $Config{'version'} >= 5.005 ? ( ABSTRACT_FROM => 'lib/Audio/', AUTHOR => 'Geoffrey Leach <>' ) : () ), PREREQ_PM => { "Encode" => 0, "Test::Deep" => 0, "File::Slurp" => 0, "Test::More" => 0, "Test::Output" => 0, }, "CONFIGURE_REQUIRES" => { "ExtUtils::MakeMaker" => 0, "Config" => 0, }, );
    (Naturally, those hardcoded paths need to change for other boxes.)
    Then, assuming we need to build with g++ instead of gcc, I run perl Makefile.PL CC=g++
    That proceeds ok, but when I run dmake I get hammered with:
    TagLib.xs:26:21: fatal error: apeitem.h: No such file or directory com +pilation terminated.
    Sure enough, TagLib.xs unconditionally includes apeitem.h and, sure enough, I don't have it.
    Do you know what and where that file is ?

    If I can get past that problem, it may become evident that the Makefile.PL that I've used needs further amendment ... cross that bridge when I come to it.

      Do you know what and where that file is ?


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        Yeah, got it.
        I just had to append "/taglib" to the "-IC:/MinGW/msys/1.0/local/include" argument I had supplied in the Makefile.PL.

        Unfortunately there's now a write() function in ostream that's getting #define'd to "PerlIO_write" ... which breaks the build.
        Have to see if I can undef something somewhere and fix that.


        Update: #undef write (and #undef read), then change a "char**" declaration in iconv_wrap.h to "const char**" get me to:
        c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/streambuf:569:7: err +or: expected ')' before '*' token
        which means what ? ... that the file is being parsed as a C file instead of a C++ file ? ... but afaict there has been no invocation of gcc - only g++ has been invoked.
        I'm probably not ready for C++ and (God willing), I hope I never bloody-well am.

        When I build taglib, I find that there's also a libtag_c.dll and libtag_c.dll.a produced - which, I assume, are the C versions of the library. It's a pity that Audio::TagLib doesn't build against that C library instead.
      Hi All,

      Thanks for the pointers to win32 / XS modules.

      Rob, apeitem.h is part of Taglib and should be in: Taglib-1.7.2/Include/Taglib
      If you were to open TagLib-1.7.2/Include/TagLib/TagLib.h and comment out the "_Pragma(...)" on line 34, you'll get further.

      If I am understanding correctly Audio::TagLib builds a Library as well, it is called TagLib.dll (in Win, or .so in *nix) that is linked with Taglib's libtag.a.
      but I don't know FOR SURE! for I have yet to see it build anything, other then an attempt to build TagLib.o. out of TagLib.c (an XS created file) and that fails.

      Taglib is not the issue, Audio::TagLib is the issue.

      I suspect it's missing the win32 run times.


      fh :)_~

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://988533]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2018-04-23 12:07 GMT
Find Nodes?
    Voting Booth?