Build mongo current on OpenBSD : find egcc, ssl.h

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:

scons: Configure: Checking for SSL_version(NULL) in C library ssl... 
build/scons/opt/sconf_temp/conftest_42d562287bca6fadd943ac430ed30054_0.c <-
  |#include "openssl/ssl.h"
  |main() {
  |  SSL_version(NULL);
  |return 0;
/usr/local/bin/egcc -o build/scons/opt/sconf_temp/conftest_42d562287bca6fadd943ac430ed30054_0.o -c -std=c11 -Werror -fasynchronous-unwind-tables -ggdb -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -fno-omit-frame-pointer -fno-strict-aliasing -O2 -march=sandybridge -mtune=generic -mprefer-vector-width=128 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -Wno-missing-braces -fstack-protector-strong -fno-builtin-memcmp -fPIE -DNDEBUG build/scons/opt/sconf_temp/conftest_42d562287bca6fadd943ac430ed30054_0.c
/usr/local/bin/egcc -o build/scons/opt/sconf_temp/conftest_42d562287bca6fadd943ac430ed30054_0_a1ba5b757e2b0ce3219a399f52ae31c0 -Wl,--fatal-warnings -pthread -Wl,-z,now -fstack-protector-strong -Wl,--build-id -Wl,--hash-style=gnu -Wl,-z,noexecstack -Wl,--warn-execstack -Wl,-z,relro -Wl,--compress-debug-sections=none -pie -rdynamic build/scons/opt/sconf_temp/conftest_42d562287bca6fadd943ac430ed30054_0.o -lkvm -lcrypto -lssl -lcrypto -ldl
ld: error: unable to find library -ldl
collect2: error: ld returned 1 exit status
scons: Configure: no

There is no libdl on my system … if it’s looking for dlopen() that should be in libc on OpenBSD.

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.


Thanks, Andrew … I didn’t think it was going to be easy :wink:

Well, I made some progress but now it has gone bonkers and is looking for arm_neon.h

scons: Configure: Checking for C header file arm_neon.h... 
build/scons/opt/sconf_temp/conftest_ca1da64614a9ba196b2237c2c671e2f3_0.c <-
  |#include "arm_neon.h"

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.


Yes, @Andrew_Morrow , I’m sure you’re right about that.

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.


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)'

… and so on for a page or two.

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.

scons ... CCFLAGS=-march=core2

That got me farther. Now …

Compiling build/opt/mongo/db/user_write_block_mode_op_observer.o
virtual memory exhausted: Cannot allocate memory

which is funny because I don’t see it hitting swap. It just exhausts free physical RAM.

@Jack_Woehr -

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.


1 Like

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 …

1 Like

Using CCFLAGS="-march=core2 -g -link-model=dynamic" (-g strips everything :slight_smile: ) 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 :slight_smile: … 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.

1 Like

Got past the boost problem with this article … I added CXXFLAGS="-O2 -Wall -DNDEBUG"

1 Like

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.

1 Like


Sorry for the slightly OT question, but which debugging options are included within the --dbg flag?

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.

scons ... --separate-debug archive-servers{,-debug}

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.

1 Like

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.

1 Like

Thanks for the tips. I’m making glacial progress :slight_smile:

It is becoming obvious that if I wish to continue to pursue this, I’m going to have to allocate a more powerful machine.

1 Like

Hi @Jack_Woehr,

Have a look at this thread Build from source error in MongoDB v4.4 - #3 by Zikker

I had a similar problem before

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

1 Like

You maybe would also look into this post:

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: