maria-developers team mailing list archive

[worklog-noreply@xxxxxxxxxxxx]

-----------------------------------------------------------------------
                              WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...........: Enable the use of libstdc++ in MariaDB
CREATION DATE..: Wed, 11 Nov 2009, 13:19
SUPERVISOR.....: Monty
IMPLEMENTOR....: Knielsen
COPIES TO......: 
CATEGORY.......: Server-Sprint
TASK ID........: 63 (http://askmonty.org/worklog/?tid=63)
VERSION........: Server-5.2
STATUS.........: Complete
PRIORITY.......: 60
WORKED HOURS...: 4
ESTIMATE.......: 10 (hours remain)
ORIG. ESTIMATE.: 10

PROGRESS NOTES:

-=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=-
Category updated.
--- /tmp/wklog.63.old.19705     2010-03-09 14:34:47.000000000 +0000
+++ /tmp/wklog.63.new.19705     2010-03-09 14:34:47.000000000 +0000
@@ -1 +1 @@
-Server-BackLog
+Server-Sprint

-=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=-
Status updated.
--- /tmp/wklog.63.old.19705     2010-03-09 14:34:47.000000000 +0000
+++ /tmp/wklog.63.new.19705     2010-03-09 14:34:47.000000000 +0000
@@ -1 +1 @@
-Assigned
+Complete

-=-=(Knielsen - Tue, 09 Mar 2010, 14:34)=-=-
High Level Description modified.
--- /tmp/wklog.63.old.19695     2010-03-09 14:34:21.000000000 +0000
+++ /tmp/wklog.63.new.19695     2010-03-09 14:34:21.000000000 +0000
@@ -12,3 +12,11 @@
 except that it might introduce a problem for bintar packages with an external
 dependency on libstdc++.
 
+The conclusion on this worklog is that the solution is just to build with
+CXX=g++. This solves the problem, and after research is considered to have no
+serious bad consequences.
+
+Since this is a future build/packaging issue, there is nothing to be actually
+done in the code for this worklog. Once we merge an actual plugin into the main
+source tree we may need to update the BUILD/* scripts to default to CXX=g++ if
+needed.

-=-=(Knielsen - Sat, 27 Feb 2010, 16:02)=-=-
Status updated.
--- /tmp/wklog.63.old.30948     2010-02-27 16:02:20.000000000 +0000
+++ /tmp/wklog.63.new.30948     2010-02-27 16:02:20.000000000 +0000
@@ -1 +1 @@
-Un-Assigned
+Assigned

-=-=(Knielsen - Thu, 14 Jan 2010, 13:46)=-=-
Research and updated description

Worked 4 hours and estimate 10 hours remain (original estimate increased by 14 hours).

-=-=(Knielsen - Thu, 14 Jan 2010, 13:45)=-=-
High-Level Specification modified.
--- /tmp/wklog.63.old.13967     2010-01-14 11:45:49.000000000 +0000
+++ /tmp/wklog.63.new.13967     2010-01-14 11:45:49.000000000 +0000
@@ -1 +1,37 @@
+I did some investigation into this.
+
+The simple way to do this is to simply use g++ to link C++ objects. So this
+issue is really restricted to GCC compilation where we by default prefer to
+link with gcc even for C++ code. So this means building with
+
+    CXX=g++
+
+The consequences of doing this for the binaries is the addition of two
+additional run-time .so dependencies: libstdc++.so and libgcc_s.so.
+
+It still needs to be investigated if these additional dependencies are a
+problem for binary tarball packages, or if the ABI for those libraries are now
+as stable as libc.so.
+
+The libgcc_s.so is needed as a dependency to support exceptions between
+different object files, as they need to use the same code for stack unwinding.
+libstdc++.so is of course needed for access to C++ runtime.
+
+I researched into the possibility to instead link only specific plugins with
+g++, and continue to link the rest of the server with gcc. Unfortunately, this
+seems really hard to do in a proper way due to the way autotools works. At
+configure time, a script ./libtool is created with hardcoded compiler commands
+derived from $CC and $CXX. This script is then used to do the actual linking
+in Makefiles generated by Automake. I thus did not find a way to change the
+linker command on a per-makefile basis, as libtool is global to the project.
+
+One option would be to use separate configure.in for plugins, but this is
+quite an intrusive change.
+
+My conclusion is that the best way is to start using g++ for linking the
+entire server. This is no problem for binaries made for a specific
+distribution (Ubuntu, Debian, Centos), where the dependencies are handled by
+the package manager. If it is a big problem for binary tarball releases, at
+worst we can build multiple binary tarball releases for the different library
+versions we need to support.
 

-=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=-
Version updated.
--- /tmp/wklog.63.old.19522     2010-01-12 16:26:23.000000000 +0200
+++ /tmp/wklog.63.new.19522     2010-01-12 16:26:23.000000000 +0200
@@ -1 +1 @@
-Connector/.NET-5.2
+Server-5.2

-=-=(Guest - Tue, 12 Jan 2010, 16:26)=-=-
Category updated.
--- /tmp/wklog.63.old.19506     2010-01-12 16:26:15.000000000 +0200
+++ /tmp/wklog.63.new.19506     2010-01-12 16:26:15.000000000 +0200
@@ -1 +1 @@
-Server-RawIdeaBin
+Server-BackLog



DESCRIPTION:

Enable the use of libstdc++ in MariaDB.

As time goes on, more and more plugins and external code/library will need
linking to libstdc++ for stuff it uses. I have already seen this happen several
times, with extra work needed to integrate things properly.

It would be nice to have a general solution for this so that it is not necessary
to spend time on individual solutions in each case.

It also needs to be considered what the impact of this will be for the server in
terms of binary compatibility, performance etc. I think it should be mostly ok,
except that it might introduce a problem for bintar packages with an external
dependency on libstdc++.

The conclusion on this worklog is that the solution is just to build with
CXX=g++. This solves the problem, and after research is considered to have no
serious bad consequences.

Since this is a future build/packaging issue, there is nothing to be actually
done in the code for this worklog. Once we merge an actual plugin into the main
source tree we may need to update the BUILD/* scripts to default to CXX=g++ if
needed.


HIGH-LEVEL SPECIFICATION:



I did some investigation into this.

The simple way to do this is to simply use g++ to link C++ objects. So this
issue is really restricted to GCC compilation where we by default prefer to
link with gcc even for C++ code. So this means building with

    CXX=g++

The consequences of doing this for the binaries is the addition of two
additional run-time .so dependencies: libstdc++.so and libgcc_s.so.

It still needs to be investigated if these additional dependencies are a
problem for binary tarball packages, or if the ABI for those libraries are now
as stable as libc.so.

The libgcc_s.so is needed as a dependency to support exceptions between
different object files, as they need to use the same code for stack unwinding.
libstdc++.so is of course needed for access to C++ runtime.

I researched into the possibility to instead link only specific plugins with
g++, and continue to link the rest of the server with gcc. Unfortunately, this
seems really hard to do in a proper way due to the way autotools works. At
configure time, a script ./libtool is created with hardcoded compiler commands
derived from $CC and $CXX. This script is then used to do the actual linking
in Makefiles generated by Automake. I thus did not find a way to change the
linker command on a per-makefile basis, as libtool is global to the project.

One option would be to use separate configure.in for plugins, but this is
quite an intrusive change.

My conclusion is that the best way is to start using g++ for linking the
entire server. This is no problem for binaries made for a specific
distribution (Ubuntu, Debian, Centos), where the dependencies are handled by
the package manager. If it is a big problem for binary tarball releases, at
worst we can build multiple binary tarball releases for the different library
versions we need to support.


ESTIMATED WORK TIME

ESTIMATED COMPLETION DATE
-----------------------------------------------------------------------
WorkLog (v3.5.9)