Topic: libmusicbrainz-4.0.0 MacOSX troubles

Hi,

I trying to build libmusicbrainz-4.0.0 on MacOSX and I have followed included install.txt instructions.
here is the command line that i have used:

cmake -L -DNEON_LIBRARIES:FILEPATH=/opt/local/lib/libneon.dylib -DNEON_INCLUDE_DIR:PATH=/opt/local/include/neon -DCMAKE_INSTALL_PREFIX:PATH=/usr/local/fma/libmusicbrainz/4.0.0

then run make and make install
All seems to be successfully built ... no output errors

My problem is that the resulting libmusicbrainz4.3.0.0.dylib in my targeted prefix folder using otool -L give me this result :

/usr/local/fma/libmusicbrainz/4.0.0/lib/libmusicbrainz4.3.0.0.dylib:
    libmusicbrainz4.3.dylib (compatibility version 3.0.0, current version 3.0.0)
    /opt/local/lib/libneon.27.dylib (compatibility version 30.0.0, current version 30.6.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

there is no path for libmusicbrainz4.3.dylib

When other binary try to use the linked using ln -s in /usr/local/lib/libmusicbrainz4.3.dylib I have an error saying that

dyld: Library not loaded: libmusicbrainz4.3.dylib

running otool -L on the binary which need libmusicbrainz4.3.dylib give me the same result

...
        /usr/local/fma/libdiscid/0.2.2/lib/libdiscid.0.dylib (compatibility version 3.0.0, current version 3.1.0)
    /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 5.0.0)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 41.0.0)
    /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current version 8.0.0)
    /opt/local/lib/libslang.2.dylib (compatibility version 2.0.0, current version 2.2.0)
    libmusicbrainz4.3.dylib (compatibility version 3.0.0, current version 3.0.0)
    /opt/local/lib/libFLAC++.6.dylib (compatibility version 9.0.0, current version 9.0.0)
    /opt/local/lib/libFLAC.8.dylib (compatibility version 11.0.0, current version 11.0.0)
...

Resulting libmusicbrainz4.3.0.0.dylib in the src folder after the make step running otool -L give me this result

