Analytics Software

What version of BDB are you using?

As best as we can tell clang 3.9.0 has not been released yet.

We generally do not do testing against unreleased software.

Can you explain what you are doing in more detail and what

the purpose is?

Hi, This is db-6.2.23

It's same with clang 3.7 and 3.8. It's not clang that is problem, it is problem when using libc++/libc++abi instead of libstdc++/libsupc++ as c++ api library. I assume atomic implementation in libc++ conflicts with one in gcc/libstdc++/whatever.

I'm trying to move away from gcc to clang, and bdb is one of few packages that doesn't build with clang and its runtime libraries. Note that libc++ isn't default in any distro that I know (yet), which is probably why nobody reported this. It can be made default when building clang by specifying a cmake option, or at runtime, by running clang++ with -stdlib=libc++ parameter.

hmm -- we do build with clang.  We will take a deeper look and figure out what is going on and correct.

This isnt something we can get to immediately but we will add it to our list to get resolved.

Thanks for the information on the other versions of clang. 

We have dug a little deeper into this issue.   We do not believe this is an issue with CLANG.

What we are seeing is compatibility issues with C++ 11.   We did several tests on a MAC

using CLANG with versions of C++ < 11 and the builds were fine.   It looks like what we have

now is a namespace collision.  Internally we will create a project to deal with this issue.   We need

to scope the effort first to decide if this is a simple bug fix or whether major changes are involved.

Either way, we will ensure that BDB builds with C++ 11 by the next BDB release.

Have there been any developments on this issue? I'm running into it with clang/libc++ 3.8 (on a Mac) and am struggling to even find a workaround. Do you have any suggestions for how to get it working in the short term? I have exactly the same error log as the original poster had.

To clarify, I'm seeing this exact issue on 5.3.28 and on 6.0.20, and there appear to be at least two separate issues: one is that the store macro uses a common name and breaks that atomic C++ header, and the other is that something it does seems to break usage of atomic_flag and friends. You can see both happening in the OP's log, but I wanted to make sure that it was clear that they were actually different issues.

Oddly enough, this was all working fine for me on clang+libc++ 3.7, but has now started breaking horribly.

Would really appreciate a suggestion for a workaround until upstream can deal with it properly. I tried disabling atomics in the configure script but this isn't actually caused by BDB trying to use atomics, but rather by it importing a really basic header (iostream) which indirectly imports atomic.

we are looking into this and trying to figure out what the best solution is for it.

The problem is with C++ 11 we now get a name conflict where with prior versions of C++ we did not.   The header files for C++ changed.

  We are finding 2 issues.

   1) In our db.h header file we have a #define store(a,b) __db_dbm_store(a,b).  Our definition which we have had for over 15 years is now conflicting with a definition in C++/v1/atomic.h

      as a temp fix -- check your db_int.h file and see if DB_DBM_HSEARCH is set to 1.   If you remove this then this error should go away.

  2)  the other issue is with atomic_init conflicting.   This is conflicting with our definition in src/dbinc/atomic.h --   as temp fix, you can go and rename it.  Then you will need to also rename in the code where it is being used.    Here is what we see:

In file included from ../lang/cxx/cxx_channel.cpp:13:

In file included from ./db_cxx.h:55:

In file included from /usr/bin/../include/c++/v1/iostream:38:

In file included from /usr/bin/../include/c++/v1/ios:216:

In file included from /usr/bin/../include/c++/v1/__locale:15:

In file included from /usr/bin/../include/c++/v1/string:442:

In file included from /usr/bin/../include/c++/v1/algorithm:634:

In file included from /usr/bin/../include/c++/v1/memory:618:

/usr/bin/../include/c++/v1/atomic:1148:1: error: expected ')'

