Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
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
[Clamav-users] clamav-devel (20050316) and zlib-1.2.2
I am trying to statically compile zlib-1.2.2 into my clamav installation on FreeBSD 4.11. cd zlib-1.2.2 ./configure make cd ../clamav-devel ./configure --with-zlib=../zlib-1.2.2 [other opts] I get this error: cut checking for pthread.h... yes checking for zlib installation... using ../zlib-1.2.2 configure: error: Please install zlib and zlib-devel packages /cut I'm thinking this should be the correct way. I don't intend to install zlib-1.2.2 over what is on my system until they import it into the base system ;) -Wash http://www.netmeister.org/news/learn2quote.html -- +==+ |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ God doesn't play dice. -- Albert Einstein ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
On Mar 16, 2005, at 10:24, Odhiambo Washington wrote: I am trying to statically compile zlib-1.2.2 into my clamav installation on FreeBSD 4.11. cd zlib-1.2.2 ./configure make cd ../clamav-devel ./configure --with-zlib=../zlib-1.2.2 [other opts] This is obviously wrong and wont give you the results you are after. I get this error: cut checking for pthread.h... yes checking for zlib installation... using ../zlib-1.2.2 configure: error: Please install zlib and zlib-devel packages /cut I'm thinking this should be the correct way. I don't intend to install zlib-1.2.2 over what is on my system until they import it into the base system ;) When you configure zlib without specifying a prefix it will defalut to /usr/local and wont overwrite your existing zlib if it is installed in /usr however, I offer the following advice. If libz.a is installed in /usr/lib then build zlib 1.2.2 with the following command. ./configure --prefix=/usr make make install. If libz.a is installed in /usr/local/lib then build zlib 1.2.2 with the following command. ./configure make make install. If libz.a is installed in another folder, let me know where and I'll give you a proper build/install command. By installing an updated zlib, it wont break your system or anything that depends on the zlib libraries and is a safe upgrade to perform from a user standpoint. Don't be afraid, no harm will come to your system and later when they get it into the RPM's, nothing will break when you update other apps. As well, I recommend building from source everything you require on your system rather than installing someone's RPM, most RPM's are generic in nature and you usually end up getting stuff you don't want or need, don't get me wrong, I think RPM's are useful as a base to work from and that is where I would start, a basic RPM of the latest OS and build from there. You also get less problems when you build your own over someone's RPM's and you don't have to wait on anybody to fix anything that doesn't work properly. -Wash -- Dale ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
* Dale Walsh [EMAIL PROTECTED] [20050316 19:40]: wrote: On Mar 16, 2005, at 10:24, Odhiambo Washington wrote: I am trying to statically compile zlib-1.2.2 into my clamav installation on FreeBSD 4.11. cd zlib-1.2.2 ./configure make cd ../clamav-devel ./configure --with-zlib=../zlib-1.2.2 [other opts] This is obviously wrong and wont give you the results you are after. Oh! I get this error: cut checking for pthread.h... yes checking for zlib installation... using ../zlib-1.2.2 configure: error: Please install zlib and zlib-devel packages /cut I'm thinking this should be the correct way. I don't intend to install zlib-1.2.2 over what is on my system until they import it into the base system ;) When you configure zlib without specifying a prefix it will defalut to /usr/local and wont overwrite your existing zlib if it is installed in /usr. Well, that is what I actually expected! I don't want to overwrite the system's zlib. however, I offer the following advice. If libz.a is installed in /usr/lib then build zlib 1.2.2 with the following command. ./configure --prefix=/usr make make install. If libz.a is installed in /usr/local/lib then build zlib 1.2.2 with the following command. ./configure make make install. If libz.a is installed in another folder, let me know where and I'll give you a proper build/install command. I actually don't want to overwrite system zlib. I mentioned that in my post, no? By installing an updated zlib, it wont break your system or anything that depends on the zlib libraries and is a safe upgrade to perform from a user standpoint. I don't want to mess with this server at all. I just want to see the diff between two clamds compiled differently. Don't be afraid, no harm will come to your system and later when they get it into the RPM's, nothing will break when you update other apps. I run FreeBSD, so I'm allergic to RPMs ;-) As well, I recommend building from source ..that is what I always do with clamav... [The rest of the story snipped]. 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 http://www.netmeister.org/news/learn2quote.html -- +==+ |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ The trouble with a kitten is that When it grows up, it's always a cat -- Ogden Nash. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
On Mar 16, 2005, at 14:08, Odhiambo Washington wrote: * Dale Walsh [EMAIL PROTECTED] [20050316 19:40]: wrote: On Mar 16, 2005, at 10:24, Odhiambo Washington wrote: I am trying to statically compile zlib-1.2.2 into my clamav installation on FreeBSD 4.11. cd zlib-1.2.2 ./configure make cd ../clamav-devel ./configure --with-zlib=../zlib-1.2.2 [other opts] This is obviously wrong and wont give you the results you are after. Oh! I get this error: cut checking for pthread.h... yes checking for zlib installation... using ../zlib-1.2.2 configure: error: Please install zlib and zlib-devel packages /cut I'm thinking this should be the correct way. I don't intend to install zlib-1.2.2 over what is on my system until they import it into the base system ;) When you configure zlib without specifying a prefix it will defalut to /usr/local and wont overwrite your existing zlib if it is installed in /usr. Well, that is what I actually expected! I don't want to overwrite the system's zlib. however, I offer the following advice. If libz.a is installed in /usr/lib then build zlib 1.2.2 with the following command. ./configure --prefix=/usr make make install. If libz.a is installed in /usr/local/lib then build zlib 1.2.2 with the following command. ./configure make make install. If libz.a is installed in another folder, let me know where and I'll give you a proper build/install command. I actually don't want to overwrite system zlib. I mentioned that in my post, no? By installing an updated zlib, it wont break your system or anything that depends on the zlib libraries and is a safe upgrade to perform from a user standpoint. I don't want to mess with this server at all. I just want to see the diff between two clamds compiled differently. Don't be afraid, no harm will come to your system and later when they get it into the RPM's, nothing will break when you update other apps. I run FreeBSD, so I'm allergic to RPMs ;-) As well, I recommend building from source ..that is what I always do with clamav... [The rest of the story snipped]. 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 ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
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 ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
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. 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. 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. 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. It's your system and your opinion to deploy it in any way you wish, making a fuss over zlib doesn't make a whole lot of sense to most people but you don't need my permission to install it they way you want, just consider the consequences of following this path is all I suggest and recommend. -- Dale ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
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 ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav-devel (20050316) and zlib-1.2.2
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. I don't run into this problem, all my systems are the same, latest version of zlib installed, latest version of ClamAV, each system identical, I do a test install on an off-line server and if all works as intended I then deploy the application. Installing multiple version of zlib doesn't make sense to me because of dependancy issues and issues that System Engineers have explained regarding simultaneous loading/linking of multiple version and the potential problems based on this that I don't want to experience. Your comments on my comments haven't helped the original poster figure out he should do it the right way, your comments don't really help him at all, you spent too much time attacking what I suggested without acknowledging why it was suggested or even offering an alternative method for him to use. He doesn't want to overwrite the existing zlib or ClamAV, he wants to install it just to see what the differences are, if you have another way of installing both so he can see the differences I'm sure he'd be happy to read it as would I. Basically
