Okay @Andrew_Morrow, that got me past the compiler error (BTW for Gnu it’s CXX=/usr/local/bin/eg++) but stuck with openssl apparently because a dependent library is wanted:
I believe this is happening due to this logic in the build system:
MongoDB currently does no testing on any BSDs, so it isn’t surprising to me that there are some incorrect assumptions. Unfortunately, you will need to make a local fix to work past this. It is reasonable to assume that you will find other issues like this. In particular, you may find that several of the vendored third party libraries (MozJS, tcmalloc, and libunwind all come to mind) lack configurations for your platforms. You may need to disable features or build against a system version in order to work past those.
If I remember right, that is a misleading bit of information that the build spits out. The check for that is unconditional, but failing it doesn’t stop your build. It just happens to be the last check that gets run, so it looks suspicious when you see the “failed” result. I suspect there is another error happening elsewhere.
It doesn’t seem to make it into the failure log, but watching stdout I see what’s happening.
ISTR speed-reading some MongoDB docs that later versions of the x86_64 port require advanced instructions.
Well.
Here’s some output from the oldish computer on which I have OpenBSD installed that leads me to believe that the immediate problem is that the Intel(R) Core™2 Duo CPU T6500 is unsupported for MongoDB 5:
Compiling build/opt/mongo/db/ttl.o
/tmp//cch4k6rb.s: Assembler messages:
/tmp//cch4k6rb.s:3658: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:3668: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5245: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5266: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5275: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5470: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5491: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5500: Error: no such instruction: `vzeroupper'
/tmp//cch4k6rb.s:5820: Error: no such instruction: `vmovdqu 16(%rdx),%xmm0'
/tmp//cch4k6rb.s:5821: Error: no such instruction: `vmovaps %xmm0,-96(%rbp)'
/tmp//cch4k6rb.s:6000: Error: no such instruction: `vmovdqa -96(%rbp),%xmm1'
/tmp//cch4k6rb.s:6001: Error: no such instruction: `vmovaps %xmm1,-64(%rbp)'
Yeah, that looks like your assembler doesn’t like the codegen from the compiler. However you can override our default targeting of -march=sandybridge by providing your own -march argument to GCC, again on the command line, via CCFLAGS.
Building the server sources is fairly resource intensive. I recommend using the most powerful machine you can. But there are a few things you can try to reduce various sorts of resource constraints:
By default the build will use all available cores as found by the python psutil library. But you can reduce that on the command line by passing an explicit -j N argument. Cutting that N value back from using all your local cores should reduce the memory pressure during compilation.
Linking a static mongod binary can take a lot of memory. If you don’t need a production quality binary, you can build with --link-model=dynamic, which will instead build a mongod that links tons of little shared libraries. That makes the final link much less resource intensive.
If you must go with a static build but don’t need debug info after development, you can try building with CCFLAGS=-gsplit-dwarf, which should reduce the amount of memory and disk used to manage debug info, but the resulting build is really only appropriate for development use since you can’t take the debug info with you easily. Note that you are already passing an argument to CCFLAGS, so the syntax for passing multiple values is a space separated string: scons ... CCFLAGS="-march=core2 -gsplit-dwarf". There isn’t much use to -gsplit-dwarf for a --link-model=dynamic build, in our experience.
You can save a disk space on the installation by building with --install-action=hardlink, which will hardlink files into the installation directory, rather than copying them from the build directory. This will only work as long as your build directory and installation directory are on the same filesystem. If you have customized DESTDIR or similar, that may not be true.
All of the above comes with the caveat that all our developer experience with these flags is from macOS and Linux. So, just like with the code itself, your mileage may vary on BSDs.
Thanks for all the tips, @Andrew_Morrow … Will work with this today.
You’re right, it’s pretty silly to throw this little old laptop at this big compilation problem.
Of course I’m really using MongoDB on a mixture of more advanced platorms, Ubuntu and Fedora.
In the present case, I’m just trying to see the viability of OpenBSD as a modern MongoDB platform and had installed the latest OBSD cut on a little laptop. Thanks for your patience with my experiment!
PS I couldn’t make it accept --link-model=dynamic so I tried -link-model=dynamic (1 dash) and that is running now and has already gotten further than I got before …
Using CCFLAGS="-march=core2 -g -link-model=dynamic" (-g strips everything ) I was able to get far enough to run into errors that are based on the code … now I have to do some real work … My system doesn’t like boost::optional<long long> _N; …
@Jack_Woehr - That sounds like you are up and running on a working environment for doing the necessary porting. Please reach out of if you have further questions.
I’d be careful there. We already manage optimization flags like -O2 and we always build with -Wall. The setting -NDEBUG is also something we already manage for you, based on whether the build has the --dbg flag.
I definitely recommend hunting around in the top level SConstruct for these sorts of flags before introducing them via the command line. Yes, the file is huge and complex, but there is a lot of accumulated knowledge baked in there too.
The --dbg flag enables additional runtime checks within the server build, usually those deemed too expensive to be retained in a production build. It also enables the debugallocation subsystem of gperftools if you are building with the builtin version of that (which you are, by default), which catches some classes of memory use errors. One some platforms it may opt you into a debugging enabled C++ runtime. A build made with --dbg on is definitely not suitable for production use.
The --dbg flag does not, as is often and incorrectly assumed, have anything to do with whether we build with debugging symbols (e.g. the -g switch to GCC). We always build with debug symbols, and there is no switch to disable it. As a result, the binaries can be quite large. If you would like the binaries to be “production” sized like what you would get from our prebuilt packages, you can retain the debugging information as separated files by building with the --separate-debug flag. On non-windows paltforms, adding that flag will enable new installation and archiving targets with a -debug suffix which will install and archive just the debug symbols, respectively.
will get you two tgz files: one of debuginfo stripped server binaries, and another of the separated debug info for those binaries. Note that on windows, debug information is always separated into PDB files, so you don’t need to use the flag or the extra package name.
Oh, one more fun fact about the --dbg flag: when specified, it changes the build system default so as to disable compiler optimization in the interest of providing a better experience under debuggers. So if you are using the --dbg flag and you still want compiler optimization enabled, you need to explicitly opt in with --opt.
Basically, don’t use --dbg unless you are doing server development.
Thank you very much for the insight @Andrew_Morrow ! I was dealing with missing user stacks while doing off-CPU analysis on mongodb, I’ll see if the dbg flag will help me with that
MongoDB 6.0 is already compiling for FreeBSD, but it is segfaulting, maybe this will be also related to OpenBSD.
Maybe have a look here how mongodb 6.0 is build for FreeBSD: https://cgit.freebsd.org/ports/tree/databases/mongodb60
) I was able to get far enough to run into errors that are based on the code … now I have to do some real work