[Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Irene <Irene Huang Sun COM>]

Hi, Harish 

I built evolution 2.6 on my Solaris X86 the other day. The build process
was successful, however, as soon as I started evolution-2.6, it crashed.
We investigated this problem and arrived at the following conclusions:

camel_vee_folder_hash_folder in
evolution-data-server/camle/camel-vee-folder.c invokes functions
including md5_init, md5_update and md5_final. The fact is, two copies of
md5_utils.[c|h] with exactly same functions defined, exist in the
evolution system, one in evolution-data-server/libedataser and the other
in evolution/e-utils. Camel-vee-folder.c includes
evolution-data-server/libedataserver/md5-utils.h, but when evolution
runs, the md5_* functions in evolution/e-utils/md5-utils.c instead of
those in evolution-data-server/libedataserver/md5-utils.c are invoked,
which we think should not be the case. 

Currently, the MD5Context structures in
evolution-data-server/libedataserver/md5-utils.h and
evolution/e-utils/md5-utils.h are different with the first one not
having a doByteReverse member. 

When evolution-2.6 is run, the ctx variable in
camel_vee_folder_hash_folder does not have doByteReverse, but it is
passed into the md5_* functions, a doByteReverse (which actually points
to something else in the stack) is modified.  This is the reason why
evolution-2.6 crashes under Solaris. We are curious why it works well
under linux with the stack illegally changed.

When we went further into this issue, we saw that there's a huge lot of
duplication in evolution-data-server/libedataser and evolution/e-utils.
With such duplications, similar problems may surface in the future when
one copy of the code is modified while the other remains unchanged. 

We think that something should be done to solve this problem.