James Gates wrote: >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). > > the dynamic client libraries are available for 5.0 as well...in a typical MySQL release area you will find both the static and dynamic version of client library and that was our initial plan as well....however, we can just ship the dynamic version of client libraries and take out the static library.
>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. > > The following static libraries exist in typical MySQL install area: libdbug.a, libmysys.a , libmystrings.a , libz.a. (in addition to client static library). I am working with MySQL to get a definitive answer about their use case ... > > >>>...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 >> >> >_______________________________________________ >webstack-discuss mailing list >webstack-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/webstack-discuss > >
