MariaDB supports page compression algorithms through plugins:
Adding LZMA would amount to something like:
INSTALL SONAME 'provider_lzma';
Where can I find these plugins (DLLs) for Windows? They are not distributed with the MariaDB binaries for Windows.
As described in the documentation, the compression plugins are available depending on the platform.
This means the plugins are only created if the corresponding compression library is available by default on the respective platform.
In order to create all plugins, all external libraries would have to be statically linked, which would bring some disadvantages (memory consumption, rebuild on library update, package size, ..)
So the only solution would be to install liblzma libraries and headers and rebuild MariaDB Server.
From the MariaDB windows builder log file (10.8 build):
-- The following OPTIONAL packages have not been found:
* Git
* LibXml2
* PMEM
* CURL
* Boost (required version >= 1.40.0)
Required for the OQGraph storage engine
* BZip2
* LZ4 (required version >= 1.6)
* LibLZMA
* LZO
* Snappy
Related
I have a C++ program where I need the current path to later create a folder. The location of my executable is, let's say /home/me/foo/bin. This is what I run:
//Here I expect '/home/me/foo/bin/', but get ''
auto currentPath = boost::filesystem::current_path();
//Here I expect '/home/me/foo/', but get ''
auto parentPath = currentPath.parent_path();
//Here I expect '/home/me/foo/foo2/', but get 'foo2/'
string subFolder = "foo2";
string folderPath = parentPath.string() + "/" + subFolder + "/";
//Here I expect to create '/home/me/foo/foo2/', but get a core dump
boost::filesystem::path boostPath{ folderPath};
boost::filesystem::create_directories( boostPath);
I am running on Ubuntu 16.04, using Boost 1.66 installed with the package manager Conan.
I used to run this successfully with a previous version of Boost (1.45 I believe) without using Conan. Boost was just normally installed on my machine. I now get a core dump when running create_directories( boostPath);.
Two questions:
Why isn't current_path() providing me with the actual path, and returns and empty path instead?
Even if current_path() returned nothing why would I still have a core dump even if I run it with sudo? Wouldn't I simply create the folder(s) at root?
Edit:
Running the compiled program, having some cout outputs of the above variables in between the lines rather than using debug mode, normally gives me the following output:
currentPath: ""
parentPath: ""
folderPath: /foo2/
Segmentation fault (core dumped)
But sometimes (about 20% of the times) gives me the following output:
currentPath: "/"
parentPath: "/home/me/fooA�[oFw�[oFw#"
folderPath: /home/me/fooA�[oFw�[oFw#/foo2/
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
what(): boost::filesystem::create_directories: Invalid argument
Aborted (core dumped)
Edit 2:
Running conan profile show default I get:
[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=5
compiler.libcxx=libstdc++
build_type=Release
[options]
[build_requires]
[env]
There is some discrepance between the libcxx used in the dependencies, and the one that you are using to build your application.
In g++ (linux) there are 2 standard library modes you can use, libstdc++, built without C++11 enabled, and libstdc++11, built with C++11 enabled. When you are building an executable (application or shared library), all the individual libraries linked together must link with the same libcxx.
libstdc++11 was made the default for g++ >= 5, but this also depends on the linux distro. It happens that even if you install a g++ >=5 in older distros like Ubuntu 14, the default libcxx will still be libstdc++, apparently it is not easy to upgrade it without breaking. It also happens that very popular CI services used in open-source, like travis-ci, used older linux distros, and thus libstdc++ linkage was the most popular.
libstdc++ was the default for g++ < 5.
For historical and backwards compatibility reasons, conan default profile always use libstdc++, even for modern compilers in modern distros. You can read your default profile the first time conan is executed, but also find it as a file in .conan/profiles/default, or show it with conan profile show default. This will likely change in conan 2.0 (or even sooner), and the correct libcxx will be detected for each compiler if possible.
So, if you are not changing the default profile (using your own profiles is recommended for production), then when you execute conan install, the depedencies which are installed are built against libstdc++. Note that this conan install is independent on the build in most cases, it just downloads, unzip and configure the dependencies you want, with the requested configuration (from the default profile).
Then, when you are building, if you are not changing _GLIBCXX_USE_CXX11_ABI, then you can be using your system compiler default, in this case, libstdc++11. In most cases, a linking error appears that shows this discrepance. But in your case you were unlucky, and your application managed to link, but then crashed at runtime.
There are a couple of approaches to solve this:
Build your application with libstdc++ too. Make sure to define _GLIBCXX_USE_CXX11_ABI=0.
Install your dependencies for libstdc++11. Edit your default profile to use libstdc++11, then issue a new conan install and rebuild your app.
I'm trying to compile the libxkbcommon library for kodi for my Raspberry Pi 2.
The host machine is a dedicated Server running Ubuntu 16.04 x64.
Now there are two errors when I'm trying to compile libxkbcommon, depending on what yacc I'm using:
byacc:
YACC src/xkbcomp/parser.c
yacc: e - line 219 of
"/opt/kodi/xbmc/tools/depends/target/libxkbcommon/raspberry-pi2-release/src/xkbcomp/parser.y", syntax error
%destructor { FreeStmt((ParseCommon *) $$); }
^
Makefile:1637: recipe for target 'src/xkbcomp/parser.c' failed
btyacc:
parser.y:85: syntax error
Here is the source code of libxkbcommon:
https://github.com/xkbcommon/libxkbcommon
The xbcomp/parser.y file requires a number of (very useful) bison extensions, so it can't be processed by all yacc variants.
btyacc does not support bison-compatible pure-parser declarations. (It has a different, not entirely compatible mechanism which implements the same feature.) So it fails on the first instance of one of those declarations.
It should be possible to use byacc, but not the version which is available in the Ubuntu package repository. Although the Ubuntu package repository change history seems to suggest that the intention was to include the build option which allows %destructor, the actual binary currently available in the byacc repository was built without that option. (It is also several years old, and I think it would be useful to use a more recent version.) I reported this as launchpad bug 1776270, along with a suggestion for a possible fix.
I'm sure you'll be able to build the software using Gnu bison, which is available as the Ubuntu package bison. Since that's the most popular yacc version installed on developer machines, a failure to build with bison would probably have been noticed long ago.
If you would prefer to use byacc, for whatever reason, you'll have to download and build it yourself. You can get the most recent version from Thomas Dickey's byacc page, and then build it with the usual procedure: untar, configure, make, make install. When I tested this, I used the following configure line:
./configure --enable-btyacc --program-prefix=b --prefix=/usr
Only the first option is mandatory
* --program-prefix=b Install it as `byacc` rather than `yacc`
* --enable-btyacc Necessary for %destructor support
* --prefix=/usr Install it in /usr/bin and /usr/man. The default
is /usr/local/bin and /usr/local/man, which failed on
my Ubuntu install because of a missing -D option in the
install command in the Makefile.
When compiling OpenSSL you can add 2 options (from INSTALL in the OpenSSL sources):
Configuration Options
---------------------
There are several options to ./config (or ./Configure) to customize
the build:
--prefix=DIR Install in DIR/bin, DIR/lib, DIR/include/openssl.
Configuration files used by OpenSSL will be in DIR/ssl
or the directory specified by --openssldir.
--openssldir=DIR Directory for OpenSSL files. If no prefix is specified,
the library files and binaries are also installed there.
When compiling other things that rely on OpenSSL or can be added in, an option will be available e.g. for tinc the --with-openssl is available. Should this point to the OpenSSL compilation option given to prefix or openssldir?
Note: I'm not compiling tinc, it's just the first thing I found with a clear example.
You could also run this command to identify in which directory it's installed to.
openssl version -d
which is the openssldir?
By default, the OpenSSL directory is /usr/local/ssl. If you perform a config without --prefix and without --openssldir, that's what you get by default.
Headers will be located in /usr/local/ssl/include/openssl and libraries will be located in /usr/local/ssl/lib.
You should prefer --openssldir, and avoid clever tricks like --prefix=/usr to overwrite a distro's copy of OpenSSL.
If you want to provide a more up to date version of OpenSSL, then look into building a custom package (Personal Package Archive (PPA)) as described at Override Distro Package with Custom Package?.
I'm working on OS X 10.8.5 at the moment. Here's what my /usr/local/ssl looks like (I use one additional directory path on --openssldir due to multiple OpenSSL builds):
$ ls /usr/local/ssl/
android-14 darwin macosx-x64
android-18 ios macosx-x86
the --with-openssl is available. Should this point to the OpenSSL compilation option given to prefix or openssldir?
Yes (but it depends). I've worked with a lot of projects that don't append include and lib properly.
Often times those libraries with --with-openssl are broken in subtle ways. For example, suppose you do the following:
export CFLAGS="-I/usr/local/ssl/include"
export LDFLAGS="/usr/local/ssl/lib"
./config ... --with-openssl=/usr/local/ssl
make
sudo make install
In the above, you will compile and link against the gear in /usr/local/ssl. Then, when you execute your program, it will link against the shared object in /usr/lib, and not the shared object in /usr/local/ssl/lib.
If your distro provides 0.9.8 and you have 1.0.1 in /usr/local/ssl, you will get a lot of unexplained crashes that make no sense. Be vigilant for this issue on OS X because Apple provides 0.9.8.
If you and the distro are both providing something binary compatible (like 1.0.1), then you will be missing functionality without explanation. For example, your version of OpenSSL will have TLS 1.1 and 1.2 enabled, while Ubuntu's version will have TLS 1.1 and 1.2 disabled (Ubuntu priot to 14 built with -DOPENSSL_NO_TLS1_2_CLIENT). And you'll wonder why you cannot connect using TLS 1.2.
If you are compiling on OS X, then you will find OS X silently discards your request to perform static linking (i.e., -Bstatic -lcrypto -lssl). The linker will always use the shared object if available (even on iOS, where its not allowed!). And it will silently ignore your -rpath, too. And forget LD_LIBRARY_PATH because its not honored (you have to use DYLD_LIBRARY_PATH per dyld(1)).
The easiest way to cope with OS X is to:
cd <project>
grep -R "-lcrypto" *
<replace all occurences of -lcrypto with /usr/local/ssl/lib/libcrypto.a>
grep -R "-lssl" *
<replace all occurences of -lssl with /usr/local/ssl/lib/libssl.a>
Archives are just like object files (they are a collection of object files), so you don't even need the -l.
When forcing static linking as above, you don't have to worry about the linker silently discarding your requests or doing things you don't expect. The same works on Linux, too. As a matter of fact, I always use my own version of OpenSSL, and I always do what I described because I got tired of fighting with the various tools (its not only ld, its Eclipse and friends, too).
When compiling other things that rely on OpenSSL, what they usually need is, in order to compile correctly, the openssl binaries - crypto and ssl (linux) - (for linkage) and the include files.
So, your best try would be to point the --prefix you used to install the openssl
https://wiki.openssl.org/index.php/Compilation_and_Installation#PREFIX_and_OPENSSLDIR
PREFIX and OPENSSLDIR
--prefix and --openssldir control the configuration of installed components. The behavior and interactions of --prefix and --openssldir are slightly different between OpenSSL 1.0.2 and below, and OpenSSL 1.1.0 and above.
The rule of thumb to use when you want something that "just works" for all recent versions of OpenSSL, including OpenSSL 1.0.2 and 1.1.0, is:
specify both --prefix and --openssldir
set --prefix and --openssldir to the same location
One word of caution is avoid --prefix=/usr when OpenSSL versions are not binary compatible. You will replace the distro's version of OpenSSL with your version of OpenSSL. It will most likely break everything, including the package management system.
I am trying to run an app but I get
...
/usr/lib64/libstdc++.so.6: VERSION 'GLIBCXX_3.4.15' not found
/lib64/libc.so.6: VERSION 'GLIBC_2.15' not found
/lib64/libc.so.6: VERSION 'GLIBC_2.14' not found
...
When I do "strings /usr/lib64/libstdc++.so.6 | grep GLIBC" i get a normal list...
...
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
...
GLIBCXX_3.4.13
GLIBCXX_2.2.5
GLIBCXX_2.3.2
...
I don't seem to find a simple tutorial on how to install the missing libs/files/dependencies, (or Centos 6.5 or anything else for that mater).
Can someone explain how to install whatever might be missing on Centos?
Can someone explain how to install whatever might be missing on Centos?
You need glibc >= 2.15 and libstdc++ >= 3.4.15.
In theory, installing e.g. glibc-2.19 on the system should work (glibc provides backward binary compatibility), but this message suggests that you would not find a standard package for your OS with such an upgrade.
Instead you would have to either install a second version of glibc, as documented here, and redirect your application to use that version by binary-patching the loader encoded into the application, or run your application in a chroot (where you can install any version of glibc you like).
Similar considerations apply to libstdc++.so.6 as well, except you don't have to install it into the fixed location -- you can install newer copy anywhere, and point LD_LIBRARY_PATH to it.
Your final (and most likely easiest) alternative is to build the app you are trying to run from source, or obtain a pre-built binary for your distribution (one that doesn't require newer libraries than what you have).
I'm fairly new to linux so when yum install doesn't work, I'm lost. I found some files online for plzip but I don't know how to install the program from those files.
To install plzip you will most likely have to download the source code in tarball, uncompress and compile it. (usually: ./configure; make; make install) but as RHEL is RPM based your life will be much easier (for now) if you stick to what's available in RPM or in fact what was shipped with your distribution.
If I'm not mistaken you want to use multiple threads to compress you data. If you are on RHEL 5 or 6 you should have xz available to you:
yum install xz
From Wikipedia:
XZ Utils (previously LZMA Utils) is a set of free command-line
lossless data compressors, including LZMA and xz, for Unix-like
operating systems and, from version 5.0 onwards, Microsoft Windows.
From man xz
DESCRIPTION
xz is a general-purpose data compression tool with command line syntax similar to gzip(1) and bzip2(1). The native file format
is the .xz format, but also the legacy .lzma format and raw
compressed streams with no container format headers are supported.
In other words this is an implementation of Lempel-Zif-Markov algorithm and by far most popular tool to use it is 7zip. To read more about it you can visit great Wikipedia article: http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Markov_chain_algorithm
The other option would be to use pbzip - which is also available in rpm: http://compression.ca/pbzip2/ and by it looks of things it might make it to RHEL one day...