|
Mark, FYI, we have successfully built and deployed a 64 bit version of the UW Imap package and a shared version of the c-client library on Solaris and have been running the c-client library as a 64 bit shared object with PHP for several months now. It has been working just fine. It appears that you fixed a couple of problems in the 2007 release that were breaking the 64 bit version of imapd and that is now working just fine (along with everything else) in 64 bit mode. The main benefit/requirement for a 64 bit build (at least of the c-client library) is to link in with a 64 bit build of Apache/PHP/Perl, etc.. In addition - those of us doing voice services using asterisk are also using the c-client lib for voicemail service. We are running all of our voice software as 64 bit apps. Why is 64 bit valuable? One main thing is it removes the 256 file descriptor limit for streams - substantial roadblock to any applications that may open hundreds or thousands of streams at a time. In general I don't see not building apps 64 bit these days if you are running on a 64 bit capable processor. Not doing so is just delaying the inevitable obsolescence that will occur as more and more apps and coders depend on 64 bit characteristics. The arguments against building 64 bit - like it takes more memory - just don't hold water. The amount of additional memory is insignificant and at a system level is substantially less since you don't have to load both 64 bit and 32 bit versions of various libraries. In addition - kernels don't have to context switch between 32 and 64 bit modes for system calls from 32 bit apps. These are just a few of the top reasons - there are no doubt many more albeit of lesser consequence and benefit. It would be so nice if the UW imap c-client library build was setup to properly build as both a static and a shared library. Internally we have modified your build to handle this but it is specific to our world. It would be so much better if the library had an appropriately correct name (eg: libuwimap.so) and had the appropriate shared object versioning so that it would be consistent with the way shared objects are handled in other packages. Having a clearly identifiable name (c-client is far too generic) that uniquely identifies the library so that other packages (php, and no doubt other unnamed apps) could properly find the library and the header files in standard search paths (for instance, /usr/local/include/uwimap) or better yet just /usr/local/include if the header file could be limited to just external interfaces in a single file would make incorporating the UW Imap libraries a far more predictable process that would likely require a lot less support from yourself in dealing with odd bugs that turn out to be related to the way things have been linked to some old, static version of c-client. Basically what I am saying - at least for Solaris is that UW Imap is already 64 bit capable - this is just the age old issue of needing shared library support. Mark Crispin wrote: 64-bit builds are not supported; nor is the software likely to derive much (if any) benefit by being built in 64-bits. Building in 64-bits has worked for some people, but not for others. --
| ||||||
_______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
