On Oct 4, 2010, at 5:08 PM, Dennis Peterson <denni...@inetnw.com> wrote:
> On 10/4/10 10:03 AM, Al Varnell wrote: >> On 10/4/10 9:39 AM, "Erwan David"<er...@rail.eu.org> wrote: >> >>> On 04/10/10 18:25, Dennis Peterson wrote: >>>> On 10/4/10 9:20 AM, Al Varnell wrote: >>>>> On 10/4/10 7:51 AM, "Dennis Peterson"<denni...@inetnw.com> wrote: >>>>> >>>>>> On 10/1/10 11:30 PM, Al Varnell wrote: >>>>>>> On 10/1/10 12:07 AM, "Dennis Peterson"<denni...@inetnw.com> wrote: >>>>>>> >>>>>>>> A short term solution until Apple updates bzip2 is to install >>>>>>>> MacPorts if >>>>>>>> not >>>>>>>> already installed, and use it to install bzip2. It will install it in >>>>>>>> /opt/local >>>>>>>> so you need to add an option to your clamav configure statement: >>>>>>>> >>>>>>>> configure --with-libbz2-prefix=/opt/local ... >>>>>>>> >>>>>>>> It should build and run fine. >>>>>>>> >>>>>>> What you said is correct, as far as it goes, but realize that bzip2 >>>>>>> 1.0.6 is >>>>>>> not necessary to compile clamav correctly since clamav provides it's >>>>>>> own >>>>>>> bzip library. What it will do is lose the warning which is only >>>>>>> there to >>>>>>> let the user know that he has a bugged version of bzip on his computer. >>>>>>> Using a port to correct the bug is fine as long as the directory is >>>>>>> included >>>>>>> in the users path. If it isn't then you've defeated the purpose of the >>>>>>> compilers check. >>>>>> >>>>>> As much as I dislike bzip2 I have customers that require it. Leaving >>>>>> it out is >>>>>> not an option. Doesn't mean I have to be happy about it :) >>>>>> >>>>> Sorry, I wasn't clear. I didn't mean one should leave it out, just >>>>> that if >>>>> you do install the MacPorts version in /opt/local you need to make >>>>> sure that >>>>> this is included in the path designation or your customer won't >>>>> benefit by >>>>> it's being there. >>>>> >>>>> >>>>> -Al- >>>>> >>>> >>>> Ah - yes. One should test it using otool which is similar to ldd in Linux: >>>> >>>> otool -l /usr/local/sbin/clamd (much stuff deleted from the output) >>>> >>>> Load command 14 >>>> cmd LC_LOAD_DYLIB >>>> cmdsize 56 >>>> name /opt/local/lib/libbz2.1.0.dylib (offset 24) >>>> time stamp 2 Wed Dec 31 16:00:02 1969 >>>> current version 1.0.6 >>>> compatibility version 1.0.0 >>>> >>>> This shows the full path to the dylib is hardcoded into clamd. >>>> >>> >>> No it does not show this. otool (like ldd) could resolve the lib and >>> write where it found it, and where the loader would find it. >>> >> Well this is scary. How come I'm getting this: >> >> Load command 13 >> cmd LC_LOAD_DYLIB >> cmdsize 52 >> name /usr/lib/libbz2.1.0.dylib (offset 24) >> time stamp 2 Wed Dec 31 16:00:02 1969 >> current version 1.0.2 >> compatibility version 1.0.0 >> >> and >> >> bzip2 --version >> bzip2, a block-sorting file compressor. Version 1.0.5, 10-Dec-2007. >> >> >> -Al- >> > > That is the old version in its normal location. My original is still there, > too. > > Did you build a new version of bzip2 and tell clamav where to find it? > > > configure --with-libbz2-prefix=/opt/local # My new bzip2 is in > > /opt/local/... > I troubleshoot ClamXav for users and it's important for me to not get ahead of the ClamXav developer or Apple, so I must leave things as they are until Mark has a chance to compile and release 0.96.3 and or Apple gets around to fixing bzip2. I just don't understand why itool found the current version to be 1.0.2 when I'm at 1.0.5? The libbz2.1.0dylib alias points to libbz2.1.0.5dylib, as it should. Sent from my iPad -Al- -- Al Varnell _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
