[SERVER-17563] GPerfTools does not build on PPC64 (Power8) platform Created: 12/Mar/15 Updated: 08/Jan/24 Resolved: 11/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | 3.0.0 |
| Fix Version/s: | 3.2.5, 3.3.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jorik Blaas | Assignee: | Mark Benvenuto |
| Resolution: | Done | Votes: | 0 |
| Labels: | code-only | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Completed: | |||||||||
| Steps To Reproduce: | get a linux ppc64/power8 system, then untar a clean 3.0.0 mongodb build, and run 'scons --js-engine=none' |
||||||||
| Participants: | |||||||||
| Description |
|
It seems that mongodb in version 3.0 always includes the gperf header (coming from the cpu_profile_command), even through the command is only available when mongodb is explicitly built with the profiler.
|
| Comments |
| Comment by Githook User [ 08/Mar/16 ] |
|
Author: {u'username': u'markbenvenuto', u'name': u'Mark Benvenuto', u'email': u'mark.benvenuto@mongodb.com'}Message: (cherry picked from commit df981d0766beb3e1c423f72eba1831ec510bd457) |
| Comment by Githook User [ 11/Feb/16 ] |
|
Author: {u'username': u'markbenvenuto', u'name': u'Mark Benvenuto', u'email': u'mark.benvenuto@mongodb.com'}Message: |
| Comment by Andrew Morrow (Inactive) [ 18/May/15 ] |
|
jorik.blaas@synerscope.com Some of them, possibly. However, many of the replication and sharding tests expect to be able to spawn servers from the shell while running tests, this will not work against a remote server. |
| Comment by Jorik Blaas [ 18/May/15 ] |
|
Would I be able to run the integration tests from a different machine (with JS), against this power8 machine as a remote? |
| Comment by Andrew Morrow (Inactive) [ 18/May/15 ] |
|
jorik.blaas@synerscope.com - Yes, that is correct. Please note that MongoDB does no testing on Power8 at this time, so this is definitely not a supported configuration. Additionally, you will not be able to run the JavaScript integration tests because they require the mongo shell, which you can't build when using --js-engine=none. |
| Comment by Jorik Blaas [ 18/May/15 ] |
|
That was the combination that did it, I now have a mongodb build, haven't run any tests yet. ~/build/mongodb-src-r3.0.0$ scons --js-engine=none --allocator=system --wiredtiger=off -j40 Install file: "build/linux2/allocator_system/wiredtiger_off/mongo/mongod" as "mongod" That does mean that I do not have V8 javascript, do not have wiredtiger, and are not using tcmalloc, right? |
| Comment by Andrew Morrow (Inactive) [ 18/May/15 ] |
|
WiredTiger as embedded in the MongoDB source tree does not currently support PPC64. You can disable it when building by adding --wiredtiger=off to the SCons invocation. |
| Comment by Jorik Blaas [ 18/May/15 ] |
|
I think this is more about memory write barriers than about disk write barriers (as the link you have posted seems to suggest). |
| Comment by Anup Halarnkar [ 18/May/15 ] |
|
Thanks Jorik. Any idea on how this option of turning off write barrier could help or not? Thanks, |
| Comment by Jorik Blaas [ 18/May/15 ] |
|
v8 by default isn't available on power8, so that is causing a compilation failure. When compiling with scons --js-engine=none --allocator=system The error becomes different once again, due to an unimplemented WRITE_BARRIER primitive. gcc -o build/linux2/allocator_system/third_party/wiredtiger/src/block/block_ext.o -c -std=c99 -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -Werror -O3 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-but-set-variable -Wno-missing-braces -fno-builtin-memcmp -DBOOST_ALL_NO_LIB -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -DMONGO_OPTIMIZED_BUILD -DMONGO_BYTE_ORDER=1234 -D_FILE_OFFSET_BITS=64 -DMONGO_HAVE___THREAD -DMONGO_HAVE_CXX11_ATOMICS -DMONGO_HAVE_HEADER_UNISTD_H -DMONGO_HAVE_POSIX_MONOTONIC_CLOCK -DMONGO_HAVE_EXECINFO_BACKTRACE -D_GNU_SOURCE -DHAVE_BUILTIN_EXTENSION_ZLIB -DHAVE_BUILTIN_EXTENSION_SNAPPY -Ibuild/linux2/allocator_system/third_party/wiredtiger -Isrc/third_party/wiredtiger -Isrc/third_party/snappy-1.1.2 -Isrc/third_party/zlib-1.2.8 -Ibuild/linux2/allocator_system/third_party/wiredtiger/src/include -Isrc/third_party/wiredtiger/src/include -Ibuild/linux2/allocator_system/third_party/wiredtiger/build_linux -Isrc/third_party/wiredtiger/build_linux src/third_party/wiredtiger/src/block/block_ext.c |
| Comment by Anup Halarnkar [ 18/May/15 ] |
|
Hi Sam, g++ -o build/PowerPC/allocator_system/third_party/snappy-1.1.2/snappy-sinksource.o -c -Wnon-virtual-dtor -Woverloaded-virtual -std=c++11 -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -O2 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-but-set-variable -Wno-missing-braces -fno-builtin-memcmp -Wno-sign-compare -Wno-unused-function -DPCRE_STATIC -Isrc/third_party/snappy-1.1.2 -Ibuild/PowerPC/allocator_system -Isrc src/third_party/snappy-1.1.2/snappy-sinksource.cc if (Acquire_Load(once) != ONCE_STATE_DONE) { ^ src/third_party/v8/src/once.h: In function 'void v8::internal::CallOnce(v8::internal::OnceType*, typename v8::internal::OneArgFunction<Arg*>::type, Arg*)': src/third_party/v8/src/once.h:115:24: error: cannot convert 'v8::internal::OnceType* {aka long int*} ' to 'const volatile Atomic32* {aka const volatile int*}' for argument '1' to 'v8::internal::Atomic32 v8::internal::Acquire_Load(const volatile Atomic32*)' ' to 'volatile Atomic32* {aka volatile int*}' for argument '1' to 'void v8::internal::NoBarrier_Store(volatile Atomic32*, v8::internal::Atomic32)' Thanks in advance, |
| Comment by Anup Halarnkar [ 18/May/15 ] |
|
Hi Sam, |
| Comment by Sam Kleinman (Inactive) [ 15/May/15 ] |
|
Hello, Sorry for not getting back to you sooner. We've looked into this issue, but it looks like there's an interaction between the default allocator tcmalloc and gperftools on PPC/Power systems. If you can pass --allocator=system to scons when you build mongod does this work? Regards, |