You ask for details so here they are.
I don't use MacPorts or any other non-standard build environment, I
don't suffer compiler bugs so I don't need 'CCFLAGS=-O0 to correct
a buggy compiler and I have applied every patch and bug-fix released
and experience no build issues with any other
I don't use MacPorts or any other non-standard build environment...
Your entire build system is non-standard if you maintain in the way you say
you do.
This is very likely an architecture issue and will require explicit casts
in order to work for you (which would cause performance decreases for
Why do people have to be so stupid and immediately implicate the
build tools or environment?
Because updates and bug-fixes were applied, your assuming that these
are not done correctly or in compliance with the OS and build
environment or that they are faulty.
First, you need to stop
You must not have read my email. I was not saying it is your build tool. I said
it was your architecture causing the LLVM type to not be implicitly casted to a
long int, likely due to register sizes on the PPC platform.
You will need to modify the code to explicitly cast the LLVM type to a long
FWIW i am currently asking friends if they have a PPC that i can try this one.
Sent from a computer
On Mar 26, 2014, at 1:37 PM, Brandon Perry bperry.volat...@gmail.com wrote:
You must not have read my email. I was not saying it is your build tool. I
said it was your architecture causing
FYI, This just in (from clamdoc.pdf):
quote
The following packages are optional, but required for bytecode JIT support:
GCC C and C++ compilers (minimum 4.1.3, recommended 4.3.4 or newer)
the package for these compilers are usually called: gcc, g++, or gcc-c++.
/quote
Mileage may be better
This also might be worth trying.
Dale, could you try appending this to your configure line and see if it
resolves the issue with your 4.x compiler?
Sent from a computer
On Mar 26, 2014, at 2:19 PM, Steven Morgan smor...@sourcefire.com wrote:
FYI, This just in (from clamdoc.pdf):
quote
