Segfault when launching latest builds

[skellert]

In anticipation that I’m missing something obvious, here’s a potentially dumb question that’s driving me nuts….

I’ve successfully built around a dozen or so of the nightly releases up to and including 1348 – on my Fedora Core 5 system. When I tried to upgrade to 1400, mt-daapd was segfaulting at launch. I didn’t think much of it, waited for 1417 and tried again…. with the same result. Going back and rebuilding 1348 still worked.

Frustrated, I repeated the above on my new Fedora Core 6 box. Similar result – 1348 compiled and ran fine, but 1417 segfaults at runtime. This is what the log file says. (timestamps removed to make it easier to read)…

: Starting with debuglevel 2

: Error loading plugin /usr/lib/libXxf86misc.so: /usr/lib/libXxf86misc.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libXxf86dga.so: /usr/lib/libXxf86dga.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libpisync.so: /usr/lib/libpisync.so: undefined symbol: dlp_DeleteRecord

: Error loading plugin /usr/lib/libpopt.so: /usr/lib/libpopt.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libxml2.so: /usr/lib/libxml2.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libGL.so: /usr/lib/libGL.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libgdk_pixbuf_xlib-2.0.so: /usr/lib/libgdk_pixbuf_xlib-2.0.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libaudiofile.so: /usr/lib/libaudiofile.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libkdeinit_kprinter.so: /usr/lib/libkdeinit_kprinter.so: undefined symbol: plugin_info

: Error loading plugin /usr/lib/libcairo.so: /usr/lib/libcairo.so: undefined symbol: plugin_info

I’ve googled for the ‘error loading plugin’ faults and come up empty.

This is the sequence I use to compile and install…

./configure --prefix=/usr  --sysconfdir=/ --enable-sqlite

make



cp -f src/mt-daapd /usr/sbin/mt-daapd

rm -rf /usr/share/mt-daapd

mkdir /usr/share/mt-daapd

cp-tree admin-root /usr/share/mt-daapd/admin-root

cp -f src/plugins/.libs/*.so /usr/lib

OK… what stupid thing am I doing? I’m guessing it might have something to do with the “ignore the plugins value, instead auto-loading all plugins in the plugin dir” feature of 1391….. Also, a segfault is probably not the best way of flagging that there the plugin dir hasn’t been configured right 😉

[rpedde]

@skellert wrote:

OK… what stupid thing am I doing? I’m guessing it might have something to do with the “ignore the plugins value, instead auto-loading all plugins in the plugin dir” feature of 1391….. Also, a segfault is probably not the best way of flagging that there the plugin dir hasn’t been configured right 😉

Uh, what’s wrong with “make install”? 🙂

Yeah, obviously it’s trying to load every file in your libs directory. The plugins really shouldn’t go there. /usr/lib is for linkable libraries — stuff you intend to link with a -l. I believe they *should* go in $pkglibdir.

Short answer, put it somewhere other than /usr/lib. That’s what’s making it explode, and they arguably don’t belong there anyway.

course, putting them there shouldn’t make you segfault, so I clearly have work to do there.

That’s ticket 213, btw.

— Ron

[skellert]

Ron, Thanks for the reply and thanks for confirming the cause….

The reason I started avoiding “make install” was that this kept overwriting my mt-daapd.conf file with the default, which was a pain. Yes – I could have kept a backup and overwritten the “make install” default, but I didn’t. It probably would have saved me time to be sensible and kept the backup, huh?

Cheers,

[rpedde]

@skellert wrote:

The reason I started avoiding “make install” was that this kept overwriting my mt-daapd.conf file with the default, which was a pain.

😳 yeah… my bad. That’s been fixed some time in current nightlies, btw.

In any event, I’ll look for the underlying problem.

— Ron

[Author]

Posts