After update of dev-db/mariadb-5.5.37 media-sound/amarok-2.8.0-r1 was drawn into rebuild queue due to existing preserved libs, but failed to emerge. At that time several bug reports were filed including one I made. Today dev-db/mariadb-5.5.37-r1 came into the tree. It now allows media-sound/amarok-2.8.0-r1 to successfully rebuild and emerge, however, it doesn't clear out the existing preserved libs. Completing the emerge leaves the following mesg: !!! existing preserved libs: >>> package: dev-db/mariadb-5.5.37-r1 * - /usr/lib64/libmysqld.so.18 * used by /usr/lib64/kde4/amarok_collection-mysqlecollection.so (media-sound/amarok-2.8.0-r1) No matter how many times this package or mariadb is rebuilt these preserved libs remain. Reproducible: Always Steps to Reproduce: 1. update to dev-db/mariadb-5.5.37-r1 (build completes with preserved libs) 2. emerge @preserved-rebuild brings in media-sound/amarok-2.8.0-r1 for rebuilding 3. emerge succeeds, but portage still complains of preserved libs 4. attempt to rebuild both again manually with the same results Actual Results: Preserved libs remain. Output from portage: !!! existing preserved libs: >>> package: dev-db/mariadb-5.5.37-r1 * - /usr/lib64/libmysqld.so.18 * used by /usr/lib64/kde4/amarok_collection-mysqlecollection.so (media-sound/amarok-2.8.0-r1) Expected Results: Successful emerge of mariadb and rebuild of amarok without existing libs left behind.
My emerge --info: Portage 2.2.10 (default/linux/amd64/13.0/desktop/kde, gcc-4.8.2, glibc-2.19, 3.14.0-pf1 x86_64) ================================================================= System uname: Linux-3.14.0-pf1-x86_64-Intel-R-_Core-TM-2_CPU_T7200_@_2.00GHz-with-gentoo-2.2 KiB Mem: 3336220 total, 279620 free KiB Swap: 4200960 total, 4200848 free Timestamp of tree: Sat, 26 Apr 2014 17:45:01 +0000 ld GNU ld (GNU Binutils) 2.24 app-shells/bash: 4.2_p47 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.6-r1, 3.3.5, 3.4.0 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.14.1 sys-devel/binutils: 2.24-r2 sys-devel/gcc: 4.8.2 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.14 (virtual/os-headers) sys-libs/glibc: 2.19 Repositories: gentoo sunrise my_local_overlay Installed sets: @android, @nicefonts, @toolchain, @xorgupdate ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0 /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs=2 --with-bdeps=y --keep-going --complete-graph --load-average=1.5" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs candy collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe -march=native" GENTOO_MIRRORS="http://gentoo.netnitco.net http://gentoo.osuosl.org/ http://gentoo.mirrors.tds.net/gentoo http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://gentoo.wetzlmayr.com/ http://osmirrors.cerias.purdue.edu/pub/gentoo/ http://www.cyberuse.com/gentoo/ http://gentoo.mirrors.hoobly.com/ ftp://gentoo.imj.fr/pub/gentoo/ http://130.59.10.35/ftp/mirror/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2 -l1.5 -s" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="S3TC X a52 aac aacplus aacs aalib acl acpi alsa amd64 amr avahi berkdb bidi bluetooth bluray branding btrfs bzip2 cairo cdda cddb cdio cdparanoia cdr cli consolekit cracklib crypt cups curl cvs cxx dbus declarative device-mapper dirac djvu dri dts dv dvd dvdr emboss encode exif faac fam fat ffmpeg firefox flac fontconfig fortran gdbm gif git gphoto2 gtk iconv idn ieee1394 imagemagick ipv6 java jbig joystick jpeg jpeg2k kde kipi lame lastfm lcms ldap libass libnotify libsamplerate live lua lzma lzo mad matroska mime mjpeg mms mmx mmxext mng modplug modules mp3 mp4 mpeg multilib musepack musicbrainz ncurses netlink nls nptl nsplugin ntfs ntp ogg openal openexr opengl openmp pam pango pcre pdf phonon plasma png policykit postproc ppds qalculate qt3support qt4 quicktime rar readline samba scanner schroedinger sdl semantic-desktop session smp sndfile sox speex spell sse sse2 sse3 ssl ssse3 startup-notification subversion svg symlink taglib tcpd telepathy theora tiff truetype twolame udev udisks unicode upower usb vcd vcdx vlm vnc vorbis vpx wavpack wicd wifi wmf wxwidgets x264 xa xcb xcomposite xinerama xml xscreensaver xv xvid xvmc zeroconf zlib" ABI_X86="64 32" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev keyboard mouse synaptics joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" SANE_BACKENDS="epson epson2" USERLAND="GNU" VIDEO_CARDS="nvidia nv" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Please remove "/usr/lib64/libmysqld.so.18" and rebuild amarok. Since we moved that lib to "/usr/lib64/mysql", portage is keeping it around. @portage: anything we can do to address this?
@jmbsvicetto: Portage is correct here. Probably it wouldn't preserve /usr/lib64/libmysqld.so.18 if Amarok was correctly linked. It's not, see this: $ ldd /usr/lib64/kde4/amarok_collection-mysqlecollection.so|grep 'not found' libmysqld.so.18 => not found $ ls -l /usr/lib64/mysql/libmysqld.so.18 -rwxr-xr-x 1 root root 13323528 04-27 11:34 /usr/lib64/mysql/libmysqld.so.18 $ amarok --debug ... amarok: [WARNING] [PluginManager] "Failed to get factory 'amarok_collection-mysqlecollection' from KPluginLoader: Cannot load library /usr/lib64/kde4/amarok_collection-mysqlecollection.so: (libmysqld.so.18: cannot open shared object file: No such file or directory)" ... It of course now Amarok collection does not work.
Please remove "/usr/lib64/libmysqld.so.18" and rebuild amarok as I've asked before. If you're concerned, I can assure you I have amarok working here with mariadb-5.5.37-r1. I'm currently listening to music being played by amarok.
Of course I have done it before posting my comment, please don't assume I am ignorant. I made sure there are no /usr/lib64/libmysqld* files on my system, rebuilt amarok again (it does link against /usr/lib64/mysql/libmysqld.so thanks to `-L/usr/./lib64/mysql -lmysqld' in command line), this time by `emerge -C amarok && emerge amarok' to be on the safe side and even rebooted the system. It's still the same, amarok can't find libmysqld.so in runtime. I am curious, how do you expect it to work if /usr/lib64/mysql is not in ld.so.conf and amarok_collection-mysqlecollection.so does not have RPATH/RUNPATH? What does `ldd /usr/lib64/kde4/amarok_collection-mysqlecollection.so|grep libmysqld' give you?
Confirmed here, Gentoo x86_64, dev-db/mysql-5.5.37-r1, amarok 2.8.0-r1, ldd /usr/lib64/kde4/amarok_collection-mysqlecollection.so | grep mysqld libmysqld.so.18 => not found amarok and mysql both freshly rebuilt, the collection in amarok is not working, complains about not finding above mentioned .so file. amarok: [WARNING] [PluginManager] "Failed to get factory 'amarok_collection-mysqlecollection' from KPluginLoader: Bibliothek /usr/lib64/kde4/amarok_collection-mysqlecollection.so kann nicht geladen werden: (libmysqld.so.18: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden) (seems to be ignoring LANG=C, sorry for that. It says "can't load the library usr/lib64/kde4/amarok_collection-mysqlecollection.so, libmysqld.so.18: can't open the shared object file: file or directory not found)
The mentioned symlink belongs to mysql package, so I removed it and the file that it's pointing to and rebuilt both mysql and amarok. Looks ok.
(In reply to Jorge Manuel B. S. Vicetto from comment #2) > Please remove "/usr/lib64/libmysqld.so.18" and rebuild amarok. > Since we moved that lib to "/usr/lib64/mysql", portage is keeping it around. > > @portage: > anything we can do to address this? I did as suggested and manually removed the preserved lib, then emerged both mysql and amarok. However now amarok isn't linking to mysql correctly and collection is broken. As stated in several other posts checking linking shows it's failing. ~ $ ldd /usr/lib64/kde4/amarok_collection-mysqlecollection.so | grep mysqld libmysqld.so.18 => not found As you can see this is still an issue that needs resolving.
Strictly the same behaviour (In reply to Robert Cabrera from comment #8) > (In reply to Jorge Manuel B. S. Vicetto from comment #2) > > Please remove "/usr/lib64/libmysqld.so.18" and rebuild amarok. > > Since we moved that lib to "/usr/lib64/mysql", portage is keeping it around. > > > > @portage: > > anything we can do to address this? > > I did as suggested and manually removed the preserved lib, then emerged both > mysql and amarok. However now amarok isn't linking to mysql correctly and > collection is broken. As stated in several other posts checking linking > shows it's failing. > > ~ $ ldd /usr/lib64/kde4/amarok_collection-mysqlecollection.so | grep mysqld > libmysqld.so.18 => not found > > As you can see this is still an issue that needs resolving.
No offense to either the Devs or maintainers here, I know you all work hard and volunteer your time and efforts at making Gentoo the best distro it can be. However there are now 6 individual reports about this issue yet it's still marked as "UNCONFIRMED" with no one even hinting about a genuine solution. How many reports does it require before it's "confirmed" as being a problem worthy of fixing? I've posted reports before where I was the only one reporting an issue and it was marked as confirmed within a few hours of my posting. There may not be an easy solution, but at least acknowledge there's a problem here.
(In reply to Robert Cabrera from comment #10) > with no one even hinting about a genuine solution. Creating a /etc/ld.so.conf.d/10mysql.conf with /usr/lib64/mysql and running ldconfig is not a good, but working solution. I guess you could use that in the meantime until it gets fixed properly.
(In reply to Christian Loosli from comment #11) > /usr/lib64/mysql Adapt that to your path, obviously. (Just thought I could mention it, before someone complains)
In bug 509208 the poster shows in dramatic fashion how Amarok is failing to link with mariadb/mysql. As such, it should be marked as a duplicate of this one.
MySQL guys: This looks like a mariadb bug. Amarok can find the library at build time thanks to jmbsvicetto's latest commit but the new path is not included in ld.so.conf so cannot be found at runtime. I guess mariadb will need to install a file into /etc/env.d with a LDPATH entry? Amarok users: A simple way to launch amarok is by manually setting LD_LIBRARY_PATH. (Assuming you are on multi-lib 64bit) $ LD_LIBRARY_PATH="/usr/lib64/mysql" amarok Or you can manually create file in /etc/env.d with the below contents: LDPATH="/usr/lib64/mysql" and run env-update.
(In reply to Ian Whyman (thev00d00) from comment #14) > MySQL guys: > This looks like a mariadb bug. No, this is an amarok issue. > Amarok can find the library at build time thanks to jmbsvicetto's latest > commit but the new path is not included in ld.so.conf so cannot be found at > runtime. amarok needs to grab the location of the lib through mysql_config / mariadb_config. > I guess mariadb will need to install a file into /etc/env.d with a LDPATH > entry? > > Amarok users: > A simple way to launch amarok is by manually setting LD_LIBRARY_PATH. > (Assuming you are on multi-lib 64bit) > > $ LD_LIBRARY_PATH="/usr/lib64/mysql" amarok > > Or you can manually create file in /etc/env.d with the below contents: > LDPATH="/usr/lib64/mysql" > > and run env-update. I'll try to patch amarok to do that as soon as I have time for it.
*** Bug 509490 has been marked as a duplicate of this bug. ***
Now the same happens with amarok-2.8.0-r2.
I'm trying to track down the problem within Amarok, but being unfamiliar with Cmake is making it interesting. Anyhow, I found the following reading through the cmake output during configuration: -- Found MySQL: /usr/include/mysql, -L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lssl -lcrypto -ldl -- Found MySQL Embedded: /usr/include/mysql, -L/usr/./lib64/mysql -lmysqld -lpthread I manually ran the following commands to check the output of mysql_config: # mysql_config --libs -L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lssl -lcrypto -ldl # ls -l /usr/lib64/libmysqlclient.so" lrwxrwxrwx 1 root root 20 Apr 27 03:11 /usr/lib64/libmysqlclient.so -> libmysqlclient.so.18 # mysql_config --libmysqld-libs -L/usr/./lib64/mysql -lmysqld # ls -l /usr/lib64/mysql/libmysqld.so lrwxrwxrwx 1 root root 15 Apr 27 03:11 /usr/lib64/mysql/libmysqld.so -> libmysqld.so.18 According to my use flags I should be compiling Amarok with the embedded MySQL option. Seemingly, Amarok doesn't think that the case: # ldd /usr/lib64/kde4/amarok_collection-mysqlecollection.so | grep mysql libmysqld.so.18 => /usr/lib64/libmysqld.so.18 (0x00007f7752034000) Could it be that Amarok is confusing itself and instead of linking to what it found with Cmake for embedded, it's using the "normal" MySQL options?
Never mind, I think I got confused with the different mysql libraries. Perusing through the build.log on my computer I did notice there were two Amarok .so files that were being linked differently: # ldd /usr/lib64/kde4/amarok_collection-mysql* | grep mysql /usr/lib64/kde4/amarok_collection-mysqlecollection.so: libmysqld.so.18 => /usr/lib64/libmysqld.so.18 (0x00007f7d8a669000) /usr/lib64/kde4/amarok_collection-mysqlservercollection.so: libmysqlclient.so.18 => /usr/lib64/libmysqlclient.so.18 (0x00007fcbe7cdd000) I got confused between libmysqld.so.18 and libmysqlclient.so.18. Still, one of the .so doesn't link with what I would think is the embedded configuration, but I don't know enough about those libraries to say whether that's intentional or not. Still, I don't think this is the source of the problem now. > amarok needs to grab the location of the lib through mysql_config / > mariadb_config. In my previous comment mysql_config returned the "old" MySQL libraries. Amarok does use mysql_config in their Cmake scripts-- mysql_config seems to be the one at fault here, if libmysqld.so.18 has been moved elsewhere and is considered obsolete, as implied by an earlier comment. I have little experience in these matters, so please correct me if I'm wrong.
I need to stop troubleshooting things late at night. I was also misunderstanding what ldd actually does, and now I understand why the LDPATH and LD_LIBRARY_PATH options work. I may be stating the obvious for some, but if I'm understanding this correctly, amarok, at runtime, is loading /usr/lib64/libmysqld.so.18 because that is the library it finds in the runpath. Adding an entry to ld.so.conf.d makes sense as a solution... but wouldn't it be better to have mysql/mariadb do this, since they are the owner of the symlinks in question? I fail to see what can be patched in Amarok to resolve this problem.
I traced the problem down. It's not Amarok's fault-- it's mysql-cmake.eclass's fault. I filed a bug with my findings (bug 512008). See there for the proposed fix. I tested this in my system and it fixed the problem (I was having some weird quirkiness happening with mysql and amarok and portage, possibly due to my experimentation, so I had to emerge -C amarok and mysql and then emerge -1 them back in). The fix may also fix other problems with other applications linking to mysql or mariadb.
In bug 512008 I was told that my fix was incorrect. I have been trying to find anything in the Gentoo community (mailing lists, forums, etc.) detailing what the plans are for MySQL/MariaDB (for example, anything explaining why all the shared libraries except libmysqld.so were moved from /usr/$(get_libdir)/mysql to /usr/$(get_libdir)), but have failed at doing so. Without this information, I am unable to develop a fix to the problem. As I've stated before, I fail to see how Amarok is at fault since it compiles correctly (by using mysl_config). It just fails to find libmysqld.so.18 at runtime because it is inside /usr/$(get_libdir)/mysql, which is not pointed to by anything in the runtime environment. Is there any progress on this? I am more than happy to provide any information about my system/configuration in order to help, and I am also willing to create a proper fix, if someone could point me to where I could learn more about what Gentoo is doing with regards to MySQL/MariaDB.
Created attachment 378976 [details, diff] Patch adding a variable for CMake with the /usr/$(get_libdir)/mysql for addition into the runpath. If the solution isn't to add /usr/$(get_libdir)/mysql to LDPATH, the only other option I can see is to add the mysql library directory to the DT_RUNPATH of the amarok_collection-mysqlecollection.so binary, which needs /usr/$(get_libdir)/mysql/libmyslqd.so.18. If I am correct in this and I'm not ignoring anything glaring, I have two patches that would set this up when building Amarok. This first patch goes against the amarok-2.8.0-r2 ebuild (to be followed by a second patch file to modify one of Amarok's CMakeLists.txt to use the CMake variable introduced in the ebuild patch). It does two things-- it introduces a CMake variable, MYSQLD_DIR, which points to "${EPREFIX}/usr/$(get_libdir)/mysql", and also adds a new patch for one of Amarok's CMakeLists.txt.
Created attachment 378978 [details, diff] Patch file for modifying amarok_collection-mysqlecollection.so's CMakeLists.txt. This patch goes inside the "files" folder for Amarok. It simply uses the variable declared in the ebuild, MYSQLD_DIR, to set up the RPATH. I'm a bit unsure about this one, because I do recall reading something about Apple systems (Darwin?) having different properties regarding RPATHs or something of the sort... maybe this modification should go in the conditional for if the system is not Windows or Apple? In my system (~amd64), applying these two patches (really, a patch to the ebuild and then let the ebuild patch Amarok) fixes this problem and ldd reports that it can find the libmysqld library at runtime. Do these patches seem OK?
(In reply to Gabriel Marcano from comment #24) > Created attachment 378978 [details, diff] [details, diff] > Patch file for modifying amarok_collection-mysqlecollection.so's > CMakeLists.txt. > Sorry, I realized after I submitted this file that uploading it stripped it of its name. It is "files/amarok-2.8.0-libmysqld.patch", with the patched ebuild looking for it in "${FILESDIR}/${P}-libmysqld.patch".
Created attachment 379100 [details, diff] amarok-2.8.0-r2.ebuild.patch correction I should have tried to apply my own patch before uploading it yesterday. I must have tweaked it by hand and forgot to fix the line number specification for the second hunk. The new patch corrects this and now correctly applies on my computer against the original amarok-2.8.0-r2.ebuild.
(In reply to Gabriel Marcano from comment #26) > Created attachment 379100 [details, diff] [details, diff] > amarok-2.8.0-r2.ebuild.patch correction > > I should have tried to apply my own patch before uploading it yesterday. I > must have tweaked it by hand and forgot to fix the line number specification > for the second hunk. The new patch corrects this and now correctly applies > on my computer against the original amarok-2.8.0-r2.ebuild. Excellent. It works for me. Now in amarok library works.
(In reply to Gabriel Marcano from comment #26) > Created attachment 379100 [details, diff] [details, diff] > amarok-2.8.0-r2.ebuild.patch correction > > I should have tried to apply my own patch before uploading it yesterday. I > must have tweaked it by hand and forgot to fix the line number specification > for the second hunk. The new patch corrects this and now correctly applies > on my computer against the original amarok-2.8.0-r2.ebuild. Seems to work here, too.
Patch works for runtime, but tests fail to locate libmysqld. I tried to extend the macro in tests/core-impl/collections/db/sql/CMakeLists.txt, but it never picks up on the change. I even tried to override src_test to have -DMYSQLD_DIR set, but it did not work.
(In reply to Brian Evans from comment #29) > Patch works for runtime, but tests fail to locate libmysqld. > > I tried to extend the macro in > tests/core-impl/collections/db/sql/CMakeLists.txt, but it never picks up on > the change. I even tried to override src_test to have -DMYSQLD_DIR set, but > it did not work. I'm looking into what's causing this... what I can say right now is that my patches are being added and putting in print statements or their equivalents for the ebuild and the CMakeList.txt file reveals that the changes are going through and being picked up by both the ebuild and cmake. So far, I'm noticing that doing an ebuild compile doesn't update the rpath for amarok_collection-mysqlecollection.so. Looking at the output from the ebuild install phase, I can see that a make -j9 install command is issued, and that there is a ton of output mentioning linking of shared object files, including our good friend amarok_collection-mysqlecollection.so . Checking the *.so files created by ebuild install and installed inside /var/tmp/portage/amarok-2.8.0-r2/image reveals correct linking. Based on some searching and prodding with cmake, this is probably related to how cmake handles rpaths, possibly a problem somewhere where we aren't telling cmake to include the rpath at build time instead of at install time. I have next to no experience with cmake, so any input from anyone more experienced would be appreciated, especially anyone understading how our eclasses interact with packages' cmake scripts. In the meantime I'm going to keep plugging away at this.
Created attachment 381082 [details, diff] amarok-2.8.0-libmysqld.patch correction, adds rpath at build time instead of link time. Found the problem and came up with a solution. The problem was that by default cmake doesn't add install rpaths during build time but during install time. During the emerge process, testing happens between build and install, so by default we were missing the rpath when we run our tests. I added a line to the CMakeLists.txt file patch to intruct cmake to add the install rpath during build time for target amarok_collection-mysqlecollection. I was able to get all tests to pass after using the new patch file. Can anyone else confirm that my solution works?
(In reply to Gabriel Marcano from comment #31) > Created attachment 381082 [details, diff] [details, diff] > amarok-2.8.0-libmysqld.patch correction, adds rpath at build time instead of > link time. > > Found the problem and came up with a solution. The problem was that by > default cmake doesn't add install rpaths during build time but during > install time. During the emerge process, testing happens between build and > install, so by default we were missing the rpath when we run our tests. I > added a line to the CMakeLists.txt file patch to intruct cmake to add the > install rpath during build time for target > amarok_collection-mysqlecollection. I was able to get all tests to pass > after using the new patch file. Can anyone else confirm that my solution > works? I can confirm the patch fixes runtime rpath and tests. @jmbsvicetto Please check and merge this.
Fixed in media-sound/amarok-2.8.0-r3. Commit acked by jmbsvicetto in IRC.
*** Bug 509208 has been marked as a duplicate of this bug. ***
