|
a roll back to
tag:mariadb-10.0.8, r3994
|
cures the problem; build completes without error/fail.
regression bracketed bet revno 3994 & revno 4040
|
|
note
http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/4015#libmysql/libmysql_versions.ld.in
|
testing
build revno 4014 -> OK
|
build revno 4015 -> FAIL, as above
|
fyi
ld -v
|
GNU gold (GNU Binutils; devel:gcc / openSUSE_12.3 2.24.0.20131209-185) 1.11
|
|
|
Could you please provide the complete cmake line?
It works for me on 13.1 (which is great news, at least there is a way to build it).
By default it picks up cc/c++, but even when I forced gcc/g++, it still got built. Compiler command lines are different though, so I suppose when you say
cmake .. \
|
...
|
make VERBOSE=1
|
there is something hiding under the dots?
|
|
Yes, of course. NO options would be too easy, no?
This is my usual cmake
cmake .. \
|
--debug-output \
|
-G "Unix Makefiles" \
|
-DENABLE_DEBUG_SYNC=0 \
|
-DBUILD_SHARED_LIBS=1 \
|
-DCMAKE_INSTALL_PREFIX=/usr/local/mariadb \
|
-DCMAKE_C_FLAGS="-O2 -D_FORTIFY_SOURCE=2 -fmessage-length=0 -fstack-protector -march=amdfam10 -mtune=amdfam10 -fno-omit-frame-pointer" \
|
-DCMAKE_CXX_FLAGS="-O2 -D_FORTIFY_SOURCE=2 -fmessage-length=0 -fstack-protector -march=amdfam10 -mtune=amdfam10 -felide-constructors -fno-exceptions -fno-rtti" \
|
-DWITH_MYSQLD_LDFLAGS="-L/usr/local/ssl/lib64 -Wl,-rpath,/usr/local/ssl/lib64 -lssl -lcrypto" \
|
-DCMAKE_SKIP_BUILD_RPATH=0 \
|
-DCMAKE_BUILD_WITH_INSTALL_RPATH=0 \
|
-DCMAKE_INSTALL_RPATH="" \
|
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=1 \
|
-DINSTALL_LAYOUT=STANDALONE \
|
-DINSTALL_LIBDIR=lib64 \
|
-DINSTALL_MANDIR=/usr/local/mariadb/man \
|
-DINSTALL_MYSQLDATADIR=/usr/local/mariadb/data -DMYSQL_DATADIR:PATH=/usr/local/mariadb/data \
|
-DINSTALL_UNIX_ADDRDIR=/var/cache/mariadb/mariadb.sock \
|
-DINSTALL_SYSCONFDIR=/usr/local/etc/mariadb.DEFAULT \
|
-DINSTALL_SYSCONF2DIR=/usr/local/etc/mariadb.DEFAULT/conf.d \
|
-DDEFAULT_SYSCONFDIR=/usr/local/etc/mariadb \
|
-DCONNECT_WITH_MYSQL=1 \
|
-DWITH_EMBEDDED_SERVER=0 \
|
-DWITH_ARCHIVE_STORAGE_ENGINE=0 \
|
-DWITH_ARIA_STORAGE_ENGINE=1 \
|
-DWITH_BLACKHOLE_STORAGE_ENGINE=0 \
|
-DWITH_CONNECT_STORAGE_ENGINE=0 \
|
-DWITH_FEDERATEDX_STORAGE_ENGINE=0 \
|
-DWITH_PARTITION_STORAGE_ENGINE=1 \
|
-DWITH_PERFSCHEMA_STORAGE_ENGINE=1 \
|
-DWITH_SEQUENCE_STORAGE_ENGINE=0 \
|
-DWITH_SPHINX_STORAGE_ENGINE=0 \
|
-DWITH_TEST_SQL_DISCOVERY_STORAGE_ENGINE=0 \
|
-DWITH_XTRADB_STORAGE_ENGINE=1 -DWITH_XTRADB=1 \
|
-DWITHOUT_INNOBASE=1 \
|
-DWITHOUT_TOKUDB_STORAGE_ENGINE=1 -DWITHOUT_TOKUDB=1 \
|
-DWITH_READLINE=1 \
|
-DWITH_ZLIB=system \
|
-DWITH_UNIT_TESTS=0 \
|
-DWITH_VALGRIND=0 \
|
-DWITH_SSL=/usr/local/ssl \
|
-DOPENSSL_ROOT_DIR=/usr/local/ssl \
|
-DOPENSSL_INCLUDE_DIR=/usr/local/ssl/include \
|
-DOPENSSL_LIBRARIES=/usr/local/ssl/lib64/libssl.so \
|
-DCRYPTO_LIBRARY=/usr/local/ssl/lib64/libcrypto.so \
|
-DDEFAULT_CHARSET=latin1 -DDEFAULT_COLLATION=latin1_swedish_ci \
|
-DWITH_EXTRA_CHARSETS=all \
|
-DWITH_FAST_MUTEXES=1 \
|
-DWITH_ATOMIC_LOCKS="smp"
|
not a surprise; it's insensitive to
-march=amdfam10 -mtune=amdfam10
|
removing, or changing for other builds – same issue.
|
|
elenst gcc version isn't relevant here, I guess. ld version is. We use ld everywhere, not gold. I don't think we've ever tested linking with gold yet.
|
|
serg, yes, we already discussed ld vs gold, and i tried both (or rather, all four – 2.23.1 ld/gold and 2.24.0 ld/gold), still haven't got the failure.
pgnd mentioned that the build machine is not a standard openSUSE installation, but a dev stack or something. I will need to know how exactly it was created and what was installed, and to try the same in order to pinpoint the important difference.
|
|
nothing terribly untoward. by 'dev stack', i colloqiually refer to dev tools pulled from opensuse's mostly-official repos that are often significantly more up to date than the release channels; although, that of course varies over time.
i've a bunch of machines that all exhibit this same, reported failure.
here's the package env from one,
zypper ls -dup
|
# | Alias | Name | Enabled | Refresh | Priority | Type | URI
|
---+----------------------+------------------------------+---------+---------+----------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------
|
1 | Archiving | Archiving | Yes | Yes | 99 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/Archiving/openSUSE_12.3
|
2 | Editors | Editors | Yes | Yes | 99 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/editors/openSUSE_12.3
|
3 | GCC | GCC | Yes | Yes | 40 | rpm-md | http://ftp5.gwdg.de/pub/opensuse/repositories/devel:/gcc/openSUSE_12.3
|
4 | Hardware | Hardware | Yes | Yes | 99 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/hardware/openSUSE_12.3
|
5 | JavaOpenJDK | JavaOpenJDK | Yes | Yes | 60 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/Java:/openjdk6:/Factory/openSUSE_12.3/
|
6 | MySQL | MySQL | Yes | Yes | 65 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/server:/database/openSUSE_12.3
|
7 | Netfilter | Netfilter | Yes | Yes | 40 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/security:/netfilter/openSUSE_12.3
|
8 | Network-Samba | Network-Samba | Yes | Yes | 45 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/network:/samba:/STABLE/openSUSE_12.3
|
9 | Network-vpn | Network-vpn | Yes | Yes | 99 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/network:/vpn/openSUSE_12.3/
|
10 | NetworkUtilities | NetworkUtilities | Yes | Yes | 89 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/network:/utilities/openSUSE_12.3
|
11 | OS12-non-oss | OS12-non-oss | Yes | Yes | 99 | yast2 | http://download.opensuse.org/distribution/12.3/repo/non-oss/
|
12 | OS12-oss | OS12-oss | Yes | Yes | 99 | yast2 | http://download.opensuse.org/distribution/12.3/repo/oss/
|
13 | OS12-security | OS12-security | Yes | Yes | 90 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/security/openSUSE_12.3
|
14 | OS12-src-non-oss | OS12-src-non-oss | Yes | Yes | 99 | yast2 | http://download.opensuse.org/source/distribution/12.3/repo/non-oss/
|
15 | OS12-src-oss | OS12-src-oss | Yes | Yes | 99 | yast2 | http://download.opensuse.org/source/distribution/12.3/repo/oss/
|
16 | OS12-update | OS12-update | Yes | Yes | 90 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/update/12.3
|
17 | Perl | Perl | Yes | Yes | 60 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/devel:/languages:/perl/openSUSE_12.3
|
18 | Python | Python | Yes | Yes | 60 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/devel:/languages:/python/openSUSE_12.3
|
19 | SCM | SCM | Yes | Yes | 99 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/devel:/tools:/scm/openSUSE_12.3
|
20 | SCM-svn | SCM-svn | Yes | Yes | 40 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/devel:/tools:/scm:/svn/openSUSE_12.3
|
21 | SystemsMgmt | SystemsMgmt | Yes | Yes | 100 | rpm-md | http://ftp.halifax.rwth-aachen.de/opensuse/repositories/systemsmanagement/openSUSE_12.3
|
22 | Tools | Tools | Yes | Yes | 89 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/devel:/tools/openSUSE_12.3
|
23 | ToolsBuilding | ToolsBuilding | Yes | Yes | 99 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/devel:/tools:/building/openSUSE_12.3
|
24 | ToolsCompiler | ToolsCompiler | Yes | Yes | 99 | rpm-md | http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/devel:/tools:/compiler/openSUSE_12.3
|
25 | packman | packman | Yes | Yes | 14 | rpm-md | http://packman.inode.at/suse/openSUSE_12.3
|
|
I've built from src
openssl version --> prefix: /usr/local/ssl
|
OpenSSL 1.0.1f 6 Jan 2014
|
|
ssh -V --> prefix: /usr/local
|
OpenSSH_6.5p1, OpenSSL 1.0.1f 6 Jan 2014
|
and there's
cat /etc/ld.so.conf
|
/usr/local/lib64
|
/usr/local/lib
|
include /etc/ld.so.conf.d/*.conf
|
noteworthy versions are
gcc -v
|
Using built-in specs.
|
COLLECT_GCC=gcc
|
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
|
Target: x86_64-suse-linux
|
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
|
Thread model: posix
|
gcc version 4.8.2 20131210 [gcc-4_8-branch revision 205857] (SUSE Linux)
|
|
rpm -q --whatprovides `which gcc`
|
gcc-4.7-7.1.1.x86_64
|
|
ld -v
|
GNU gold (GNU Binutils; devel:gcc / openSUSE_12.3 2.24.0.20131209-185) 1.11
|
rpm -q --whatprovides `which ld`
|
binutils-2.24-185.1.x86_64
|
there's more, but I think this is mostly what's relevant.
and, again recall – builds of MariaDB 10 r <= 4014 are without error, and 'in production' are pretty much rock solid for me. r>= 4015, all fail similarly
|
|
Not sure if I accidentally deleted the affects/version tag for 10.0.9; correcting.
Given
mariadb-10.0.8 3994
|
mariadb-10.0.9 4040
|
and that this appears at revno 4015, it effects >= 10.0.9
|
|
just fyi, I've migrated the last of my opensuse v12.3 boxes -> v13.1.
the problem here remains, as reported above – just no more 12.3 boxes to test/verify on, only 13.1
|
|
This is gold specific error message (it's only present in the gold sources, not in ld sources). Unfortunately, I wasn't able to find any documentation about gold besides "supports most of the features of the GNU linker", so it's unclear why exactly it doesn't like a perfectly valid linker script. It seems that it only expects a VERSION section in a version script (--version-script command line option) or a linker script specified in --script (main linker script) option.
But GNU ld manual clearly says
3.9 VERSION Command
|
===================
|
...
|
You can include a version script directly in the main linker script,
|
or you can supply the version script as an implicit linker script. You
|
can also use the `--version-script' linker option.
|
and
3.11 Implicit Linker Scripts
|
============================
|
If you specify a linker input file which the linker can not recognize as
|
an object file or an archive file, it will try to read the file as a
|
linker script.
|
...
|
Typically an implicit linker script would contain only symbol
|
assignments, or the `INPUT', `GROUP', or `VERSION' commands.
|
We put VERSION in the implicit version script — and gold doesn't seem to support it.
It's either a bug (if unintentional) or an undocumented incompatibility of gold.
|
|
I couldn't find an easy way of fixing the build for gold. We could have a workaround — the build that works, but doesn't provide exactly the same symbol versioning as with GNU ld. I'm not sure whether it's a good idea, though.
|
|
From the bugreport for gold:
For gold, using -T works because there is no default linker
script to replace. But coming up with something that works with both
linkers is clearly desirable. I think you could separate your script
into all the stuff before "VERSION { ... }", and leave that in an
implicit linker script, then put everything from the VERSION block
into a separate file and add that with --version-script.
So, we can either use -T for gold (but not for ld) or split the script.
|
|
Neither workaround helped. While gold stop issuing errors and started linking, it didn't produce the same results as *ld did. In particular, all symbol aliases in the libmysqlclient_16 version node were missing.
|
|
Apparently there's nothing we can do to have correctly versioned libraries with gold. It's up to gold developers to fix ld compatibility.
|
|
In communicating with the ld.gold devs, upon their review of THIS bug, the following was shared:
"The initial analysis is basically correct: gold doesn't accept VERSION
in an implicit linker script. However, the fix for that is
straightforward, and it looks like they applied it.
The last two comments then say that something else went wrong, but
there are no details, so I have no idea what they did or what the
problem was.
In general please file gold bug reports at
http://sourceware.org/bugzilla and discuss gold issues on the mailing
list binutils@sourceware.org."
Since MariaDB dev (hopefully) has the details of what's been done, and what's still not working, it'd be generally helpful if you communicated the issue – which clearly affects MariaDB build – to ld upstream, avoiding any 'fogging' by the uninformed (aka, me).
Thanks.
|
|
Thanks. First, don't worry, comments to closed bugs are still forwarded.
Second. My last comment on the gold bug tracker (https://sourceware.org/bugzilla/show_bug.cgi?id=16895#c7) from 2014-05-31 explains the problem exactly. The linking worked but versioning of symbols was incorrect, there were no symbols in the libmysqlclient_16 version node.
My comment in this MDEV-5982 says the same. I don't know what other details are required. Considering that there were no comments on https://sourceware.org/bugzilla/show_bug.cgi?id=16895 after mine, I believed that no more information is needed.
|
|
we'll do the following:
if cmake detects gold it aborts with the error message like "gold linker doesn't support our symbol versioning scheme (https://sourceware.org/bugzilla/show_bug.cgi?id=16895), use ld or run cmake with -DDISABLE_LIBMYSQLCLIENT_SYMBOL_VERSIONING=1"
|
|
> we'll do the following:
> if cmake detects gold it aborts with the error message like "gold linker
> doesn't support our symbol versioning scheme (https://sourceware.org/bugzilla/
> show_bug.cgi?id=16895), use ld or run cmake with -
> DDISABLE_LIBMYSQLCLIENT_SYMBOL_VERSIONING=1"
checking back on the error handling on this
bldg from latest 10.1 sources,
switching
- -DCMAKE_LINKER=/usr/bin/ld.bfd \
|
+ -DCMAKE_LINKER=/usr/bin/ld.gold \
|
allows config to pass with NO errors, but subsequent make still fires error at
...
|
[ 76%] Built target clientlib
|
[ 76%] Linking CXX shared library libmysqlclient.so
|
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: error: /usr/local/src/mariadb/bld/libmysql/libmysql_versions.ld:155:9: invalid use of VERSION in input file
|
collect2: error: ld returned 1 exit status
|
libmysql/CMakeFiles/libmysql.dir/build.make:110: recipe for target 'libmysql/libmysqlclient.so.18.0.0' failed
|
make[2]: *** [libmysql/libmysqlclient.so.18.0.0] Error 1
|
CMakeFiles/Makefile2:4149: recipe for target 'libmysql/CMakeFiles/libmysql.dir/all' failed
|
make[1]: *** [libmysql/CMakeFiles/libmysql.dir/all] Error 2
|
Makefile:138: recipe for target 'all' failed
|
make: *** [all] Error 2
|
it looks like it's still not detected/messaged correctly in 10.1
|
|
I've implemented configure-time gold detection and the DISABLE_LIBMYSQLCLIENT_SYMBOL_VERSIONING option.
|