On Apr 04, 2012, at 11:50 AM, Tomasz Kojm wrote:
> On Wed, 4 Apr 2012 22:58:01 +0800 boyd yang <boyd.yang@gmail.com>
> wrote:
>> Hi Guys,
>>
>> Cay I join the Mac Dev of clamav?
>> How can I know something about Mac dev of clamav?
>
> Hi,
>
> are you a mac developer? Have you ever played with ClamAV on OS X?
>
> Regards,
Some people claim to be a Mac developer and after examination of some
of the builds they provide, it is clear they are nothing more than
people with the ability to compile software on Mac OS X who posses a
little programming knowledge and very limited programming skill.
While I think it is great that someone wishes to help in the Mac
development department and I hope they bring their A-game because
nothing annoys me more than having to rebuild something for someone
else because the binaries they downloaded weren't built properly and
this in turn reflect a poor reputation of the ClamAV developers for
allowing such software to be released/distributed based on the
implication that it endorses the binary distribution.
My early 10.4.x work can be seen at:
http://www.daleenterprise.com/info.php#module_clamav http://www.daleenterprise.com/clamav_test.php <-- live test
http://www.daleenterprise.com/clamav_info.php Recent work to support my clients still running 10.5.x can be seen at
http://www.convertit2mac.com/info.php#module_clamav http://www.convertit2mac.com/clamav_test.php <-- live test
http://www.daleenterprise.com/clamav_info.php An installer package can be downloaded from http://
www.daleenterprise.com/ClamAV-0.97.4.tar.gz for those Mac ClamAV
developers who wish to examine the binaries for possible information
which can be extracted from the binaries and support files, better
for someone to download and distribute rather than passing out the
link, it will remain available for about 30 days.
Clearly you can see that I am more than capable of building the
software properly and having access to internal apple resources does
help ensure these binaries are OS environment compliant, I just don't
have the time to commit to development work but this doesn't mean I
can't spend some time checking out builds before they are released if
you intend to provide binaries for Mac OS X and hopefully the support
will be for multiple OS versions and architectures rather than only
the latest OS version.
When I built the binaries I modified the build scripts to make use of
special features of the ADE (Apple Developer Environment) so that I
could build for multiple architectures while targeting specific
environments during the compiling/linking phases to avoid cross
contamination during the build process, what this means is that when
it compiles for arch ppc it compiles it in a ppc environment, when
compiling in ppc64 is compiles this code in a ppc64 environment, when
compiling in i386 is compiles this code in a i386 environment, when
compiling in x86_64 is compiles this code in a x86_64 environment and
these environments are not aware of each other or the differences
between them, essentially the ADE is 4 separate OS environments
accessible through a common gateway, each architecture is
simultaneously built in it's environment then joined as a single
binary, kinda like building on 4 separate machines then using lipo
but much more complicated.
These binaries have been built in the ADE (Apple Developer
Environment) and as such are guaranteed to be OS environment
compliant, not compiled on an intel machine for a ppc build using
multiple architectures or a PowerPC machine for an intel build using
multiple architectures, the later does provide an acceptable
alternative build if you modify some files to alter the build process
for other architectures and you can get pretty damn close to an ADE
build.
Currently ClamAV does not support architecture endian compensation
compiling and this compensation is easy to add and it also does not
properly support 32 and 64 bit builds due to the method used to
calculate the size of things such as longs (as an example try
configuring with CFLAGS="-arch ppc -arch i386 -arch ppc64 -arch
x86_64") but shouldn't be too difficult to compensate for this based
on the compiling architecture.
Providing binaries while a nice concept for the lazy, it has many
pitfalls IMO, I believe it is better to provide a script which builds
the software properly, this allows people to apply modifications and
patches to the source and compile it knowing it will work properly
and provide the correct results, again, this is just my opinion.
-- Dale