Dale Walsh said: > > On Mar 17, 2005, at 00:03, Dennis Peterson wrote: > >> Dale Walsh said: >>> >>> On Mar 16, 2005, at 19:33, Dennis Peterson wrote: >>> >>>> Dale Walsh said: >>>>> >>>> >>>>>> >>>>>> Where are the archives of this list, like for last week? I remember >>>>>> someone mentioned how to do what I want to do and I think I am >>>>>> almost >>>>>> right in how I was doing it... I don't intent to install zlib-1.2.2 >>>>>> over my system's zlib! >>>>>> >>>>>> >>>>>> >>>>>> -Wash >>>>> >>>>> I guess you didn't understand my response. >>>>> >>>>> Doing this upgrade is safe and wont break anything and is >>>>> recommended. >>>>> >>>>> Installing it in a secondary location is not recommended and the >>>>> reasons should be obvious!!! >>>>> >>>>> This upgrade is recommended because it fixes some bugs, improves >>>>> performance and fixes some vulnerabilities. >>>>> >>>>> If you don't want to install it for any reason then give just give >>>>> up >>>>> on building anything that depends on it because without it they wont >>>>> build. >>>>> >>>>> Is that any clearer for you? >>>>> >>>>> -- Dale >>>> >>>> It's clear to me, Dale, and it's wrong. I wouldn't do it either. I >>>> get >>>> my >>>> system libs from Sun, for example, because they are guaranteed to >>>> work >>>> with my OS. Anything else goes into /usr/local where my compiled >>>> sources >>>> are told to look for it. Generalizations are usually a bad idea - >>>> including mine. It is best to leave it to each admin to manage the >>>> configuration of their OS's. >>>> >>>> In this instance the OP can put the path to his libs in his clamav >>>> configure. If that doesn't work (as revealed by ldd, for example) >>>> then >>>> he >>>> can hack the Makefile. >>>> >>>> dp >>> >>> Yes, you can hack the Makefile, but Sun doesn't do anything special to >>> the zlib installation so upgrading this app/library wont have any ill >>> effects. >> >> Rot. They give it a part number, they track dependancies, it becomes >> part >> of the total configuration management system, they upgrade it in a >> coordinated fashion and in concert with other dependent packages. Man >> pages are replaced, for example, and are placed where pkgadd/pkgrm >> expects >> to see them. pkginfo will give you accurate information about the >> running >> product. This is in no way limited to zlib. >> >>> >>> If you do a "./configure && make && make install", it will install in >>> "/usr/local" and you can point ClamAV to this library and it will work >>> as you expect however, you may experience other side-affects by having >>> two versions of zlib installed when library loading/linking occurs by >>> different applications. >> >> User error. >> >>> >>> If you're doing this for test purposes, go ahead and do it this way >>> but >>> if you're wishing to use it in deployment, this is not recommended >>> based on the problems that it causes unless soft-linking is employed >>> and very few applications use this linking method. >> >> I'd imagine that if you have 40 different systems to manage with your >> methodology you'd truely have 40 very different systems. >> >>> >>> Considering the problem that occur with loading several different >>> versions of the same application library, it should not pose any >>> serious problem and System Engineers may consider this approach to >>> determine compatibility on a test platform before deploying the >>> application. >> >> Thanks, no. The OP has it right. >> >> dp > > Unfortunately you have misunderstood the scope of this topic and the > information I have offered as something I recommend as a way of life.. > > I do have 14 systems to manage and I don't play games with any of them. > > Fortunately, the methodology isn't mine, it is the original poster who > wishes to install different version of ClamAV and by adding the latest, > a version requirement for zlib is being encountered that he doesn't > want to install. > > All I did was mention the potential problems, suggest that a temporary > install for testing purposes as described to me is about his only > possible option if he still wishes to test-install the latest ClamAV > without overwriting the current system installed zlib. > > In your case, you are saying you're basically stuck with the whatever > version is available based on your configuration system management > provides for you, hopefully they have the latest versions available.
Not at all. You can install libraries in non-standard locations all you like. That is yet another reason why it is not necessary to over-write your system libs with rpm's from God knows where, or compiled code that may or may not have the proper switches set (32 vs 64 bit, for example) as the OS vendor expects. The best advice for the OP is to learn more about his development environment and in particular, his linker. Done right there is absolutely no reason why his original configure setting wouldn't work provided he understands that it is a strick environment. dp _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
