MariaDB Build Script for 11.x

[CentralWare]

@andyj: As requested, the current (though not entirely complete) build script for MariaDB 11.x

This script contains, technically, the builds for about half a dozen packages that will become requirements as the script grows (boost, snappy, judy, etc.)
Something went wrong when attempting to compile the more recent Google fork of Snappy; feel free to update if you find a work-around.

Warning: Maria is huge (source download alone is ~100MB zipped) and though threading is enabled, still takes quite a while to complete.

maria.tcz.dep and .dep.multiple are created -- multiple is a list of files which are provided in two or more extensions (such as OpenSSL since there's numerous SSL releases in the repository.) Manual intervention will be required there.

Once the package is properly tested (and on different platforms) it would then be feasible to split the package into _client, _server, _doc, _dev, etc. with their own dependency and info files.

[CentralWare]

mysqld and mysql client tested successfully.

basedir=/usr/local/mysql
datadir=/opt/mysql/data

TO-DO:

• Create links to /usr/local/bin from /usr/local/mysql/bin OR add /usr/local/mysql/bin to PATH
• Update /usr/local/etc/init.d/mysql to check if /opt/mysql/data has been initialized; IF NOT do so on mysql start which is the general method used in mainstream distros
• Find a fix/patch for g00gle's Snappy just to keep up with the Jones' IF it's compliant with Maria's modules (v1.1.2 is a bit older...  almost a decade older... but still works with mySQL)
• Separate compilation into individual packages [src] [doc] [test] [local] [client] [server] ::: Will need help testing with locale :::
  

After all of that is finished, return to INSTALL/large and complete the builds for the remaining 3-4 dependencies in order to implement Boost, Snappy, etc. which should give us the most "rounded" SQL server options.

NOTE: Java support has been disabled (as has virtually world-wide discontinuation it seems) due to "licensing issues" thus a handful of modules are being skipped as they rely on JAVA, including the JAVA based connector.
EDIT: Corrected above paths for "links"

[Rich]

Hi CentralWare
Firefox and Thunderbird store their directories in /usr/local/.
They then link the main executable to /usr/local/bin/ in their
/usr/local/tce.installed script:

Code: [Select]

ln -s /usr/local/firefox/firefox /usr/local/bin/firefoxand:

Code: [Select]

[ -e /usr/local/bin/thunderbird ] || sudo ln -s /usr/local/thunderbird/thunderbird /usr/local/bin/thunderbird

[CentralWare]

@Rich: Good morning, Sir!

They then link the main executable to /usr/local/bin/ in their /usr/local/tce.installed script

The only difference here is MySQL/Maria has a few dozen binaries that would have to be linked (not that we couldn't loop the list into tce.installed/mysql) so I was weighing linking versus PATH addendum, but yes, if we linked anything it would likely have to be done in tce.installed/mysql as the only other option would be etc/init.d/mysql which really isn't the "right" place to do so unless necessary. I never looked into it, but I'm assuming tce.installed/extension gets called by tce(load)

The maintenance scripts (like mariadb-install-db) can stay right as they are; it's inconvenient typing in the entire file path, but they're launched infrequently. Hmmm... in fact, these scripts may also be able to be linked into /usr/local/bin as their internal calls use associated paths like ../bin/mysql_something -- which should still work.  (They currently reside in /usr/local/mysql/scripts/filename)

[CentralWare]

NOTE: Post 2 above is being treated like a to-do checklist; additional posts will be recorded separately when the to-do reaches a milestone.

[Rich]

Hi CentralWare

The only difference here is MySQL/Maria has a few dozen binaries that would have to be linked ...

The  firefox  executable is only about 13K in size. It looks at  /proc/self/exe:

Code: [Select]

tc@E310:~$ grep "/proc/self/exe" /tmp/tcloop/firefox/usr/local/firefox/firefox
Binary file /tmp/tcloop/firefox/usr/local/firefox/firefox matcheswhich points back to an executables location:

Code: [Select]

tc@E310:~$ readlink  /proc/self/exe
/tmp/tcloop/coreutils/usr/local/bin/readlink
tc@E310:~$ ls -l /proc/self/exe
lrwxrwxrwx 1 tc staff 0 Feb 19 08:07 /proc/self/exe -> /tmp/tcloop/coreutils/usr/local/bin/lsFirefox uses that to determine where firefox-bin, helper programs, and
libraries are located.
Thunderbird does the same thing.

... I never looked into it, but I'm assuming tce.installed/extension gets called by tce(load) ...

That is correct.

[andyj]

One thing I would do is to fix this:

Code: [Select]

    cd $SRC/builder
    sed -i '102a#include <ncursesw/curses.h>\n#include <ncursesw/term.h>\n#include <ncursesw/termcap.h>\n' ../client/mysql.cc

I did it this way as a quick/dirty/lazy way to get it to compile, but you can see the line number is hard coded. A better solution would be to use a patch:

Code: [Select]

    patch builder/client/mysql.cc <<'EOF'
--- client/mysql.cc-orig
+++ client/mysql.cc
@@ -100,6 +100,9 @@
 #define HAVE_READLINE
 #endif
 #define USE_POPEN
+#include <ncursesw/curses.h>
+#include <ncursesw/term.h>
+#include <ncursesw/termcap.h>
 }
 
 static CHARSET_INFO *charset_info= &my_charset_latin1;
EOF

I haven't actually tested this snippet so double check my grammar. I do agree with your comment, it's a bug the devs can't see because whatever distro they're using hides this problem.

[CentralWare]

@andyj: Yes, a <diff> patch would be better in the long run (which is how I handled a few fixes to configuration files, etc.)
I ran into the curses curse myself thus copying your initial fix worked out well (copying ncursesw-dev into maria/src was a last ditch effort I did as well when at 97% or so 'make tosses out "I can't find curses.h!  I know you told me where to look, but I forgot!!  I'm not AI you know?!"

I'll test your patch tomorrow when time permits just on mysql.cc itself -- not on a compile; I'm holding off until the next milestone before we run another compilation.
Didn't mysql.cc already have #include curses.h and was just missing the other two?  (I don't have a clean mysql.cc to look at @ the moment and my memory is already looking forward to "...a long winter's nap" so forgive me if I'm mistaken! )

@Rich: I'll experiment accordingly and see how things turn out.  If mysql-client and server are both installed, an end user would call mysql somewhere at the prompt to open the CLI utility, which is where a link to /usr/local/bin would need to be accommodated so that even `which mysql` knew what's what.  etc/init.d/mysql can contain full paths (preferred anyhow) so we're good there...  I'm uncertain of apps like mysql-install-db and other similar apps and scripts that aren't in the mysql/bin directory, but will have to see first hand to really rest assured.

Good evening, gentlemen, and thanks for your feedback!

[CentralWare]

@andyj: Okay, I lied...  turns out I did have a clean client directory.

Code: [Select]

--- mysql.cc
+++ mysql2.cc
@@ -100,6 +100,9 @@
 #define HAVE_READLINE
 #endif
 #define USE_POPEN
+#include <ncursesw/curses.h>
+#include <ncursesw/term.h>
+#include <ncursesw/termcap.h>
 }
 static CHARSET_INFO *charset_info= &my_charset_latin1;
Typed in the necessary includes...  ran diff... created mysql.cc.diff - tested in reverse (patch -i) and worked just fine.  Ran a second time; complained and quit as expected.
Looked up a few lines --- now know what I recalled about curses already being there.

Take care!