/Users/suroot/Develop/libmusicbrainz/libmusicbrainz-4.0.0/libmusicbrainz-4.0.0/src/libmusicbrainz4.3.0.0.dylib:
    /Users/suroot/Develop/libmusicbrainz/libmusicbrainz-4.0.0/libmusicbrainz-4.0.0/src/libmusicbrainz4.3.dylib (compatibility version 3.0.0, current version 3.0.0)
    /opt/local/lib/libneon.27.dylib (compatibility version 30.0.0, current version 30.6.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

I don't have encountered trouble with libdiscid-0.2.2 (built myself) or libmusicbrainz-3.0.3 (using brew or macports).

I have made some search on google and found these
http://hintsforums.macworld.com/showthread.php?t=79226
http://www.cmake.org/pipermail/cmake/20 … 24112.html

I would like to know if I have made something wrong or if something have change between libmusicbrainz-3.0.3 and libmusicbrainz-4.0.0 with cmake process ?

as example
running otool -L on libdiscid-0.2.2 give good result

 /usr/local/fma/libdiscid/0.2.2/lib/libdiscid.0.2.1.dylib:
    /usr/local/fma/libdiscid/0.2.2/lib/libdiscid.0.dylib (compatibility version 3.0.0, current version 3.1.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.42.0)
    /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

running otool -L on libmusicbrainz-3.0.3 give good results too

/usr/local/Cellar/libmusicbrainz/3.0.3/lib/libmusicbrainz3.6.3.0.dylib:
    /usr/local/lib/libmusicbrainz3.6.3.0.dylib (compatibility version 6.0.0, current version 6.3.0)
    /usr/local/Cellar/neon/0.29.6/lib/libneon.27.dylib (compatibility version 30.0.0, current version 30.6.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

Many thanks in advance for all advices.

Kind Regards

Re: libmusicbrainz-4.0.0 MacOSX troubles

Hi,

I'm afraid I've got no experience of compiling under MacOS. The only thing I can say is that I've compared the CMakeLists from 3.0.3 and 4.0.0 and (apart from a few obvious changes) they're identical.

You say:

I don't have encountered trouble with libdiscid-0.2.2 (built myself) or libmusicbrainz-3.0.3 (using brew or macports).

Have you tried compiling libmb-3.0.3 straight from the MusicBrainz source? I don't know what brew or macports are, but could they have made changes to the build system?

If you can find out what these changes are (or point me to them) then perhaps I can update the library to take account of them. I'm about to make an update, so now would be a good time as any.

Also, I'd appreciate it if you'd submit this as a bug at http://tickets.musicbrainz.org/browse/LMB

Finally, I don't get on here much, so it might be easier to email me with any updates.

Thanks

Andy

Re: libmusicbrainz-4.0.0 MacOSX troubles

Another thought after some discussions in IRC, is it possible that /usr/local/fma/libmusicbrainz isn't in your library search path, but /usr/local/fma/libdiscid/ is?

Andy

Re: libmusicbrainz-4.0.0 MacOSX troubles

Hi Andy,

Many thanks for your answers.

MacPorts (http://www.macports.org), Homebrew (http://mxcl.github.com/homebrew) or Fink are very serious and professional project about porting linux binaries to BSD/MacOSX. They all use original developer sources but all can't be used at the same time.

Here is libmusicbrainz-3.0.3 port from MacPorts: https://trac.macports.org/browser/trunk … 3/Portfile
Here is libmusicbrainz-3.0.3 port from Homebrew: https://github.com/mxcl/homebrew/blob/m … cbrainz.rb

Many thanks for your help.
I'm sending by email the rest of updates.

Kind Regards

Re: libmusicbrainz-4.0.0 MacOSX troubles

Ok, there doesn't look anything unusual in those files.

The only thing I can think is that it's some installation issue.

Can you check exactly what the libmb3 package installs and where (including any symbolic links and the like) and make sure they are duplicated (suitably modified of course) for your installation of libmb4?

Failing that, get on to the macports and homebrew people to see if they can put libmb4 packages in place.

However, if there's something that can be done in my source to make it easier to install for Mac user (and you can tell me what that is!) then I'll obviously try to include it.

Andy

Re: libmusicbrainz-4.0.0 MacOSX troubles

Dear Andy,

Did you received my 2 emails ?

Kind Regards

Re: libmusicbrainz-4.0.0 MacOSX troubles

No, I haven't received any emails. I guess it's possible they got spam trapped somehow.

Either try again or post again here, I'm getting email notifications when this thread is updated so that's probably the best thing to do.

Cheers

Andy

Re: libmusicbrainz-4.0.0 MacOSX troubles

Hi Andy,

Here are my two emails content
first one:

Hi Andy,

Many thanks for your answers.

MacPorts (http://www.macports.org), Homebrew (http://mxcl.github.com/homebrew) or Fink are very serious and professional project about porting linux binaries to BSD/MacOSX. They all use original developer sources but all can't be used at the same time.

Here is libmusicbrainz-3.0.3 port from MacPorts: https://trac.macports.org/browser/trunk … 3/Portfile
Here is libmusicbrainz-3.0.3 port from Homebrew: https://github.com/mxcl/homebrew/blob/m … cbrainz.rb

I have modified Homebrew formula which contains an old devel section for libmusicbrainz-4.0.0beta1 for libmusicbrainz-4.0.0 using original sources too and used homebrew install mechanism to build libmusicbrainz-4.0.0 and it worked this time. otool -L give me good results on the targeted dylib.
    /usr/local/Cellar/libmusicbrainz/4.0.0/lib/libmusicbrainz4.3.0.0.dylib:
    /usr/local/lib/libmusicbrainz4.3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0)
    /usr/local/Cellar/neon/0.29.6/lib/libneon.27.dylib (compatibility version 30.0.0, current version 30.6.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)
It seems that I'm missing something when building libmusicbrainz-4.0.0 myself from the same sources and this is not a bug from libmusicbrainz-4.0.0. 
I have built libdiscid-0.2.2 from your sources myself (as this is unavailable from Homebrew) using configure, make and all worked fine.
This is the first time that I'm using a cmake project manually to build lib/binaries on MacOSX.
mine was referencing libmusicbrainz4.3.dylib and homebrew version is referencing libmusicbrainz4.3.0.0.dylib

I think that after the cmake step (as I'm using the same command line) Homebrew is modifying the environment or is passing custom flags or parameters to make.
I will try to find what because I need to understand what I'm missing :)

I always use a prefix to install all built libs/includes/binaries and link all prefix/lib/* to /usr/local/lib and prefix/include/* to /usr/local/include.
libdiscid-0.2.2 is located in /usr/local/fma/libdiscid/0.2.2/lib/*.dylib and linked to /usr/local/lib/*.dylib and /usr/local/fma/libdiscid/0.2.2/include/discid is linked to /usr/local/include/discid. So I had libdiscid and neon libs and includes in my search path but not the libmusicbrainz-4.0.0 (musicbrainz4) as not yet built.

libdiscid-0.2.2 (myself version) and Macports version are 100% same ... ouf :).

I have tried to use same prefix method or without prefix for building myself libmusicbrainz-4.0.0. 
Something strange is that built libs into ./libmusicbrainz-4.0/src/ after cmake and make contains shared library dependencies (otool -L) with path but after the make install step path is removed and libmusicbrainz4.3.0.0.dylib md5 is not the same before and after make install.

I'm really missing something. It's not libmusicbrainz-4.0.0 developer fault !
Many thanks for your help.

Are you the "adhawkins" from the great flactag project ?

Kind Regards

second one:

Hi Andy,

Seems to find the solution.
It seems for some build (eg cmake) it is needed to run a tool (install_name_tool) with which you can change or update shared library information.
I tried many times with this tools but not with the good parameter.
first reference of a dylib is the id

$ install_name_tool [-change old new] ... [-rpath old new] ... [-add_rpath new] ... [-delete_rpath old] ... [-id name] input

$ cd /usr/local/fma/libmusicbrainz/4.0.0/lib/
$ install_name_tool -id /usr/local/fma/libmusicbrainz/4.0.0/lib/libmusicbrainz4.3.0.0.dylib libmusicbrainz4.3.0.0.dylib
or 
$ install_name_tool -id $prefix/lib/libmusicbrainz4.3.0.0.dylib libmusicbrainz4.3.0.0.dylib
or
install_name_tool -id /usr/local/lib/libmusicbrainz4.3.0.0.dylib libmusicbrainz4.3.0.0.dylib (which is better with symlink /usr/local/lib/libmusicbrainz4.3.0.0.dylib -> /usr/local/fma/libmusicbrainz/4.0.0/lib/libmusicbrainz4.3.0.0.dylib)

now running otool -L:
libmusicbrainz4.3.0.0.dylib:
    /usr/local/fma/libmusicbrainz/4.0.0/lib/libmusicbrainz4.3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0)
    /opt/local/lib/libneon.27.dylib (compatibility version 30.0.0, current version 30.6.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

I will tomorrow rebuild flactag as now shared library references seems to be solved and libmusicbrainz4.3.0.0.dylib could be loaded (i hope so :) ) as my error was flactag can't load libmusicbrainz4.3.0.0.dylib due to broken shared reference (I hope too).

many thanks again for your help.
I will confirm you this asap.

Kind Regards

Kind Regards

Re: libmusicbrainz-4.0.0 MacOSX troubles

Hi,

Just to clarify, have you now got it working?

You seem to be suggesting that there's a step missing from the install process. Do you think this is a manual step that is required for MacOS only, or is it something I could consider including in the libmusicbrainz source build system?

And yes, I am the same adhawkins that wrote flactag. My main reason for writing libmb4 was because flactag stopped working properly when MusicBrainz switched over to their NGS. The original maintainer of libmb didn't have time to do the work for the new XML web service, so I decided to do it myself.

Thanks for your input

Andy

Re: libmusicbrainz-4.0.0 MacOSX troubles

Dear Andy,

libmusicbrainz-4.0.0 seems to be fully working now.
I have tried included example binaries (cdlookup, cdlookup_c, search, search_c) and I got results.

install_name_tool is a MacOSX developer tool. Homebrew (don't know for MacPorts) use it to fix dynamic shared library reference in some case. It seems to be only required on MacOSX. I never had to use it before for some build process using configure/make which were not available through porting projects. It seems that some build process need it to fix dynamic shared library reference as I found it in a Homebrew ruby script. It's maybe due to cmake. I have made some search about cmake and install_name_tool and found some results about calling install_name_tool from cmake about fixing shared library references.

Today, I have successfully built flactag 2.0.0 (never can't build flactag 1.1 on MacOSX) and I don't have anymore the error: "Library not loaded: libmusicbrainz4.3.dylib". flactag command give me now the command line options ... seems good :)
I have to test more accurately by tagging something. Running otool on flactag give me good references about all shared library without using install_name_tool.

flactag discid is fully working and is accessing natively my internal combo drive without any troubles and give me good results that I have checked online or with cdlookup.

I can give you more return if you want.

Many thanks for all.
Kind Regards

Re: libmusicbrainz-4.0.0 MacOSX troubles

Glad to know all is working. There will be an official release of flactag 2.0.1 later today (there were some minor packaging and licensing issues with 2.0.0). Functionally it's identical, but worth upgrading to.

If you point me to a reference for cmake and MacOS then I'll see if it can be included in a future build process. Again, there will be a new release of libmb4 (4.0.1) probably later today. This fixes a minor bug and addresses a misinterpretation of the XML schema on my part.

Thanks again

Andy