On Monday 12 December 2011 04:02:50 Rainer Gerhards wrote: > On Fri, Dec 9, 2011 at 5:34 PM, Mike Frysinger wrote: > > On Friday 09 December 2011 06:21:18 Rainer Gerhards wrote: > >> I am trying to build a program so that it does not refer to shared > >> libraries by their version-specific name but rather a generic one. My > >> intent is to use checkinstall to generate packages. > >> > >> As a concrete example, I use some basic openssl functionality that is > >> available in both newer and older versions of the library (without any > >> ABI issues). In essence, it does not matter if 0.9.x or 1.0.x is used. > >> However, after my program is built, the exact version number seems to > >> be required. So if I build on an older system and move the binary over > >> to the newer one, the new one complains that 0.9.x is not available > >> (which is fine with me, because 1.0.x does nicely). And vice versa for > >> the other direction. > > > > it isn't possible to link against "libssl.so" and have that be recorded. > > you have to realize that the differences between them isn't simply > > naming ... they changed because the binary interfaces between the two > > versions changed. > > > > the closest you could do is load the library with dlopen(), then use > > dlsym() to look up specific funcs, and then hope the specific functions > > you're using didn't actually change between versions. > > Thanks, this explains the problem. So I probably need to think about > going the dlopen() way as I know the function has not changed, so > from my PoV either version is well. i don't know how portable you need to be, but libtool provides a libltdl helper library that hides the cross system issues that arise from libdl. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