atomic_init(volatile atomic<_Tp>* __o, _Tp __d) _NOEXCEPT

  3)   We are not seeing /usr/bin/../include/c++/v1/atomic:1717:35: error: unknown type name 'atomic_flag'.    This is a stranger one because is not in the function name but a type of a parameter.

     We did our testing on Ubuntu Linux.   So the above could be a platform issue.  We also did our testing with clang 3.8.   I do not know if clang 3.9 vs clang 3.8 brings in any different .h files for C++.

    The version of BDB is not the key issue here, since BDB has had these definitions for a very long time now.    C++ changed its header files and now there is a conflict.  We are working on the best solution. 

   If you debug the atomic_flag issue, please post what you find.

thanks

mike

Thanks for all the detail, it's very helpful (although I still don't have it building). What's confusing me is that I'm not going out of my way to build bdb in any way that enables c++11. All I'm doing is running a fairly standard build of bdb, on top of a clang 3.8 toolchain. Since clang has supported c++11 since 3.3, I'm struggling to see how the c++11 changes are really affecting this. I could see libc++ header changes accidentally overlapping with bdb defines, but what's extra odd to me is that libc++ 3.7 was calling store with one argument too: https://github.com/llvm-mirror/libcxx/blob/release_37/include/atomic#L1117 , and it worked fine for me. In fact, atomic didn't change very much between 3.7 and 3.8, so that's ultimately what's puzzling to me.

I'll let you know if I figure anything out about atomic_flag, or otherwise try to provide some instructions to reproduce the exact configuration that leads to that error.

If you take clang out of the picture, then we do see errors with C++11.  From what we can gather, clang 3.8 tool chain is bringing in c++ 11.   I wonder if based on what you are saying that the link is going against libc++ when maybe before it wasnt.  If store hasnt changed from libc++ 3.7 -> 3.8 , then may something is changing with what is being linked against.

I do not think we are at the bottom of this as far as understanding exactly what is happening.

We are pretty sure that our atomic_init definition now conflicts with C++ 11's standard interface. 

I should mention that we did have some clang compile issues on MAC 10.10 and we corrected those in 6.2.  those dealt with optimization levels.   If you are getting the same errors as in the first post here, then this would not be your issue.  I thought I would mention it. 

Can you send us how you are compiling BDB.  You said you are not going out of your way to bring in C++.   It makes me wonder if clang has some default setting that now brings in libc++ where as it didnt before.

Renaming atomic_init as you suggested also seems to resolve the issue with atomic_flag (patch: https://gist.github.com/LnL7/5153b251fd525fe15de69b67e63a6075)

However I'm not sure how to resolve the first issue, we could work around this during the build but then other packages would run into the same issue.

rename the BDB version of store() or check your db_int.h file and see if DB_DBM_HSEARCH is set to 1 and undefine.

I am not an expert on clang but is it possible that the pre 3.8 versions of clang used libstdc++ and starting with 3.8 it started using libc++.    I do not know if the original poster was on a Mac or not, but I think that libc++ is native to Mac but not to any other OS.

I also found this on "libc++" C++ Standard Library :  libc++ is a new implementation of the C++ standard library, targeting C++11.

These problems are definitely tied to C++11, and any framework that brings in C++ 11.

Can one of the posters getting the problem with store() please post their config.log file.

Also, lets us know how you are compiling BDB, what compile time options are being used.

Also, what is the exact platform you are running on.

While we can reproduce this in-house on linux, we are have to force it to happen.

It would be great if one of the posters getting the error on store posts their config.log file, passes along what compile time options they are using, describes what platform they are using, etc. 

We cannot reproduce the store error unless we force it to happen by setting the right compile time flags. 

thanks

This is the config.log when building against libc++3.8.1 on macOS https://gist.github.com/LnL7/f34a1f183dae610ef319fd0468577409. We currently use libc++-3.7.1 in our package manager and that works fine.

Thank you for the config.log. The '--enable-dbm' option you used explained why you had the store error.

Just a side node, the --enable-dbm option is used to make Berkeley DB API-compatible with the legacy DBM and NDBM interfaces. If your application doesn't use those interfaces, there is no need to specify that option.

Yong

Allright I'll try that, hopefully none of our packages need the legacy interfaces.

The __atomic_compare_exchange was also renamed in more recent versions, so the only thing that remains is atomic_init.