From: Carsten H. (T. R. <ra...@ra...> - 2007-10-05 16:50:33
|
On Fri, 5 Oct 2007 09:35:31 -0700 Michael Jennings <e-...@ka...> babbled: > On Friday, 05 October 2007, at 15:17:19 (+0900), > Carsten Haitzler wrote: > > > ok- looking at the patch gives me meat to chew on :) overall this > > looks good. i'm a little dubious of the whole libtool version thing > > - i actually HATE it. i'd prefer the libtool > > revision/version/whatever stuff is sourced/generated from the > > package itself (eg 0.5.0 for edje) and we will increment this ONE > > version info only. i know what major and minor versions mean - most > > developers do/should so i'd rather have a single version tag there > > if possible - all the space used up by the libtool scheme comments > > could work on some script mojo to work out the libtool version magic > > from the package version. i really want to keep them consistent at > > all times if possible. thats my only issue - otherwise it seems ok > > to me. > > The problem is, this is simply not the way shared library versioning > works. The dynamic linker has specific ideas about how to tell which > shared libraries will work with which executables based on the > soversion, and your way of thinking about it violates that. There is > absolutely no reason why, for example, an app linked against Imlib2 > 1.3.0 cannot continue to work (albeit improved) with 1.3.1 unless the > ABI changes. That's why if you properly follow the libtool guidelines > previously mentioned, you'll have to rebuild your binaries if, and > only if, the shared library interface actually changes. i know how it works :) i just don't want to work with libtool's abortion of a versioning system. i want to do it the old fashioned way. .so major version changes == abi break. old calls removed or changed abi or functionality. minor version == calls added, but no functionality changes in existing calls. micro == no calls added or removed, no functionality changes, just internal fixes/improvements. i want to keep the version of the package the same as the lib .so version. it's cleaner and nicer. unless we go screw things up and decide to name release versions without thought to compatibility - then we need to do the below, but if we do things right, we don't need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or whatever) as opposed to 1.0.0. i will make the package release # the same as the lib .so version as needed. > If, however, you have a shared library that really DOES need to be > tied to a specific version of the package (like libEterm is tied to > each version of Eterm, for obvious reasons), instead of using > "-version-info X:Y:Z" use "-release $(VERSION)". That is the accepted > libtool way of doing what you want without wreaking havoc on poor > defenseless ld.so. nooo - i don't want to make a new .so for each version with -release. there is no need to put the link version directly in the library name. i ONLY need to do this if i plan on having 2 or more versions of the lib around AND application needing to explicitly link at compile time to either a newer or older version. eg. gtk2 vs gtk1. (at that point - mayaswell have new lib names too as the version is now part of the lib name anyway as far as ld.so etc. are concerned). > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "But I dumped her. My motto is, 'Get out before they go down.'" > "That is so *not* my motto." > -- Monica Geller and Joey Tribbiani, "Friends" > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |