Notice: taglib-extras required

Andreas Pakulat apaku at gmx.de
Sat Mar 21 13:35:08 UTC 2009


On 21.03.09 14:19:52, Andreas Pakulat wrote:
> On 21.03.09 13:09:46, Andreas Pakulat wrote:
> > On 21.03.09 12:55:15, Mark Kretschmann wrote:
> > > On Thu, Mar 19, 2009 at 3:19 PM, Jeff Mitchell <mitchell at kde.org> wrote:
> > > > Taglib-Extras is now a required dependency of Amarok from SVN.  You can
> > > > find it in the trunk/kdesupport/taglib-extras directory of KDE's SVN
> > > > tree.  You will need to either build it yourself, or wait for packagers
> > > > to come out with a package for it.
> > > 
> > > Just a note for those of you installing Amarok and taglib-extras in
> > > your $HOME: If you get linker errors while building Amarok, put this
> > > (it works for me) in your .bashrc, or type it manually before
> > > compiling ;)
> > > 
> > > "export LD_LIBRARY_PATH=$HOME/kde/build/taglib-extras/taglib-extras"
> > > 
> > > 
> > > PS:
> > > I'm still hoping that it might be possible to fix our CMake scripts to
> > > make this step unnecessary, but I don't know how. Any CMake experts
> > > here? Please speak up now! ;)
> > 
> > Are the errors about libraries that taglib-extras links against or from
> > amarok code missing taglib-extras? Usually KDE apps automatically set
> > rpath on their binary (because FindKDE4Internal.cmake sets a cmake flag
> > to always use rpath), so the export above shouldn't be necessary as long
> > as CMake knows the proper absolute path to the taglib-extras library
> > when building amarok.
> > 
> > I'm currently rebuilding all of kde4 so should see this soon myself as
> > well. At least I can't see any obvious errors from a quick look through
> > amarok's CMakeLists.txt or the FindTagLib-Extras.cmake module.
> 
> Ah, now I see the problem. The taglib-extras-config script produces
> pkg-config like output with -L/path and -lsomelib. However when you pass
> this combo to cmake it doesn't know that the given -L path corresponds
> to the given lib, so it doesn't put that path into the RPATH of the
> executable/library it builds.
> 
> Seeing that taglib-extras also ships with a .pc file, why not use the
> existing pkg-config macros which already do the "dirty" work? It does
> require to set another env var for pkg-config to find the .pc files, but
> you have to set some variable anyway if you're installing to $HOME (i.e.
> PATH).
> 
> Attached is a patch for FindTagLib-Extras.cmake using pkg_check_modules
> similar to how this is used in kdelibs for various Find-modules that use
> pkg-config. It still supports win32 debug-postfix and also supports
> finding the lib when no pkg-config file is found. It prefers pkg-config
> supplied lib/includedir over kde4 or amarok installation dir or standard
> paths like /usr(/local) or stuff mentioned in CMAKE_PREFIX_PATHS. The
> only downside is that I had to copy a little bit of cmake-code from
> kdelibs (for the win32 debug) and that the pkg_check_modules call will
> print out it found taglib-extras even if the Find-Module will do some
> more checks. The reason for these is that apparently parts of amarok can
> be built without kdelibs but with taglib-extras.
> 
> I've built amarok and taglib-extras into two different dirs in my $HOME
> (kde4 is built into /usr/local) and with just setting PKG_CONFIG_PATH at
> least utilities/collection* does build and link properly. 
> 
> So let me know if this patch is ok, then I'll commit it.
> 
> Andreas
> 
> PS: I also renamed TAGLIB-EXTRAS_INCLUDES to TAGLIB-EXTRAS_INCLUDE_DIR
> which seems to be the preferred name (judging by kdelibs find-modules)

PPS: I could also build amarok itself with this new find-module,
including any plugins that link against libamaroklib.so, without setting
LD_LIBRARY_PATH. Checking those plugins (like
amarok_context_applet_albums.so ) with ldd also shows that they find
libamaroklib.so and libtag-extras.so in the installed paths after
installing.

Andreas

-- 
Don't hate yourself in the morning -- sleep till noon.



More information about the Amarok mailing list