Forum: Installation

Post: how to install voltdb on power platform

how to install voltdb on power platform
wayne
Dec 18, 2015
when I compile voltb4.8 on IBM power platform, our evermient is rhel7.2 for ppc64le , I receive the follow error ,
does anyone know how to resolve the problem ? thks

[exec] ../../third_party/cpp/ttmath/ttmathint.h:790:5: note: ttmath::Int<value_size>::Int(const wstring&) [with unsigned int value_size = 2u; std::wstring = std::basic_string<wchar_t>] <near match>
[exec] Int(const std::wstring & s) {
[exec] ^
[exec] ../../third_party/cpp/ttmath/ttmathint.h:790:5: note: no known conversion for argument 1 from ?.onst int64_t {aka const long int}?.to ?.onst wstring& {aka const std::basic_string<wchar_t>&}?
[exec] ../../third_party/cpp/ttmath/ttmathint.h:783:5: note: ttmath::Int<value_size>::Int(const string&) [with unsigned int value_size = 2u; std::string = std::basic_string<char>] <near match>
[exec] Int(const std::string & s) {
[exec] ^
[exec] ../../third_party/cpp/ttmath/ttmathint.h:783:5: note: no known conversion for argument 1 from ?.onst int64_t {aka const long int}?.to ?.onst string& {aka const std::basic_string<char>&}?
[exec] ../../third_party/cpp/ttmath/ttmathint.h:776:5: note: ttmath::Int<value_size>::Int(const wchar_t*) [with unsigned int value_size = 2u] <near match>
[exec] Int(const wchar_t * s) {
[exec] ^
[exec] ../../third_party/cpp/ttmath/ttmathint.h:776:5: note: no known conversion for argument 1 from ?.onst int64_t {aka const long int}?.to ?.onst wchar_t*?
[exec] ../../third_party/cpp/ttmath/ttmathint.h:769:5: note: ttmath::Int<value_size>::Int(const char*) [with unsigned int value_size = 2u] <near match>
[exec] Int(const char * s) {
[exec] ^
[exec] ../../third_party/cpp/ttmath/ttmathint.h:769:5: note: no known conversion for argument 1 from ?.onst int64_t {aka const long int}?.to ?.onst char*?
[exec] ../../third_party/cpp/ttmath/ttmathint.h:705:5: note: ttmath::Int<value_size>::Int(ttmath::uint) [with unsigned int value_size = 2u; ttmath::uint = unsigned int]
[exec] Int(uint i) {
[exec] ^
[exec] ../../third_party/cpp/ttmath/ttmathint.h:667:5: note: ttmath::Int<value_size>::Int(const ttmath::Int<value_size>&) [with unsigned int value_size = 2u]
[exec] Int(const Int<value_size> & u) :
[exec] ^
[exec] ../../third_party/cpp/ttmath/ttmathint.h:660:5: note: ttmath::Int<value_size>::Int(ttmath::sint) [with unsigned int value_size = 2u; ttmath::sint = int]
[exec] Int(sint i) {
[exec] ^
[exec] cc1plus: all warnings being treated as errors
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/indexcountexecutor.co] Error 1
[exec] make: *** [objects/executors/indexscanexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/deleteexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/unionexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/materializedscanexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/nestloopindexexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/insertexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/storage/TableCatalogDelegate.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/executors/abstractexecutor.co] Error 1
[exec] make: *** [objects/executors/tablecountexecutor.co] Error 1
[exec] cc1plus: all warnings being treated as errors
[exec] make: *** [objects/storage/persistenttable.co] Error 1
[exec] make: Leaving directory `/opt/voltdb/voltdb-voltdb-4.8/obj/release'

BUILD FAILED
/opt/voltdb/voltdb-voltdb-4.8/build.xml:1191: exec returned: 255
bballard
Dec 18, 2015
Hi Wayne,

Power is not a supported platform. We support 64-bit Linux on Intel architecture, and we have a development build for Mac OS X which is also Intel architecture.

If you look in the build.xml and build.py files, you will find various flags and settings which enable Intel-specific features. Doubtless many of those would need to be changed, and perhaps various Power-specific settings would need to be made, but beyond that, we don't know how much of the build process would have to be rewritten in order to get VoltDB to compile on Power.

You might find it easier to attempt to compile the C++ client on Power, and run the database on Intel.

Best regards,
Ben
AndrewScott
Oct 18, 2016
I think it's a mistake to overlook Power. The new Power based hardware runs little endian, and you can purchase equipment today that can be configured with 32TB of memory. For an in-memory database, running on that kind of platform should be attractive. The lower-end S-series machines from IBM are cheaper than Intel-based Enterprise class hardware, and the price/performance delta is nuts.

But enough of that, I'm attempting to build VoltDB on Power myself. I'm having much more success than the original poster, so I'll share that here and hope somebody can help me with the stuff I'm getting stuck on:

First, in build.py, you need to get rid of the Intel specific compiler flags in the "RELEASE" CTX.LEVEl conditional:

if CTX.LEVEL == "RELEASE":
CTX.CPPFLAGS += " -g3 -O3 -mmmx -msse -msse2 -msse3 -DNDEBUG -DVOLT_LOG_LEVEL=%s" % LOG_LEVEL
CTX.OUTPUT_PREFIX = "obj/release"

Delete the stuff in bold italics. Add "-m64 and -mcpu=power8 (power powerpc, or power5/6/7). The block will now look like this:


if CTX.LEVEL == "RELEASE":
CTX.CPPFLAGS += " -g3 -O3 -m64 -mcpu=power8 -DNDEBUG -DVOLT_LOG_LEVEL=%s" % LOG_LEVEL
CTX.OUTPUT_PREFIX = "obj/release"

vi bafter removing those, I was able to build some of the binaries, but there were still a lot of errors and the build failed, complaining about -Wno-float-conversion being set. So, back into build.py and I find this block:

# Do we want -Wno-float-conversion?
if (CTX.compilerMinorVersion() == 8):
CTX.CPPFLAGS += " -Wno-float-conversion"

My version of gcc doesn't support this flag (these warnings appear to be covered by -Wconversion anyway). So I changed it to -Wconversion.

Now, it builds... sort of. It gets through a bunch of CXX compiles without error, then spits out this error:

[exec] /home/ads5176/voltdb/src/ee/voltdbjni.cpp:1341:2: error: #error VoltDB server requires that your kernel headers define __NR_sync_file_range.
[exec] #error VoltDB server requires that your kernel headers define __NR_sync_file_range.
[exec] ^
[exec] In file included from /home/ads5176/voltdb/src/ee/common/common.h:55:0,
[exec] from /home/ads5176/voltdb/src/ee/common/tabletuple.h:49,
[exec] from /home/ads5176/voltdb/src/ee/executors/OptimizedProjector.cpp:51:
[exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp: In static member function ‘static bool voltdb::NValue::oversizeWholeDecimal(voltdb::TTInt)’:
[exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp:630:38: error: call of overloaded ‘Int(const uint64_t&)’ is ambiguous
[exec] return (TTInt(kMaxWholeFactor) <= ii / kMaxWholeDivisor);

From this point, it throws a ton of warnings and bomb out without compiling any of the java parts.

So this is where we need to make some code changes. PowerPC doesn't use sync_file_range(), it uses sync_file_range2() to address a register size mismatch between Intel and Power.

I found references to this syscall in:

src/ee/voltdbjni.cpp
src/ee/org_voltdb_utils_PosixAdvice.h
src/frontend/org/voltcore/utils/Bits.java
src/frontend/org/voltdb/DefaultSnapshotDataTarget.java
src/frontend/org/voltdb/SimpleFileSnapshotDataTarget.java
src/frontend/orga/voltdb/utils/PosixAdvise.h

Now, because I'm silly, I just did a global search/replace for the syscall and changed it to sync_file_range2. Just to see what would happen. It still blew up. So fixing that is going to be a bit more involved.

I'm also getting a lot of errors like this:

[exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:776:5: note: no known conversion for argument 1 from ‘const int64_t {aka const long int}’ to ‘const wchar_t*’

Whole lot of "no known conversion" messages. Not sure if it's a warning or an error, but there's some casting going on the compiler doesnt' like.

All that said, I think it's pretty close. I have some successfully built binaries in the bin directory and a pile of successfully compiled libraries, too. But it's dying trying to build and link the voltdbjni.cpp file.

Any pointers on how to properly modify these to get around some of this?

My system:
Power8, 1 core, 4GB memory
SLES 12 SP1
Kernel 3.12.49-11
gcc 4.8.5
ant 1.9.7 (compiled locally for P8)
AndrewScott
Oct 19, 2016
So, I have it building up to a point. It dies compiling deleteexecutor.cpp with this error stream:

  [exec] g++  -Wall -Wextra -Werror -Woverloaded-virtual -Wpointer-arith -Wcast-qual -Wwrite-strings -Winit-self -Wno-sign-compare -Wno-unused-parameter -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DNOCLOCK -fno-omit-frame-pointer -fvisibility=default -DBOOST_SP_DISABLE_THREADS -DBOOST_DISABLE_THREADS -DBOOST_ALL_NO_LIB -pthread -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-conversion -Wno-ignored-qualifiers -fno-strict-aliasing -std=c++11 -g3 -O3 -m64 -mcpu=power8 -DNDEBUG -DVOLT_LOG_LEVEL=500 -Wno-attributes -Wcast-align -DLINUX -fpic -isystem /home/ads5176/voltdb/third_party/cpp -I/home/ads5176/voltdb/src/ee -I/home/ads5176/voltdb/obj/release/3pty-install/include -I/home/ads5176/voltdb/obj/release  -c  -MMD -MP -o objects/executors/deleteexecutor.o /home/ads5176/voltdb/src/ee/executors/deleteexecutor.cpp
     [exec] In file included from /home/ads5176/voltdb/src/ee/common/common.h:55:0,
     [exec]                  from /home/ads5176/voltdb/src/ee/common/tabletuple.h:49,
     [exec]                  from /home/ads5176/voltdb/src/ee/stats/StatsSource.h:21,
     [exec]                  from /home/ads5176/voltdb/src/ee/stats/StatsAgent.cpp:19:
     [exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp: In static member function ‘static bool voltdb::NValue::oversizeWholeDecimal(voltdb::TTInt)’:
     [exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp:630:38: error: call of overloaded ‘Int(const uint64_t&)’ is ambiguous
     [exec]          return (TTInt(kMaxWholeFactor) <= ii / kMaxWholeDivisor);
     [exec]                                       ^
     [exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp:630:38: note: candidates are:
     [exec] In file included from /home/ads5176/voltdb/src/ee/common/NValue.hpp:35:0,
     [exec]                  from /home/ads5176/voltdb/src/ee/common/common.h:55,
     [exec]                  from /home/ads5176/voltdb/src/ee/common/tabletuple.h:49,
     [exec]                  from /home/ads5176/voltdb/src/ee/stats/StatsSource.h:21,
     [exec]                  from /home/ads5176/voltdb/src/ee/stats/StatsAgent.cpp:19:
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:790:5: note: ttmath::Int<value_size>::Int(const wstring&) [with unsigned int value_size = 2u; std::wstring = std::basic_string<wchar_t>] <near match>
     [exec]      Int(const std::wstring & s) {
     [exec]      ^
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:790:5: note:   no known conversion for argument 1 from ‘const uint64_t {aka const long unsigned int}’ to ‘const wstring& {aka const std::basic_string<wchar_t>&}’
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:783:5: note: ttmath::Int<value_size>::Int(const string&) [with unsigned int value_size = 2u; std::string = std::basic_string<char>] <near match>
     [exec]      Int(const std::string & s) {
     [exec]      ^
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:783:5: note:   no known conversion for argument 1 from ‘const uint64_t {aka const long unsigned int}’ to ‘const string& {aka const std::basic_string<char>&}’
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:776:5: note: ttmath::Int<value_size>::Int(const wchar_t*) [with unsigned int value_size = 2u] <near match>
     [exec]      Int(const wchar_t * s) {
     [exec]      ^
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:776:5: note:   no known conversion for argument 1 from ‘const uint64_t {aka const long unsigned int}’ to ‘const wchar_t*’
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:769:5: note: ttmath::Int<value_size>::Int(const char*) [with unsigned int value_size = 2u] <near match>
     [exec]      Int(const char * s) {
     [exec]      ^
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:769:5: note:   no known conversion for argument 1 from ‘const uint64_t {aka const long unsigned int}’ to ‘const char*’
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:705:5: note: ttmath::Int<value_size>::Int(ttmath::uint) [with unsigned int value_size = 2u; ttmath::uint = unsigned int]
     [exec]      Int(uint i) {
     [exec]      ^
     [exec] /home/ads5176/voltdb/third_party/cpp/ttmath/ttmathint.h:667:5: note: ttmath::Int<value_size>::Int(const ttmath::Int<value_size>&) [with unsigned int value_size = 2u]
...


It goes on from there. It's all centered around an ambiguous overloaded datatype: ‘Int(const uint64_t&)’
Now, I built all this on AMD just fine, so there's something in the build process I'm missing or isn't getting built that should remedy this ambiguity. But this is a big project and I'm not a terribly experience programmer, so I'm having difficulty finding it.

Anybody have any clues?
AndrewScott
Oct 19, 2016
Ok, I've changed the error:

 [exec] g++  -Wall -Wextra -Werror -Woverloaded-virtual -Wpointer-arith -Wcast-qual -Wwrite-strings -Winit-self -Wno-sign-compare -Wno-unused-parameter -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -DNOCLOCK -fno-omit-frame-pointer -fvisibility=default -DBOOST_SP_DISABLE_THREADS -DBOOST_DISABLE_THREADS -DBOOST_ALL_NO_LIB -pthread -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-conversion -Wno-ignored-qualifiers -fno-strict-aliasing -std=c++11 -g3 -O3 -m64 -mcpu=power8 -DNDEBUG -DVOLT_LOG_LEVEL=500 -Wno-attributes -Wcast-align -DLINUX -fpic -isystem /home/ads5176/voltdb/third_party/cpp -I/home/ads5176/voltdb/src/ee -I/home/ads5176/voltdb/obj/release/3pty-install/include -I/home/ads5176/voltdb/obj/release  -c  -MMD -MP -o objects/executors/deleteexecutor.o /home/ads5176/voltdb/src/ee/executors/deleteexecutor.cpp
     [exec] In file included from /home/ads5176/voltdb/src/ee/common/TheHashinator.h:21:0,
     [exec]                  from /home/ads5176/voltdb/src/ee/voltdbjni.cpp:106:
     [exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp: In static member function ‘static bool voltdb::NValue::oversizeWholeDecimal(voltdb::TTInt)’:
     [exec] /home/ads5176/voltdb/src/ee/common/NValue.hpp:632:38: error: call of overloaded ‘Int(const uint64_t&)’ is ambiguous
     [exec]          return (TTInt(kMaxWholeFactor) <= ii / kMaxWholeDivisor);


So, this uint datatype is coming from the included ttmath third party library.
That library has templates for X86_32 and X86_64 with inline assembler. I added a #define TTMATH_NOASM to deleteexecutor.cpp to tell the preprocessor to use the non-asm portions of the library, but I think I may have the directive in the wrong place, because it's still seeing all the different versions of the ttmath functions instead of necking down to the versions it needs.

Any clues? Bueller?
rmorgenstein
Oct 19, 2016
Andrew,

This is great stuff you are doing! Our C++ gurus are heads down right now, but I'll try to get you some answers in the next day or two.

Ruth
AndrewScott
Oct 19, 2016
Andrew,

This is great stuff you are doing! Our C++ gurus are heads down right now, but I'll try to get you some answers in the next day or two.

Ruth


Thanks!

I forgot to share my sync_file_range() "fix". The "fix" is quotes because I just made it compile. No idea if it actually works yet.

You guys are declaring a sync_file_range() method in the PosixAdvise.java file that maps to the native Linux sync_file_range() syscall. Your original code looks like this:

 /*
     * Be aware sync_file_range does not make data durable. It doesn't handle ordering with metadata
     * nor does it emit write barriers
     */
    public static native long sync_file_range(long fd, long offset, long size, int flags);
    public static long sync_file_range(FileDescriptor fd, long offset, long size, int flags) {
        final long filedescriptor = SharedSecrets.getJavaIOFileDescriptorAccess().get(fd);
        return sync_file_range(filedescriptor, offset, size, flags);
    }
}


For people reading this that aren't Java coders and just trying to make it build, the "public static native..." line is where the function is being made available to Java as a native syscall. What we have here appears to be good coding. They've made the syscall available, but then encased it in a Java method and call the java method elsewhere in the project. This prevents the rest of the app from calling the syscall directly. They have to go through this code block first, which makes it possible to translate this function call without having to go searching through the rest of the project.

the x86 version is sync_file_range(long fd, long offset, long size, int flags).
The ppc64 version is sync_file_range2(long fs, int flags, long offset, long size).

They re-ordered the arguments a tad.

This clever code block means we can change the native to match what we need, then change the call to the native in the Java class to put the arguments in the right spots.

So change it to:


/*
     * Be aware sync_file_range does not make data durable. It doesn't handle ordering with metadata
     * nor does it emit write barriers
     */
    public static native long sync_file_range2(long fd, int flags, long offset, long size);
    public static long sync_file_range(FileDescriptor fd, long offset, long size, int flags) {
        final long filedescriptor = SharedSecrets.getJavaIOFileDescriptorAccess().get(fd);
        return sync_file_range(filedescriptor, flags, offset, size);
    }
}


Then, in voltdbjni.cpp, fix the compiler directive to look for the proper syscall:

existing:

#ifdef LINUX
#ifndef __NR_sync_file_range
#error VoltDB server requires that your kernel headers define __NR_sync_file_range.
#endi


Change it to:

#ifdef LINUX
#ifndef __NR_sync_file_range2
#error VoltDB server requires that your kernel headers define __NR_sync_file_range2.
#endi


Now, I don't know if what I'm doing will actually run right. I'm just trying to get it to compile. So your mileage may vary. I'm a total hack.

I'm also grabbing IBM's toolkit and SDK. They have an Eclipse module that supposed to be able to scan code and find stuff that doesn't port right, and even suggest new ways to code it. It includes and inline ASM translator, so fingers crossed it can handle the ttmath library for me. I'm not sure I have time to bone up on assembler for two different architectures right now.
sowani
Dec 8, 2016
Please excuse my audacity, but I think there is some issue in following code (which was changed for P8LE):

public static native long sync_file_range2(long fd, int flags, long offset, long size);
public static long sync_file_range(FileDescriptor fd, long offset, long size, int flags) {
final long filedescriptor = SharedSecrets.getJavaIOFileDescriptorAccess().get(fd);
return sync_file_range(filedescriptor, flags, offset, size);
}

I understood that the exposed call was changed to sync_file_range2 as this is what is available on ppc64le. But what I don't understand is _inside_ the java wrapper, shouldn't that be sync_file_range2 instead of just sync_file_range?

Again I am not a java programmer, so I might be completely wrong here. But I would like to understand it better.

Thanks,
Atul.
AndrewScott
Dec 8, 2016
Please excuse my audacity, but I think there is some issue in following code (which was changed for P8LE):

public static native long sync_file_range2(long fd, int flags, long offset, long size);
public static long sync_file_range(FileDescriptor fd, long offset, long size, int flags) {
final long filedescriptor = SharedSecrets.getJavaIOFileDescriptorAccess().get(fd);
return sync_file_range(filedescriptor, flags, offset, size);
}

I understood that the exposed call was changed to sync_file_range2 as this is what is available on ppc64le. But what I don't understand is _inside_ the java wrapper, shouldn't that be sync_file_range2 instead of just sync_file_range?

Again I am not a java programmer, so I might be completely wrong here. But I would like to understand it better.

Thanks,
Atul.


You're right. That's a typo. I reordered the arguments but forgot the two when I pasted it into the thread. The return sync_file_range() should be sync_file_range2 with the arguments in the proper order
bwhite
Dec 8, 2016
Do you have a github clone of voltdb/voltdb with this on it?

I spend some time with the VoltDB build procedure and I'd like to look at what you've done. I can't promise to use it for anything, but I'd like to look at it anyway.

Thanks for all the time you've put into it.
AndrewScott
Dec 8, 2016
Do you have a github clone of voltdb/voltdb with this on it?

I spend some time with the VoltDB build procedure and I'd like to look at what you've done. I can't promise to use it for anything, but I'd like to look at it anyway.

Thanks for all the time you've put into it.


I haven't. It's honestly not good enough to submit back to the project.

I may be getting some more professional help soon, so keep an eye out.
sowani
Dec 9, 2016
Thanks @AndrewScott for the clarification. I am trying to build VoltDB on ppc64le. So far I made changes to build.py (same as you) to get rid of SSE specific flags. I also required to change buildtools.py in order to get OpenSSL built. Intel-specific flags were hardcoded in this file and had to change it to fit P8LE. Next I ran into the sync_file_range issue and at present I am trying out your changes in the java code. Thanks again for putting so much effort in this!

Best regards,
Atul.
sowani
Dec 16, 2016
Finally, I am able to build VoltDB on ppc64le. I would say it is in initial stage and no testing has been done. I will start testing ported voltdb now.

To get it built on ppc64le, I had to do following:

1. Implement the changes as discussed on this thread (by Andrew Scott, very valuable).

2. Modify build.py and buidtools.py to change x86 specific hardcoded values.

3. Introduce (a lot of) type casts at all such places which mixes int64_t and TTInt/TTLInt. There is something peculiar to the compilation flags VoltDB is using because for my sample program which uses TTmath, I was able to directly assign int64_t to TTInt. However VoltDB creates a lot of complaints about it. I used the very same flags to compile my sample program and get it too to complain about the assignment. So it is something flag specific and I need to investigate it further.

4. I bypassed third-party module crc since it contains too much of x86 assembly code. VoltDB build process did not complain anyway. So if there is any hard functional dependency on crc, I will come to know while doing the tests. In such case, might need to check if this code can be replaced with any generic crc solution (something like http://www.libcrc.org/).

5. Make VoltDB compilation more relaxed by removing -Werror flag.

I will keep updating this thread with my findings while testing VoltDB. Any comments, suggestions, constructive criticism are most welcome! :) And last but not the least, a big thank you to this wonderful community for all the help I got in this task!
sowani
Dec 16, 2016
I rolled back my changes just to study the build failures and their causes in details. Here is a quick summary about what I found so far regarding #3 in post #13. There are a couple of things which are causing these typecasting errors - first a set of compiler flags and second - include paths being given to the compiler.

-Wextra and -Werror cause compiler to be very strick and bail out at the first chance to do so.
"-I/root/voltdb/src/ee -I/root/voltdb/obj/release/3pty-install/include -I/root/voltdb/obj/release" are being passed to compiler which confuses it. I tried specifying exactly the same include paths to my sample application (which builds and executes fine otherwise) and caused it to fail in compilation. Typical error looks something like:

[exec] In file included from /root/voltdb/src/ee/common/TheHashinator.h:21:0,
[exec] from /root/voltdb/src/ee/voltdbjni.cpp:106:
[exec] /root/voltdb/src/ee/common/NValue.hpp: In static member function 'static bool voltdb::NValue::oversizeWholeDecimal(voltdb::TTInt)':
[exec] /root/voltdb/src/ee/common/NValue.hpp:630:38: error: call of overloaded 'Int(const uint64_t&)' is ambiguous
[exec] return (TTInt(kMaxWholeFactor) <= ii / kMaxWholeDivisor);
[exec] ^
[exec] In file included from /root/voltdb/src/ee/common/NValue.hpp:35:0,
[exec] from /root/voltdb/src/ee/common/TheHashinator.h:21,
[exec] from /root/voltdb/src/ee/voltdbjni.cpp:106:
[exec] /root/voltdb/third_party/cpp/ttmath/ttmathint.h:705:5: note: candidate: ttmath::Int<value_size>::Int(ttmath::uint) [with unsigned int value_size = 2u; ttmath::uint = unsigned int]
[exec] Int(uint i) {
[exec] ^
[exec] /root/voltdb/third_party/cpp/ttmath/ttmathint.h:667:5: note: candidate: ttmath::Int<value_size>::Int(const ttmath::Int<value_size>&) [with unsigned int value_size = 2u]
[exec] Int(const Int<value_size> & u) :
[exec] ^
[exec] /root/voltdb/third_party/cpp/ttmath/ttmathint.h:660:5: note: candidate: ttmath::Int<value_size>::Int(ttmath::sint) [with unsigned int value_size = 2u; ttmath::sint = int]
[exec] Int(sint i) {
[exec] ^

This exact code builds just fine and gives correct results if I don't specify those multiple "-I"s.
sowani
Dec 19, 2016
Update on crc module: It appears that this module is _must_, as it is being used for logging and saving the database. I have opened separate thread on "VoltDB Architecture" for this (https://forum.voltdb.com/showthread.php?1585-Any-alternative-for-quot-thirdparty-cpp-crc-quot&p=4748#post4748).
sowani
Dec 21, 2016
A quick update on crc: I disabled hardware solution and forced software crc calculations. So far it is working fine.
rmorgenstein
Dec 22, 2016
Atul,

It sounds like you've made a lot of progress. What have you tried so far?
We have a test suite you can run on the c++ code in the ee. Type this to run it:
ant eecheck

Ruth
sowani
Dec 22, 2016
Thanks! Out of the 60 test cases in the unit test suite, 6 test cases are failing. The is a final suspected culprit - the ntohll macro in serializeio.hpp - I was getting a overflow error/warning in that. I am tweaking with it now.
sowani
Jan 5, 2017
I am facing an issue with the version of ttmath included in VoltDB source. I am opening a new thread at https://forum.voltdb.com/showthread.php?1586-u-int64_t-to-TTInt-conversion-misbehaving-with-VoltDB-s-ttmath-library&p=4756#post4756 since it is slightly different from the topic of this thread.