Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mroonga plugin build in MariaDB is not reproducible #298

Closed
ottok opened this issue Jan 9, 2020 · 40 comments
Closed

Mroonga plugin build in MariaDB is not reproducible #298

ottok opened this issue Jan 9, 2020 · 40 comments

Comments

@ottok
Copy link

ottok commented Jan 9, 2020

Reproducible builds are important for software supply chain security. See https://reproducible-builds.org/

All packages in Debian are tested for reproducibility. Currently the latest MariaDB 10.3 build in Debian fails due to the build of the Mroonga, RocksDB and TokuDB plugins. See https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mariadb-10.3.html

Based on the diffoscope data is seems Mroonga is embedding a random build ID in every build:
image

Could you please not do that, or alternative provide a build flag to turn it off?

Greetings,
MariaDB maintainer in Debian

@kou
Copy link
Member

kou commented Jan 10, 2020

We don't set it explicitly. Is it really set by us?
libc.so has NT_GNU_BUILD_ID on my Debian GNU/Linux sid:

$ readelf -Wn /usr/lib/x86_64-linux-gnu/libc.so.6

Displaying notes found in: .note.gnu.build-id
  Owner                Data size 	Description
  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 0cdf11eeac6a45568714f5e7af1013f6ba8cc5b6

Displaying notes found in: .note.ABI-tag
  Owner                Data size 	Description
  GNU                  0x00000010	NT_GNU_ABI_TAG (ABI version tag)	    OS: Linux, ABI: 3.2.0

If you want to remove NT_GNU_BUILD_ID entirely, you may be able to use strip --remove-section=.note.gnu.build-id ha_mroonga.so.

@ottok
Copy link
Author

ottok commented Jan 17, 2020

I will try passing --build-id=none which according to ld man pages should make the build-id go away.

@ottok
Copy link
Author

ottok commented Jan 17, 2020

Do you know if this DYNSTR is something unique to Mroonga? Seems the build-id is deterministic based on shasum of other files, so even though it has changed, it was not the root cause. Something else changed that affected it. Tips on what could be the root cause?

image

@kou
Copy link
Member

kou commented Jan 18, 2020

Could you show the diff of string ha_mroonga.so?

diff -u <(string /.../build1/ha_mroonga.so) <(string /.../build2/ha_mroonga.so)

It may show what string is changed.

@ottok
Copy link
Author

ottok commented Jan 26, 2020

One of the reproducible build guys suggested that the build path seems to be embedded into the resulting binary, which is useless and the a likely cause for the issue. Tentative fix below:

From: https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20200120/012028.html

I have no generalised advice to impart but I spent a little while on this today and managed to make src:mroonga almost reproducible using the following changes.

Firstly, I needed to prevent the ./configure options ending up in the
binary for some kind of "--show-config" switch. This embedded the
absolute build path; the CFLAGS contain -ffile-prefix-map with a value
with the absolute build dir:

--- a/configure.ac
+++ b/configure.ac
@@ -1539,7 +1539,7 @@ GRN_DEFS="$GRN_DEFS -DGRN_DEFAULT_DOCUME
 GRN_DEFS="$GRN_DEFS -DGRN_DEFAULT_RELATIVE_DOCUMENT_ROOT=\\\"\"\$(GRN_DEFAULT_RELATIVE_DOCUMENT_ROOT)\"\\\""
 AC_SUBST(GRN_DEFS)
 CFLAGS="$CFLAGS $OPT_CFLAGS "
