Danek Duvall wrote: > On Mon, Oct 22, 2007 at 04:03:39PM -0700, Ritu Kamboj wrote: > > >>We shall be having version directory under both /var and /etc directory (ie >>/var/mysql/5.0/data and /etc/mysql/5.0. > > > Okay. > > >>We shall be having a symbolic link from /usr/mysql/5.0 to /usr/mysql. > > > That's physically impossible. Or do you simply mean that the subdirs in > /usr/mysql/5.0 will have links to them in /usr/mysql? > > >>>>/usr/mysql/5.0/lib/libdbug.a >>>>/usr/mysql/5.0/lib/libheap.a >>>>/usr/mysql/5.0/lib/libmyisam.a >>>>/usr/mysql/5.0/lib/libmyisammrg.a >>>>/usr/mysql/5.0/lib/libmysqlclient.a >>>>/usr/mysql/5.0/lib/libmysqlclient.la >>>>/usr/mysql/5.0/lib/libmysqlclient_r.a >>>>/usr/mysql/5.0/lib/libmysqlclient_r.la >>>>/usr/mysql/5.0/lib/libmystrings.a >>>>/usr/mysql/5.0/lib/libmysys.a >>>>/usr/mysql/5.0/lib/libvio.a >>>>/usr/mysql/5.0/lib/libz.a >>>>/usr/mysql/5.0/lib/libz.la >>>> >>> >>>Why are you delivering .a files? And what use are .la files on Solaris? >>> >> >>The MYSQL release area does not have shared library version for all the >>libraries > > > And people using mysql are generally content to rebuild their applications > whenever fixes are made to these libraries? We would never allow archive > libraries for a Sun-controlled project, but even though that's not the case > here, I'd like to get an idea of what the impact is for the (typical?) > end-user. > >
I assume that means for non-Sun projects, we shouldn't ship static archive libraries if the equivalent dynamic shared library is available? This is what we do with PostgreSQL (in fact, we don't ship any *.a's with PostgreSQL). The point Danek makes about people rebuilding their applications whenever fixes are installed, is particularly relevent for client libraries. Looking at MySQL version 4.0 which is currently shipped with Solaris (and held in the SFW consolidation), I see that there are dynamic versions of the client libraries libmysqlclient_r.so & libmysqlclient.so (they're installed in /usr/sfw/lib). Are these dynamic client libraries no longer built in MySQL 5.0? If they are, do you really have a good reason to ship libmysqlclient.a & libmysqlclient_r.a? If they aren't, do you know why not (seems like a bad change to me). As for the remaining .a libraries in your list (libheap.a, libmyisam.a, etc.). Does the customer really need these? I thought all client development could be performed with just libmysqlclient? These look like libraries only needed during linking of the server binary. >>...we are providing all the libraries that are provided in the default >>MySQL release area. > > > But why the .la files? And what's libz doing there? Is that the same libz > as in /usr/lib/libz.so.1? > > Danek
