Any chance of a 64-bit version ?
SEVERE: /usr/fonality/hud-lite/configuration/org.eclipse.osgi/bundles/39/1/.cp/libswt-pi-gtk-3232.so: /usr/fonality/hud-lite/configuration/org.eclipse.osgi/bundles/39/1/.cp/libswt-pi-gtk-3232.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
java.lang.UnsatisfiedLinkError: /usr/fonality/hud-lite/configuration/org.eclipse.osgi/bundles/39/1/.cp/libswt-pi-gtk-3232.so: /usr/fonality/hud-lite/configuration/org.eclipse.osgi/bundles/39/1/.cp/libswt-pi-gtk-3232.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
and this is an investment in time that is well worth making, given that you won't be able to buy a 32-bit machine in a year or so, if you even can now without hunting through the "specials" bin...
Anyone who has not already made huge inroads with porting their applications to 64bit is in serious danger of being left by the wayside.
Its more than just recompiling. Asterisk is not optimized for 64bit code and there is only anecdotal information about any benefit of running Asterisk is 64bit mode so far. Every machine sold today will run 32bit code just fine. My new quad core mega machine is running 32bit Windows XP without any issues. so what is the benefit today is the core component wont realize much, if any, benefit to most users?
The only reasons I haven't done so are:
It's not pretty;
There is no build infrastructure (just run make and hope for the best);
I was hoping to have an intermediate server (between the desktop client and the management API) rather than the desktop clients all connecting directly to Asterisk;
The only functionality I really needed at the time was originating calls, so that's all it does (though it _can_ do anything that can be done via the management API);



Member Since:
2006-07-13