-AC_DEFINE_UNQUOTED(CONFIGURE_OPTIONS, "$ac_configure_args", "specified configure options")
+AC_DEFINE_UNQUOTED(CONFIGURE_OPTIONS, "$(echo $ac_configure_args | sed -e "s@$(pwd)@<builddir>@g")", "specified configure options")

 # For groonga.org
 AC_ARG_WITH(groonga-org-path,

§

Secondly, I needed to adjust the embedded version of nginx (!) to not
also embed -ffile-prefix-map/CFLAGS as above. Note the use of
$(dirname $(dirname …)) as it is the top-level build directory that
was being embedded, not the current working directory at the time this
code is being run:

--- a/vendor/nginx-1.17.7/auto/configure
+++ b/vendor/nginx-1.17.7/auto/configure
@@ -16,7 +16,7 @@ test -d $NGX_OBJS || mkdir -p $NGX_OBJS
 echo > $NGX_AUTO_HEADERS_H
 echo > $NGX_AUTOCONF_ERR

-echo "#define NGX_CONFIGURE \"$NGX_CONFIGURE\"" > $NGX_AUTO_CONFIG_H
+echo "#define NGX_CONFIGURE \"$(echo $NGX_CONFIGURE | sed -e "s@$(dirname $(dirname $(pwd)))@<builddir>@g")\"" > $NGX_AUTO_CONFIG_H

§

However, this is not complete as the ngx_http_groonga_module.o module
includes an absolute path to its .c source file. I cannot seem to find
how (it's not a -DFOO=BAR style assignment or FILE usage or …)
despite poking for a little while.

Hope this gives you somewhere to start from — good luck. :)

@kou
Copy link
Member

kou commented Jan 26, 2020

Thanks for sharing the information.
But I think that this is not related.

Because we don't use configure nor nginx for Mroonga in MariaDB build.
Groonga package uses configure and nginx but storage/mroonga/vendor/groonga in MariaDB uses CMake and doesn't use nginx: https://github.com/MariaDB/server/blob/10.5/storage/mroonga/vendor/groonga/CMakeLists.txt#L623-L628

So I think that it's unrelated.
(It's related to Groonga package: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/groonga.html )

Could you get #298 (comment) information?

@ottok
Copy link
Author

ottok commented Jan 27, 2020

Could you show the diff of string ha_mroonga.so?

diff -u <(string /.../build1/ha_mroonga.so) <(string /.../build2/ha_mroonga.so)

It may show what string is changed.

I don't see any way to download the built binaries at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mariadb-10.3.html
image

@ottok
Copy link
Author

ottok commented Jan 27, 2020

I guess you could try building Mroonga in once, then change the name of the build directory, and build again, and then compare the resulting binaries to find out with strings where the path has been stored?

@ottok
Copy link
Author

ottok commented Jan 30, 2020

I added this patch to mariadb-10.3 in Debian: https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/a57ed417f7e4be604c3fc2c7affb9ba7d14ee268

Unfortunately it is still unreproducible, and from the diffoscope output I cannot see myself if this patch helped at all or not.

image

Full details at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/mariadb-10.3.html

@kou
Copy link
Member

kou commented Jan 31, 2020

I tried the following on my Debian GNU/Linux sid:

$ mkdir -p /tmp/aaa
$ cd /tmp/aaa
$ apt source -t sid mariadb-server-10.3
$ cd mariadb-10.3-10.3.22
$ sudo apt build-dep mariadb-10.3
$ debuild -us -uc

But the debuild is failed:

In file included from /tmp/aaa/mariadb-10.3-10.3.22/storage/cassandra/cassandra_se.cc:15:
/tmp/aaa/mariadb-10.3-10.3.22/storage/cassandra/gen-cpp/Cassandra.h:77:34: error: field ‘iface_’ has incomplete type ‘boost::shared_ptr<org::apache::cassandra::CassandraIf>’
   77 |   boost::shared_ptr<CassandraIf> iface_;
      |                                  ^~~~~~
In file included from /usr/include/boost/throw_exception.hpp:42,
                 from /usr/include/boost/numeric/conversion/converter_policies.hpp:16,
                 from /usr/include/boost/numeric/conversion/converter.hpp:14,
                 from /usr/include/boost/numeric/conversion/cast.hpp:33,
                 from /usr/include/thrift/transport/TTransportException.h:23,
                 from /usr/include/thrift/transport/TTransport.h:24,
                 from /usr/include/thrift/transport/TSocket.h:25,
                 from /tmp/aaa/mariadb-10.3-10.3.22/storage/cassandra/cassandra_se.cc:10:
/usr/include/boost/exception/exception.hpp:19:44: note: declaration of ‘class boost::shared_ptr<org::apache::cassandra::CassandraIf>’
   19 | namespace boost { template <class T> class shared_ptr; };
      |                                            ^~~~~~~~~~
In file included from /tmp/aaa/mariadb-10.3-10.3.22/storage/cassandra/cassandra_se.cc:15:
...

How did you build MariaDB package? Did you disable Cassandra storage engine? What Debian did you use?

@ottok
Copy link
Author

ottok commented Jan 31, 2020

This is a standard package and all official ways to build Debian packages should work (and do work as proven that the package is in the archives and passes all CI systems etc).

I have not seen the build problem you posted before and I don't know what it is about. Maybe your environment does not have the correct build dependencies? On the other hand debuild should not proceed it dependencies not met.

Here is what I just tested in a clean Debian Sid Docker image as root with apt source -t sid mariadb-server-10.3 && cd mariadb-10.3-10.3.22 && apt build-dep mariadb-10.3 && debuild -us -uc and it built just fine.

I agree that for upstreams this is a bit tricky to investigate, and I have asked the reproducible-builds.org maintainers to provide better docs for upstreams how they can repeat the builds and more easily ensure their software is reproducible (https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20200127/012052.html).

@kou
Copy link
Member

kou commented Feb 3, 2020

OK.
I tried with Docker and found that this is reproducible by installing libthrift-devel. debuild -us -uc tries building Cassandra storage engine with libthrift-devel and fails. How about applying the following change if we don't want to Cassandra storage engine?

diff --git a/debian/rules b/debian/rules
index ba467df5e..5c5f7753e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -103,6 +103,7 @@ endif
 	    -DPLUGIN_AUTH_SOCKET=STATIC \
 			-DWITH_SSL=bundled \
 	    -DPLUGIN_AWS_KEY_MANAGEMENT=NO \
+	    -DPLUGIN_CASSANDRA=NO \
 	    -DWITH_INNODB_SNAPPY=ON \
 	    -DDEB=$(DEB_VENDOR) ..'
 

Anyway, now I can build MariaDB by debuild -us -uc on my environment. I'll look into this.

I agree that for upstreams this is a bit tricky to investigate, and I have asked the reproducible-builds.org maintainers to provide better docs for upstreams how they can repeat the builds and more easily ensure their software is reproducible (https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20200127/012052.html).

Thanks.

@ottok
Copy link
Author

ottok commented Feb 9, 2020

More notes from Chris Lamb: https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20200203/012095.html

Unfortunately none of the changes I made seemed to solve this..
10.3.22 is still unreproducible in unstable due to RocksDB, TokuDB and
Mroonga.

Mmm, alas, I only managed to get this to "almost reproducible" stage
before my attention was required elsewhere.

However, I quickly note that we are still embedding the build flags
that vary depending on the build path via -ffile-prefix-map into the
binary, despite my patch that was designed precisely to normalise them:

│ │ │ │ │ 0x00012040 2d676e75 27202743 464c4147 533d2d67 -gnu' 'CFLAGS=-g
│ │ │ │ │ 0x00012050 202d4f32 202d6666 696c652d 70726566 -O2 -ffile-pref
│ │ │ │ │ - 0x00012060 69782d6d 61703d2f 6275696c 642f3173 ix-map=/build/1s
│ │ │ │ │ - 0x00012070 742f6772 6f6f6e67 612d392e 312e323d t/groonga-9.1.2=
│ │ │ │ │ + 0x00012060 69782d6d 61703d2f 6275696c 642f322f ix-map=/build/2/
│ │ │ │ │ + 0x00012070 67726f6f 6e67612d 392e312e 322f326e groonga-9.1.2/2n

I would suggest that this curiosity is the first place to start. :)

Chris is referencing that the patch https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/a57ed417f7e4be604c3fc2c7affb9ba7d14ee268 was not enough.

@kou
Copy link
Member

kou commented Feb 10, 2020

Thanks for sharing this.

But this is unrelated. Chris Lamb focuses on "groonga" pakcage groonga/groonga#1079 but we focus on "mariadb" package here, right? We can find "prefix-map" in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/groonga.html but can't in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/mariadb-10.3.html .

configure is used by "groonga" package" but not by "mariadb" package.
FYI: #298 (comment)

@ottok
Copy link
Author

ottok commented Oct 6, 2020

This issue still exists and mariadb-10.5 in Debian is not reproducible. Please do not close this issue until we have figured out what it is that pollutes the build.

@ottok
Copy link
Author

ottok commented Dec 9, 2020

Filed this downstream as http://bugs.debian.org/976984 to hopefully attract more eyes on this issue.

You can at any time review the latest status at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/mariadb-10.5.html

@kpcyrd
Copy link

kpcyrd commented Dec 9, 2020

I didn't read the full backlog, but I found an embedded build timestamp in the diffoscope:

··0x004223e0·32303230·2d31312d·32332030·383a3134·2020-11-23·08:14

vs

··0x004223e0·32303230·2d31312d·32342031·303a3134·2020-11-24·10:14

and

rocksdb_build_git_date:@2020-11-23·08:14:57@

vs

rocksdb_build_git_date:@2020-11-24·10:14:57@

you can ignore the build id, it's going to be equal if everything else is equal too.

@kou
Copy link
Member

kou commented Dec 9, 2020

It's MariaRocks related not Mroonga related.
We should fix it in MariaDB.

It's generated by STRING(TIMESTAMP GIT_DATE_TIME "%Y-%m-%d %H:%M:%S") at https://github.com/MariaDB/server/blob/10.6/storage/rocksdb/build_rocksdb.cmake#L485 but it should not use string(TIMESTAMP). It should embed (cd storage/rocksdb/rocksdb && git log -n1 --format=format:%cd --date="format:%Y-%m-%d %H:%M:%S") to GIT_DATE_TIME not using string(TIMESTAMP) when storage/rocksdb/rocksdb submodule is updated.

@ottok
Copy link
Author

ottok commented Dec 9, 2020 via email

@kpcyrd
Copy link

kpcyrd commented Dec 9, 2020

No, I mixed up the tabs after looking through the diffoscope but it seems @kou already figured out the root cause so I'm not sure if I should copy this over to the other rocksdb issue since it seems to be an issue in the MariaDB code.

I couldn't figure out the root cause for mroonga from the diffoscope, the only real difference seems to be 6 extra null bytes in the .dynstr section.

@ottok
Copy link
Author

ottok commented Jul 20, 2021

I got the RocksDB git id thing fixed. Now Mroonga is the only one that remains from MariaDB Server from being fully reproducible: https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/diffoscope-results/mariadb-10.5.html

It would be great if somebody figures out what generates this dynstr thing...
image

@kou
Copy link
Member

kou commented Jul 20, 2021

The not reproducible problem isn't reproducible on my local environment...

@vagrantc
Copy link

vagrantc commented Jul 22, 2021

My guess would be it is related to the build path; while you may be passing -ffile-prefix-map=BUILDPATH=. to the compiler (by way of dpkg-buildflags) which strips out the value of the build path, in some cases the length of the build path (e.g. /build/path/1/2 vs. /build/path/1/2/3) is still embedded in a zeroed out form which would embed a slightly different padded value.

If this is the case, we do not have a good solution or workaround at the moment, other than building with a consistent build path. At tests.reproducible-builds.org the build path does not currently vary when running tests on the "testing" or "stable" suites (currently bullseye and buster, respectively), so once the current version of the package migrates to "testing" it might at least be fixed in that environment.

I've got a few builds running "locally" to try and confirm my suspicions...

@vagrantc
Copy link

A slightly older version only shows the timestamps in rocksdb (which you've fixed in the version in experimental):

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/mariadb-10.5.html

So this confirms my suspicions that it is build path related.

You could also build with DEB_BUILD_OPTIONS=reproducible=-fixfilepath,+fixdebugpath and then it might actually show the embedded build paths (rather than stripping them out and leaving you with mysterious zero-padded offsets), but that might produce more noise too...

@ottok
Copy link
Author

ottok commented Jul 23, 2021

Thanks @vagrantc for responding here to https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20210719/013106.html ! It seems you nailed it, awsome!

@ottok
Copy link
Author

ottok commented Oct 10, 2021

Debugging continued in:

Lamby concludes:

Looking at the just-built (unstripped?) version of ha_mroonga.so, I
can find the following paths embedded in the binary:

$ strings builddir/storage/mroonga/ha_mroonga.so
/home/lamby/temp/cdt.20210723120540.jpheJcnR5m.repro.mariadb-10.5/build-a/mariadb-10.5-10.5.11/storage/mroonga/vendor/groonga/lib:/home/lamby/temp/cdt.20210723120540.jpheJcnR5m.repro.mariadb-10.5/build-a/mariadb-10.5-10.5.11/storage/mroonga/vendor/groonga/vendor/plugins/groonga-normalizer-mysql/normalizers:/home/lamby/temp/cdt.20210723120540.jpheJcnR5m.repro.mariadb-10.5/build-a/mariadb-10.5-10.5.11/libservices:

This looks like something to do with GROONGA_PLUGINS_DIR, so it may be
possible to set this to a fixed path at the configure stage. The
version of ha_mroonga.so that ends up in the binary package does NOT
have these paths in the output of strings(1), although that of course
does not invalidate Vagrant's theory -- they could have been zeroed
out.

That variable is used in

groonga-normalizer-mysql/normalizers/CMakeLists.txt:set(NORMALIZERS_DIR "${GROONGA_PLUGINS_DIR}/normalizers")
groonga-normalizer-mysql/configure.ac:_PKG_CONFIG(GROONGA_PLUGINS_DIR, [variable=pluginsdir],    [groonga])
groonga-normalizer-mysql/configure.ac:GROONGA_PLUGINS_DIR="${pkg_cv_GROONGA_PLUGINS_DIR}"
groonga-normalizer-mysql/configure.ac:AC_SUBST(GROONGA_PLUGINS_DIR)
groonga-normalizer-mysql/configure.ac:normalizers_pluginsdir="\${GROONGA_PLUGINS_DIR}/normalizers"
groonga-normalizer-mysql/CMakeLists.txt:  set(GROONGA_PLUGINS_DIR "${GRN_RELATIVE_PLUGINS_DIR}")

Next step would be to do something about the line groonga-normalizer-mysql/CMakeLists.txt: set(GROONGA_PLUGINS_DIR "${GRN_RELATIVE_PLUGINS_DIR}") so the values of GROONGA_PLUGINS_DIR would always be relative and never change per build, or alternatively find out where this is debugged in the build and stript that part out.

@kou
Copy link
Member

kou commented Oct 12, 2021

Thanks for sharing this.
It seems that they are defined as MRN_LIBRARY_DIRS not GROONGA_PLUGINS_DIR.

How about the following patch?

diff --git a/storage/mroonga/CMakeLists.txt b/storage/mroonga/CMakeLists.txt
index c048b214658..13323ede927 100644
--- a/storage/mroonga/CMakeLists.txt
+++ b/storage/mroonga/CMakeLists.txt
@@ -219,7 +219,7 @@ set(MYSQL_INCLUDE_DIRS
 
 if(MRN_BUNDLED)
   set(MYSQL_PLUGIN_DIR "${INSTALL_PLUGINDIR}")
-  set(MYSQL_SERVICES_LIB_DIR "${MYSQL_BUILD_DIR}/libservices")
+  set(MYSQL_SERVICES_LIB_DIR)
   set(MYSQL_CFLAGS "${CMAKE_C_FLAGS}")
   set(MYSQL_VERSION "${MYSQL_BASE_VERSION}")
 else()
@@ -258,16 +258,24 @@ endif()
 
 if(MRN_GROONGA_BUNDLED)
   set(GROONGA_INCLUDE_DIRS "${MRN_BUNDLED_GROONGA_DIR}/include")
-  set(GROONGA_LIBRARY_DIRS "${MRN_BUNDLED_GROONGA_DIR}/lib")
-  set(GROONGA_LIBRARIES "libgroonga")
+  set(GROONGA_LIBRARY_DIR "${MRN_BUNDLED_GROONGA_DIR}/lib")
+  if(CMAKE_IMPORT_LIBRARY_SUFFIX)
+    set(GROONGA_LIBRARY "${GROONGA_LIBRARY_DIR}/${CMAKE_IMPORT_LIBRARY_PREFIX}groonga${CMAKE_IMPORT_LIBRARY_SUFFIX}")
+  else()
+    set(GROONGA_LIBRARY "${GROONGA_LIBRARY_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}groonga${CMAKE_SHARED_LIBRARY_SUFFIX}")
+  endif()
 
-  set(MRN_LIBRARY_DIRS ${GROONGA_LIBRARY_DIRS})
-  set(MRN_LIBRARIES ${GROONGA_LIBRARIES})
+  set(MRN_LIBRARY_DIRS)
+  set(MRN_LIBRARIES ${GROONGA_LIBRARY})
   if(MRN_GROONGA_NORMALIZER_MYSQL_EMBED)
-    set(MRN_LIBRARY_DIRS
-      ${MRN_LIBRARY_DIRS}
-      "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers")
-    set(MRN_LIBRARIES ${MRN_LIBRARIES} mysql_normalizer)
+    if(CMAKE_IMPORT_LIBRARY_SUFFIX)
+      set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+        "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers/${CMAKE_IMPORT_LIBRARY_PREFIX}mysql_normalizer${CMAKE_IMPORT_LIBRARY_SUFFIX}")
+    else()
+      set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+        "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers/${CMAKE_SHARED_LIBRARY_PREFIX}mysql_normalizer${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    endif()
+    set(MRN_LIBRARIES ${MRN_LIBRARIES} ${GROONGA_NORMALIZER_MYSQL_LIBRARY})
   endif()
 else()
   include(FindPkgConfig)

@ottok
Copy link
Author

ottok commented Feb 2, 2022

Sorry for the long delay in following up on this. I tried the above patch by @kou in https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f5cd9372f691219d9b6409d12cfc6fb9471373d0 but it failed with:

[ 54%] Building CXX object storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_smart_bitmap.cpp.o
cd /builds/mariadb-team/mariadb-server/debian/output/source_dir/builddir/storage/mroonga && /usr/lib/ccache/c++ -DDBUG_TRACE -DHAVE_CONFIG_H -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1 -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/wsrep-lib/include -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/wsrep-lib/wsrep-API/v26 -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/builddir/include -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/builddir/storage/mroonga -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/storage/mroonga -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/storage/mroonga/lib -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/include -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/sql -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/regex -I/builds/mariadb-team/mariadb-server/debian/output/source_dir/storage/mroonga/vendor/groonga/include -g -O2 -ffile-prefix-map=/builds/mariadb-team/mariadb-server/debian/output/source_dir=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC   -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -MD -MT storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_smart_bitmap.cpp.o -MF CMakeFiles/mroonga.dir/lib/mrn_smart_bitmap.cpp.o.d -o CMakeFiles/mroonga.dir/lib/mrn_smart_bitmap.cpp.o -c /builds/mariadb-team/mariadb-server/debian/output/source_dir/storage/mroonga/lib/mrn_smart_bitmap.cpp
make[4]: Leaving directory '/builds/mariadb-team/mariadb-server/debian/output/source_dir/builddir'
[ 54%] Built target aria_embedded
make[4]: *** No rule to make target '../storage/mroonga/vendor/groonga/lib/libgroonga.so', needed by 'storage/mroonga/ha_mroonga.so'.  Stop.

Full log at https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/2424015

@kou
Copy link
Member

kou commented Feb 3, 2022

Ah, sorry. We should use binary dir not source dir:

diff --git a/storage/mroonga/CMakeLists.txt b/storage/mroonga/CMakeLists.txt
index c048b214658..d79e433dd82 100644
--- a/storage/mroonga/CMakeLists.txt
+++ b/storage/mroonga/CMakeLists.txt
@@ -219,7 +219,7 @@ set(MYSQL_INCLUDE_DIRS
 
 if(MRN_BUNDLED)
   set(MYSQL_PLUGIN_DIR "${INSTALL_PLUGINDIR}")
-  set(MYSQL_SERVICES_LIB_DIR "${MYSQL_BUILD_DIR}/libservices")
+  set(MYSQL_SERVICES_LIB_DIR)
   set(MYSQL_CFLAGS "${CMAKE_C_FLAGS}")
   set(MYSQL_VERSION "${MYSQL_BASE_VERSION}")
 else()
@@ -258,16 +258,24 @@ endif()
 
 if(MRN_GROONGA_BUNDLED)
   set(GROONGA_INCLUDE_DIRS "${MRN_BUNDLED_GROONGA_DIR}/include")
-  set(GROONGA_LIBRARY_DIRS "${MRN_BUNDLED_GROONGA_DIR}/lib")
-  set(GROONGA_LIBRARIES "libgroonga")
+  set(GROONGA_LIBRARY_DIR "${MRN_BUNDLED_GROONGA_BINARY_DIR}/lib")
+  if(CMAKE_IMPORT_LIBRARY_SUFFIX)
+    set(GROONGA_LIBRARY "${GROONGA_LIBRARY_DIR}/${CMAKE_IMPORT_LIBRARY_PREFIX}groonga${CMAKE_IMPORT_LIBRARY_SUFFIX}")
+  else()
+    set(GROONGA_LIBRARY "${GROONGA_LIBRARY_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}groonga${CMAKE_SHARED_LIBRARY_SUFFIX}")
+  endif()
 
-  set(MRN_LIBRARY_DIRS ${GROONGA_LIBRARY_DIRS})
-  set(MRN_LIBRARIES ${GROONGA_LIBRARIES})
+  set(MRN_LIBRARY_DIRS)
+  set(MRN_LIBRARIES ${GROONGA_LIBRARY})
   if(MRN_GROONGA_NORMALIZER_MYSQL_EMBED)
-    set(MRN_LIBRARY_DIRS
-      ${MRN_LIBRARY_DIRS}
-      "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers")
-    set(MRN_LIBRARIES ${MRN_LIBRARIES} mysql_normalizer)
+    if(CMAKE_IMPORT_LIBRARY_SUFFIX)
+      set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+        "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR}/normalizers/${CMAKE_IMPORT_LIBRARY_PREFIX}mysql_normalizer${CMAKE_IMPORT_LIBRARY_SUFFIX}")
+    else()
+      set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+        "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR}/normalizers/${CMAKE_SHARED_LIBRARY_PREFIX}mysql_normalizer${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    endif()
+    set(MRN_LIBRARIES ${MRN_LIBRARIES} ${GROONGA_NORMALIZER_MYSQL_LIBRARY})
   endif()
 else()
   include(FindPkgConfig)

@ottok
Copy link
Author

ottok commented Feb 3, 2022

@kou
Copy link
Member

kou commented Feb 3, 2022

Oh, sorry. The patch was incomplete:

diff --git a/storage/mroonga/CMakeLists.txt b/storage/mroonga/CMakeLists.txt
index c048b214658..9f45f5cbca2 100644
--- a/storage/mroonga/CMakeLists.txt
+++ b/storage/mroonga/CMakeLists.txt
@@ -62,6 +62,8 @@ endif()
 set(MRN_BUNDLED_GROONGA_RELATIVE_DIR "vendor/groonga")
 set(MRN_BUNDLED_GROONGA_DIR
   "${CMAKE_CURRENT_SOURCE_DIR}/${MRN_BUNDLED_GROONGA_RELATIVE_DIR}")
+set(MRN_BUNDLED_GROONGA_BINARY_DIR
+  "${CMAKE_CURRENT_BINARY_DIR}/${MRN_BUNDLED_GROONGA_RELATIVE_DIR}")
 if(EXISTS "${MRN_BUNDLED_GROONGA_DIR}")
   set(MRN_GROONGA_BUNDLED TRUE)
   if(MSVC)
@@ -95,8 +97,12 @@ if(MRN_GROONGA_BUNDLED)
     set(GRN_EMBED ON)
   endif()
 
+  set(MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_RELATIVE_DIR
+    "vendor/plugins/groonga-normalizer-mysql")
   set(MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR
-    "${MRN_BUNDLED_GROONGA_DIR}/vendor/plugins/groonga-normalizer-mysql")
+    "${MRN_BUNDLED_GROONGA_DIR}/${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_RELATIVE_DIR}")
+  set(MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR
+    "${MRN_BUNDLED_GROONGA_BINARY_DIR}/${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_RELATIVE_DIR}")
   option(MRN_GROONGA_NORMALIZER_MYSQL_EMBED
     "Embed groonga-normalizer-mysql Groonga plugin"
     ON)
@@ -219,7 +225,7 @@ set(MYSQL_INCLUDE_DIRS
 
 if(MRN_BUNDLED)
   set(MYSQL_PLUGIN_DIR "${INSTALL_PLUGINDIR}")
-  set(MYSQL_SERVICES_LIB_DIR "${MYSQL_BUILD_DIR}/libservices")
+  set(MYSQL_SERVICES_LIB_DIR)
   set(MYSQL_CFLAGS "${CMAKE_C_FLAGS}")
   set(MYSQL_VERSION "${MYSQL_BASE_VERSION}")
 else()
@@ -258,16 +264,24 @@ endif()
 
 if(MRN_GROONGA_BUNDLED)
   set(GROONGA_INCLUDE_DIRS "${MRN_BUNDLED_GROONGA_DIR}/include")
-  set(GROONGA_LIBRARY_DIRS "${MRN_BUNDLED_GROONGA_DIR}/lib")
-  set(GROONGA_LIBRARIES "libgroonga")
+  set(GROONGA_LIBRARY_DIR "${MRN_BUNDLED_GROONGA_BINARY_DIR}/lib")
+  if(CMAKE_IMPORT_LIBRARY_SUFFIX)
+    set(GROONGA_LIBRARY "${GROONGA_LIBRARY_DIR}/${CMAKE_IMPORT_LIBRARY_PREFIX}groonga${CMAKE_IMPORT_LIBRARY_SUFFIX}")
+  else()
+    set(GROONGA_LIBRARY "${GROONGA_LIBRARY_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}groonga${CMAKE_SHARED_LIBRARY_SUFFIX}")
+  endif()
 
-  set(MRN_LIBRARY_DIRS ${GROONGA_LIBRARY_DIRS})
-  set(MRN_LIBRARIES ${GROONGA_LIBRARIES})
+  set(MRN_LIBRARY_DIRS)
+  set(MRN_LIBRARIES ${GROONGA_LIBRARY})
   if(MRN_GROONGA_NORMALIZER_MYSQL_EMBED)
-    set(MRN_LIBRARY_DIRS
-      ${MRN_LIBRARY_DIRS}
-      "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers")
-    set(MRN_LIBRARIES ${MRN_LIBRARIES} mysql_normalizer)
+    if(CMAKE_IMPORT_LIBRARY_SUFFIX)
+      set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+        "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR}/normalizers/${CMAKE_IMPORT_LIBRARY_PREFIX}mysql_normalizer${CMAKE_IMPORT_LIBRARY_SUFFIX}")
+    else()
+      set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+        "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR}/normalizers/${CMAKE_SHARED_LIBRARY_PREFIX}mysql_normalizer${CMAKE_SHARED_LIBRARY_SUFFIX}")
+    endif()
+    set(MRN_LIBRARIES ${MRN_LIBRARIES} ${GROONGA_NORMALIZER_MYSQL_LIBRARY})
   endif()
 else()
   include(FindPkgConfig)

