It's because sles11sp1 build image has libjemalloc.so.2 compiled from sources — something we should never do in our VMs.
There are two possible fixes:

• remove self-compiled jemalloc and install one from SLES repository
• if that's not possible, only keep self-compiled static libjemalloc_pic.a, remove all libjemalloc.so* dynamic libraries.

There is no jemalloc available from Suse for SLES 11, so we'll have to go with your second option.

I removed the libjemalloc.so* libraries from but we're still getting the same error.

http://buildbot.askmonty.org/buildbot/builders/kvm-zyp-sles11sp1-amd64/builds/132

serg: Anything else I can try?

This comes, apparently, from 10.1.10 packages in our repository. Now, when packages are 10.1.11 recent builds show this error:

+ sudo zypper --no-refresh --no-gpg-checks install -y rpms/MariaDB-10.1.11-sles11sp1-x86_64-client.rpm rpms/MariaDB-10.1.11-sles11sp1-x86_64-common.rpm rpms/MariaDB-10.1.11-sles11sp1-x86_64-connect-engine.rpm rpms/MariaDB-10.1.11-sles11sp1-x86_64-devel.rpm rpms/MariaDB-10.1.11-sles11sp1-x86_64-server.rpm rpms/MariaDB-10.1.11-sles11sp1-x86_64-shared.rpm rpms/MariaDB-10.1.11-sles11sp1-x86_64-test.rpm

...

Problem: nothing provides libstdc++.so.6(GLIBCXX_3.4.11)(64bit) needed by galera-25.3.9-1.sles11.sle11.x86_64

Problem: nothing provides libjemalloc.so.2()(64bit) needed by MariaDB-server-10.1.10-1.x86_64

So

1. galera cannot be installed, it needs newer glibc
2. for some reason zypper looks at 10.1.10 from the repository even if there is 10.1.10 or even 10.1.11 on the command line

reassigning to nirbhay_c to look at galera issue

Since, new galera packages (starting v3.12) are now being built on buildbot's regular build images (besides a few exceptions), I am hoping that this should get resolved after dbart refreshes the galera packages.

nirbhay_c, does dbart know he should refresh something, should the issue maybe be reassigned to him?

I just noticed that its only failing on SP1. At the moment we do not have a galera build for it. I will add one.

There is some problem with sp1 networking. Besides, its has an old gcc (4.3).
Once the net issue is resolved (dbart), I will takeover to build gcc-4.7 (and possibly boost?).

We now have a galera builder for SLES11-SP1 in place.

The first run of the sles11sp1 builder using the new Galera 25.3.14 package from the new galera test repository has completed.

http://buildbot.askmonty.org/buildbot/builders/kvm-zyp-sles11sp1-amd64/builds/177/steps/test/logs/stdio

MariaDB actually installs and runs, and the galera package installs, but the test has trouble when it tries to load the galera library. The library doesn't appear to be where it is expected to be.

nirbhay_c: Is this something you need to look into? Or is there something I should do here?

Thanks.

The library is there, but for some reason the server is not able to open it.
ERROR 1126 (HY000): Can't open shared library '/usr/lib64/galera/libgalera_smm.so' (errno: 0, )

@dbart: I will look into this.

From the error log :

2016-02-10 15:08:42 140656434842368 [ERROR] WSREP: wsrep_load(): dlopen(): /usr/lib64/galera/libgalera_smm.so: symbol _ZNSt15__exception_ptr13exception_ptrC1Ev, version CXXABI_1.3.3 not defined in file libstdc++.so.6 with link time reference

The new package worked well.
https://internal.askmonty.org/buildbot/builders/kvm-zyp-sles11sp1-amd64/builds/178

with the new package from nirbhay, this issue is fixed