Bug 246 - Build process search for libgig.so.7 in the wrong directory and fails linking
Summary: Build process search for libgig.so.7 in the wrong directory and fails linking
Alias: None
Product: LinuxSampler
Classification: Unclassified
Component: other (show other bugs)
Version: 2.0.0
Hardware: PC Linux
: P5 critical
Assignee: Christian Schoenebeck
Depends on:
Reported: 2015-12-12 22:55 CET by Giovanni Mariani
Modified: 2019-02-27 15:38 CET (History)
0 users

See Also:

Log file of failed build with linking errors (513.34 KB, text/x-log)
2015-12-12 22:55 CET, Giovanni Mariani

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Mariani 2015-12-12 22:55:47 CET
Created attachment 76 [details]
Log file of failed build with linking errors

Trying to build linuxsampler 2.0.0 for Rosa Fresh R6 x86_64.
Build process fails at linking time with "undefined reference" errors, after the warning below:
/usr/bin/ld: warning: libgig.so.7, needed by ./.libs/liblinuxsampler.so, not found (try using -rpath or -rpath-link)

The libgig.so.7 library is installed in /usr/lib64/libgig/ (where it was placed by the build/install process for libgig 4.0.0), and its pkgconfig file correctly points to it:

Name: gig
Description: C++ library for accessing Gigasampler/GigaStudio, DLS, SoundFont and KORG sound files
Version: 4.0.0
Libs: -L${libdir} -lgig
Cflags: -I${includedir}
So it looks like the linuxsampler build cannot actually find it because it searches for the library in only /usr/lib64.

This can confirmed by placing in /usr/lib64 a symlink named "libgig.so.7" to the installed library in /usr/lib64/libgig: this causes the build to finish successfully.
Comment 1 Christian Schoenebeck 2016-07-25 18:34:20 CEST
The order in which the lib directories are searched is not a matter of the LinuxSampler build files, this order is defined by configuration files of your OS (usually /etc/ld.so.conf and /etc/ld.so.conf.d/*).
Comment 2 Christian Schoenebeck 2019-02-27 15:38:32 CET
I am closing this report now, since it seems to be a configuration issue, not a bug on our side.

If you still think this is an issue that should be resolved, then feel free to reopen this report. Thanks!