@kou
Copy link
Member

kou commented Feb 4, 2022

Ah, sorry. Bundled Groonga is built as a static library not a shared library:

diff --git a/storage/mroonga/CMakeLists.txt b/storage/mroonga/CMakeLists.txt
index c048b214658..3d704e25671 100644
--- a/storage/mroonga/CMakeLists.txt
+++ b/storage/mroonga/CMakeLists.txt
@@ -62,6 +62,8 @@ endif()
 set(MRN_BUNDLED_GROONGA_RELATIVE_DIR "vendor/groonga")
 set(MRN_BUNDLED_GROONGA_DIR
   "${CMAKE_CURRENT_SOURCE_DIR}/${MRN_BUNDLED_GROONGA_RELATIVE_DIR}")
+set(MRN_BUNDLED_GROONGA_BINARY_DIR
+  "${CMAKE_CURRENT_BINARY_DIR}/${MRN_BUNDLED_GROONGA_RELATIVE_DIR}")
 if(EXISTS "${MRN_BUNDLED_GROONGA_DIR}")
   set(MRN_GROONGA_BUNDLED TRUE)
   if(MSVC)
@@ -95,8 +97,12 @@ if(MRN_GROONGA_BUNDLED)
     set(GRN_EMBED ON)
   endif()
 
