There are more implementations of this function, actually, which clearly means that this is a bug. The offending one is in utils/skygw_utils.cc whereas there is a correct implementation in server/core/atomic.c. I haven't check if the first one is even used, but the current implementation stops maxscale from building on Power8 at least.

There's a temporary fix to this on the develop branch. The code in skygw_utils.cc is now the same as in atomic.c.

This only treats the symptoms but doesn't solve the real issue of having multiple definitions of atomic_add.

Any reason why something which is clearly a bug in the code, has the potential to cause all kind of problems and makes portability impossible is considered Minor?

The code in skygw_utils.cc has been corrected in line with atomic.c. That resolves the more serious issue. It makes the code compatible with any environment that either uses GCC or runs on an X86 processor. On other systems, the code will fail. Our recommendation is to always use GCC where available.

With the main issue resolved, the bug is kept open but reduced to minor status, as the remaining work is to eliminate the duplication of code (brought about by the mix of C and C++). This should be done, but is not critical.

The duplication of code has been fixed by explicitly including atomic.c in log_manager.cc. This does remove duplicate code, but is an inelegant way to deal with the problem. It would be better to ensure the atomic.c code is included through the make process, so the task remains open, although at a trivial level.

martin brampton is the duplication code fix already in develop branch ?

No, it is in the MXS-122 persistent connection branch. It did not seem worth the extra overhead to create a branch for what is only a code movement operation that tidies things up without making any functional change whatsoever. As stated earlier, it would be preferable to find a better solution, but it is a very minor issue.

martin brampton While the change is minor or trivial, the implication is that - not having this code change prevents from building MaxScale on POWER8. So I changed this back to Major - and if we could put the changes for this in separate branch other than the persistent connection branch. It should be a branch that can be merged in 1.2.0

Why would there be a problem on Power8? Is there a documented case to confirm that? Are we sure it is connected with atomic.c?

martin brampton Please see Anders comment on 2015-03-04 about, this "stops maxscale from building on Power8 at least."

That particular issue has been fixed by switching over to the GCC builtin functions.

markus makela Thanks ! I will move this to 1.2.1 now

I assumed that you were asking about the outstanding work. This item was moved from major to minor after the code in skygw_utils.cc was modified in line with atomic.c which had already been made hardware independent, as noted on 11th March. That fix is already released and is in the master branch at GitHub. The residual minor work is avoiding duplication of code, which has no functional implications whatsoever, and is therefore minor. Markus is working on a final solution to that, and if successful it can be incorporated into 1.2. It is a good thing to tidy up but is not of any great significance.