Re: [WavPack-devel] shared library troubles in WavPack release package

[Roberto J. de A. <rja...@ya...>]

Hello David.
Maybe it's some configuration error on your 32-bit machine? I just tried ldconfig -v | grep ^/ on one of my linux systems and this is the output:ldconfig -v | grep ^//usr/lib/i386-linux-gnu/mesa:
/lib/i386-linux-gnu:/usr/lib/i386-linux-gnu:/usr/local/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/mesa:/lib32:/usr/lib32:/lib:/usr/lib:
Wavpack compiled fine there (but then again, I didn't try compiling different versions to check whether it would link against old libraries)
Regards;
R.

      De: David Bryant <da...@wa...>
 Para: Wav...@li... 
 Enviadas: Quinta-feira, 14 de Maio de 2015 20:56
 Assunto: [WavPack-devel] shared library troubles in WavPack release package
   
  I'm trying to get out this latest version of WavPack, but I'm running into a problem / confusion with the libraries. WavPack 4.75.0 installs and works fine on my main system (64-bit LinuxMint Qiana), but it does not install correctly on a particular test system I have (32-bit LinuxMint Qiana).
 
 On the failing system I had no problem compiling and running the new version directly at cli/wavpack whether I built with --disable-shared or not. I could still run the old 4.70.0 version (which was installed by the package manager) simply by typing “wavpack” (/usr/bin/wavpack).
 
 However, when I tried installing the 4.75.0 package (and doing ldconfig) I ran into trouble. When I typed “wavpack” it would pick up the new binary (/usr/local/bin/wavpack) but would use the old 4.70.0 libwavpack (/usr/lib/i386-linux-gnu/libwavpack.so.1). I could force the correct library by using “LD_LIBRARY_PATH=/usr/local/lib wavpack”, but obviously that's not an acceptable solution for a distribution.
 
 The new library is definitely in the library cache, but it looks like ld.so is simply using the first library that matches the request, even though I remember reading somewhere that it is supposed to favor newer revisions of the same library. The search order seems to be (based on ldconfig -v output):
 
 /usr/lib/i386-linux-gnu/
 /usr/local/lib
 /usr/lib/x86_64-linux-gnu/
 
 So, when it looks for the 64-bit library it finds the one in /usr/local/lib first, but if it's looking for the 32-bit version it never gets to /usr/local/lib and uses the old library. To verify this I tried building and installing a 32-bit version of 4.75.0 on my 64-bit system and sure enough, it used the old library! This seems really broken to me.
 
 My first idea to fix this was to bump the libtool versioning so that (I thought) my command-line programs would require the newer library (even though there was really no missing dependency in the old library). I was surprised when this did not work. I even added a new function to the library and now I get a runtime error when I try to  run the programs, because it still won't use the new library. So either that feature, or my understanding of it, is broken.
 
 I have now found two fixes that do work, but I'm not really sure either are good ideas (especially from a packager's viewpoint). The first is to put AM_DISABLE_SHARED in my configure.ac to simply force static linking. This works great, but seems like a pretty blunt solution.
 
 The second solution I came up with was to add lines like this to the Makefile.am for the command-line programs:
 
 wavpack_LDFLAGS = -rpath $(libdir)
 
 This hardcodes “/usr/local/lib” into the binaries so that they'll try that directory first for the library, and this also works fine on all the systems I tried it on, but again I'm not sure how this will look from a packager's perspective.
 
 Sorry for the longwinded post, but I've been working on this for several days and I wanted to provide as much information as I could. Hopefully there's a Linux guru (or package maintainer!) on the list that can help. Any comments or insights or opinions on any of this are gladly welcome and appreciated!
 
 --David
 
 <!-- _filtered #yiv4379198767 {margin:0.79in;}#yiv4379198767 p {margin-bottom:0.1in;line-height:120%;}-->
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
WavPack-devel mailing list
Wav...@li...
https://lists.sourceforge.net/lists/listinfo/wavpack-devel