+  set(MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_RELATIVE_DIR
+    "vendor/plugins/groonga-normalizer-mysql")
   set(MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR
-    "${MRN_BUNDLED_GROONGA_DIR}/vendor/plugins/groonga-normalizer-mysql")
+    "${MRN_BUNDLED_GROONGA_DIR}/${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_RELATIVE_DIR}")
+  set(MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR
+    "${MRN_BUNDLED_GROONGA_BINARY_DIR}/${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_RELATIVE_DIR}")
   option(MRN_GROONGA_NORMALIZER_MYSQL_EMBED
     "Embed groonga-normalizer-mysql Groonga plugin"
     ON)
@@ -219,7 +225,7 @@ set(MYSQL_INCLUDE_DIRS
 
 if(MRN_BUNDLED)
   set(MYSQL_PLUGIN_DIR "${INSTALL_PLUGINDIR}")
-  set(MYSQL_SERVICES_LIB_DIR "${MYSQL_BUILD_DIR}/libservices")
+  set(MYSQL_SERVICES_LIB_DIR)
   set(MYSQL_CFLAGS "${CMAKE_C_FLAGS}")
   set(MYSQL_VERSION "${MYSQL_BASE_VERSION}")
 else()
@@ -258,16 +264,15 @@ endif()
 
 if(MRN_GROONGA_BUNDLED)
   set(GROONGA_INCLUDE_DIRS "${MRN_BUNDLED_GROONGA_DIR}/include")
-  set(GROONGA_LIBRARY_DIRS "${MRN_BUNDLED_GROONGA_DIR}/lib")
-  set(GROONGA_LIBRARIES "libgroonga")
+  set(GROONGA_LIBRARY
+    "${MRN_BUNDLED_GROONGA_BINARY_DIR}/lib/${CMAKE_STATIC_LIBRARY_PREFIX}groonga${CMAKE_STATIC_LIBRARY_SUFFIX}")
 
-  set(MRN_LIBRARY_DIRS ${GROONGA_LIBRARY_DIRS})
-  set(MRN_LIBRARIES ${GROONGA_LIBRARIES})
+  set(MRN_LIBRARY_DIRS)
+  set(MRN_LIBRARIES ${GROONGA_LIBRARY})
   if(MRN_GROONGA_NORMALIZER_MYSQL_EMBED)
-    set(MRN_LIBRARY_DIRS
-      ${MRN_LIBRARY_DIRS}
-      "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers")
-    set(MRN_LIBRARIES ${MRN_LIBRARIES} mysql_normalizer)
+    set(GROONGA_NORMALIZER_MYSQL_LIBRARY
+      "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_BINARY_DIR}/normalizers/${CMAKE_STATIC_LIBRARY_PREFIX}mysql_normalizer${CMAKE_STATIC_LIBRARY_SUFFIX}")
+    set(MRN_LIBRARIES ${MRN_LIBRARIES} ${GROONGA_NORMALIZER_MYSQL_LIBRARY})
   endif()
 else()
   include(FindPkgConfig)

@ottok
Copy link
Author

ottok commented Feb 4, 2022

Version 4: https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/f304e2d5feded937789f326ce4f1f729acb3a5b6
Success: https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/2432204

Previously the reproducibility test on build_path was failing - see reprotest-build_path in CI run https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/343518

With this patch it is now passing: https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/344538

Some others regressed with errors like

mv: cannot stat '/tmp/reprotest.n7jJBf/const_build_path': No such file or directory

But I think that is unrelated to Mroonga and is an issue in the CI itself on how it terminates long running CI tasks as simply restarting the runs fixed some of those failures.

@kou kou closed this as completed in fc7db7f Feb 5, 2022
@kou
Copy link
Member

kou commented Feb 5, 2022

Great!

I've pushed the patch to master. We'll update Mroonga bundled in MariaDB in a few months.

@kou
Copy link
Member

kou commented Feb 6, 2022

@ottok Sorry, could you also try the simplified version?

diff --git a/storage/mroonga/CMakeLists.txt b/storage/mroonga/CMakeLists.txt
index c048b214658..04dde62576d 100644
--- a/storage/mroonga/CMakeLists.txt
+++ b/storage/mroonga/CMakeLists.txt
@@ -219,7 +219,7 @@ set(MYSQL_INCLUDE_DIRS
 
 if(MRN_BUNDLED)
   set(MYSQL_PLUGIN_DIR "${INSTALL_PLUGINDIR}")
-  set(MYSQL_SERVICES_LIB_DIR "${MYSQL_BUILD_DIR}/libservices")
+  set(MYSQL_SERVICES_LIB_DIR)
   set(MYSQL_CFLAGS "${CMAKE_C_FLAGS}")
   set(MYSQL_VERSION "${MYSQL_BASE_VERSION}")
 else()
@@ -258,15 +258,11 @@ endif()
 
 if(MRN_GROONGA_BUNDLED)
   set(GROONGA_INCLUDE_DIRS "${MRN_BUNDLED_GROONGA_DIR}/include")
-  set(GROONGA_LIBRARY_DIRS "${MRN_BUNDLED_GROONGA_DIR}/lib")
-  set(GROONGA_LIBRARIES "libgroonga")
+  set(GROONGA_LIBRARY "libgroonga")
 
-  set(MRN_LIBRARY_DIRS ${GROONGA_LIBRARY_DIRS})
-  set(MRN_LIBRARIES ${GROONGA_LIBRARIES})
+  set(MRN_LIBRARY_DIRS)
+  set(MRN_LIBRARIES ${GROONGA_LIBRARY})
   if(MRN_GROONGA_NORMALIZER_MYSQL_EMBED)
-    set(MRN_LIBRARY_DIRS
-      ${MRN_LIBRARY_DIRS}
-      "${MRN_BUNDLED_GROONGA_NORMALIZER_MYSQL_DIR}/normalizers")
     set(MRN_LIBRARIES ${MRN_LIBRARIES} mysql_normalizer)
   endif()
 else()

@kou
Copy link
Member

kou commented Feb 7, 2022

Thanks! We'll use simplified version.

kou added a commit that referenced this issue Feb 7, 2022
GitHub: GH-298

We can use target without breaking reproducibility.
@ottok
Copy link
Author

ottok commented Feb 22, 2022

Latest Mariadb 10.6.7 is now in Debian unstable and indeed the build is now fully reproducible: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mariadb-10.6.html

Thanks @kou for the patch!

@kou
Copy link
Member

kou commented Feb 22, 2022

That's good to know. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants