Re: [Libevent-users] Question: Library naming
Trond Norbye wrote: I thought that it was normal to name the libraries like libname.so.major.minor.micro (eg: libevent.so.1.3.4) and create symbolic links so the application may pick up the newest version of the library (with the correct ABI) without re-linking the application. As did I, and I've wondered about this for a while. Is there a good reason for not doing so? Nick, have you given any thought to this? I'm surprised to see your arguments about preserving compatibility considering that each client application needs to be relinked to pick up libevent bugfixes, and many versions of libevent kept around on systems where they haven't been. libevent's APIs (existing functions' signatures + struct event layout) changes infrequently enough that I think most releases could just be a minor version bump. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Question: Library naming
On Tue, Oct 02, 2007 at 08:14:32PM -0700, Scott Lamb wrote: Trond Norbye wrote: I thought that it was normal to name the libraries like libname.so.major.minor.micro (eg: libevent.so.1.3.4) and create symbolic links so the application may pick up the newest version of the library (with the correct ABI) without re-linking the application. As did I, and I've wondered about this for a while. Is there a good reason for not doing so? Nick, have you given any thought to this? I'm surprised to see your arguments about preserving compatibility considering that each client application needs to be relinked to pick up libevent bugfixes, and many versions of libevent kept around on systems where they haven't been. libevent's APIs (existing functions' signatures + struct event layout) changes infrequently enough that I think most releases could just be a minor version bump. Agreed; I believe the only reason that neither Niels or I has made the change is that neither of us knows libtool very well. It would be good if somebody would submit a patch to do the right thing, and explain which numbers we need to bump in the future when the version changes and/or when we lose backward compatibility. With any luck, it's as simple as messing with libevent_la_LDFLAGS in in Makefile.am. yrs, -- Nick Mathewson pgpzy9irhQOLc.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
[Libevent-users] Question: Library naming
I have intalled libevent 1.3c and 1.3d on my machine, and I have some questions about the naming used for libevent. In my lib-directory I get the following: lrwxrwxrwx 1 bin bin 22 Sep 24 21:09 libevent-1.3c.so.1 - libevent-1.3c.so.1.0.3 -rwxr-xr-x 1 bin bin 160824 Sep 24 21:09 libevent-1.3c.so.1.0.3 lrwxrwxrwx 1 bin bin 22 Sep 24 19:21 libevent-1.3d.so.1 - libevent-1.3d.so.1.0.3 -rwxr-xr-x 1 bin bin 303856 Sep 24 19:21 libevent-1.3d.so.1.0.3 lrwxrwxrwx 1 bin bin 22 Sep 24 19:21 libevent.so - libevent-1.3d.so.1.0.3 When I look at the dynamic section in the libraries I see that it records libevent-1.3[cd].so.1 as the soname, so if I link my application with libevent it will require the same version of libevent to be located at runtime. I thought that it was normal to name the libraries like libname.so.major.minor.micro (eg: libevent.so.1.3.4) and create symbolic links so the application may pick up the newest version of the library (with the correct ABI) without re-linking the application. Is there a good reason for not doing so? Trond (I looked in the archive and found http://monkeymail.org/archives/libevent-users/2006-March/000114.html, but I did not find a response to the question). ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
