I need to compile fulltext parser plugin in windows, but I am not able to dot it even with original MySQL source example. MySQL Server version is 5.6 x64. With gcc I tried variations of:
gcc -shared -Wall -g -o "plugin_example.dll" -fPIC "plugin_example.c" -DMYSQL_DYNAMIC_PLUGIN -lmysqlservices
but when I try to install it
INSTALL PLUGIN simple_parser SONAME 'plugin_example.dll'
I get following error
Can't open shared library '... plugin_example.dll' (errno: 193 )
With Dev-C and its (stripped -L libs)
gcc.exe -c projekt3.c -o projekt3.o -DMYSQL_DYNAMIC_PLUGIN -DBUILDING_DLL=1
dllwrap.exe --output-def libProjekt3.def --implib libProjekt3.a projekt3.o -static-libgcc -lmysqlservices --no-export-all-symbols --add-stdcall-alias -o Projekt3.dll
I get 250K DLL and
Can't find symbol '_mysql_plugin_interface_version_' in library
Five days of googling a trial-erroring leads me nowhere. Any help would be appreciated.
errno 193 means wrong file format.
Probably there is an inconsistency between your 64 bit MySQL and the .dll. Most of the the pages from Google are talking about incompatible 32-bit and 64-bit Java versions.
So I recommend either trying with a 32-bit MySQL, compiling the plugin for 64-bit or checking if the install routine has some assumptions about 64 or 32 bits ?
I found a small sample here: http://www.clusterdb.com/mysql/creating-a-mysql-plugin-to-produce-an-interger-timestamp
Basically it is for a nix system, but you could do the same on Windows.
gcc -Idrive:\path\to\mysql\include\ -fPIC -shared -o plugin_example.dll plugin_example.c
Then copy it to the plugin lib
drive:\path\to\mysql\lib\plugin\
then you create the function like so:
create function inttime RETURNS REAL SONAME 'plugin_example.dll';
You can find the whole shebang here: http://dev.mysql.com/doc/refman/5.6/en/udf-compiling.html
Related
I am trying to compile the linux kernel for riscv64 using the following link -
https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html
While building linux with the command make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- defconfig
the following error shows up -
scripts/kconfig.include:35 compiler riscv64-unknown-linux-gnu-gcc not found in PATH
scripts/kconfig/Makefile:82:recipe for target 'defconfig' failed
I have included path of tool chain. Still not working. Attached the screenshot of folder structure and error.
I would suggest to provide the full prefix for your toolchain in the make command, for example:
wget https://toolchains.bootlin.com/downloads/releases/toolchains/riscv64/tarballs/riscv64--glibc--bleeding-edge-2020.02-2.tar.bz2
mkdir -p /opt/bootlin
tar jxf riscv64--glibc--bleeding-edge-2020.02-2.tar.bz2 -C /opt/bootlin
make ARCH=riscv CROSS_COMPILE=/opt/bootlin/riscv64--glibc--bleeding-edge-2020.02-2/bin/riscv64-buildroot-linux-gnu- mrproper defconfig Image
Compilation should complete without errors - using linux 5.7.11 here:
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
.../...
LD vmlinux.o
MODPOST vmlinux.o
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.kallsyms1
KSYM .tmp_vmlinux.kallsyms1.o
LD .tmp_vmlinux.kallsyms2
KSYM .tmp_vmlinux.kallsyms2.o
LD vmlinux
SYSMAP System.map
OBJCOPY arch/riscv/boot/Image
Kernel: arch/riscv/boot/Image is ready
It is saying compiler riscv64-unknown-linux-gnu not found which means either riscv gnu toolchain is not installed on your machine or it is not found by the shell instance in which you are trying to compile linux kernel.
To check if RISC-V GNU toolchain is installed, create a simple C file and try to compile it with RISC-V gnu toolchain with following command:
riscv64-unknown-linux-gnu-gcc <filename.c> -o <binaryname>
1. If RISC-V GNU Toolchain is not installed:
Follow the instruction here to install riscv gnu toolchain. And keep in mind to compile it with make linux instead of make.
2. If RISC-V GNU Toolchain is installed or you are done installing
Add it to the $PATH variable inside .bashrc file located on home directory.
Then try compiling your kernel again.
Can someone pinpoint where I'm doing wrong, PLEASE? I'm so exhausted. I installed MinGW 4.7, python2.7.8, numpy 1.7.1 and scipy0.13.2 to an Anaconda (32bit) environment in Windows7.
Also, for user enviroment variables, I set
C_INCLUDE_PATH:
D:\Anaconda2\envs\arc103\MinGW\i686-w64-mingw32\include
Path (User variable):
C:\Program Files (x86)\Microsoft VS code\bin;D:\Anaconda2\Library\bin;D:\Anaconda2\envs\arc103\MinGW\bin
Tying the following commands in Anaconda Prompt
"f2py -c --help-fcompiler" outputs "... Fortran compilers found:
--fcompiler=gnu95 GNU Fortran 95 compiler (4.7.0) ...."
"f2py -c --help-compiler" outputs
"List of available compilers: ...", not specifically compilers found though.
Running "f2py -c fib1.f -m fib1" according to "NumPy v1.12.dev0 Manual" gives me lots of error as below:
D:\Anaconda2\envs\arc103\Scripts\gfortran.bat -Wall -Wall -shared c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-.7\fib1module.oc:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fortranobject.o c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\fib1.o -Ld:\anaconda2\envs\arc103\mingw\lib\gcc\i686-w64-mingw32\4.7.0 -LD:\Anaconda2\envs\arc103\libs -LD:\Anaconda2\envs\arc103\PCbuild -lpython27 -lgfortran -o .\fib1.pyd
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x35): undefined reference to `__imp__PyNumber_Int'
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x68): undefined reference to `__imp__PyComplex_Type'
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x79): undefined reference to `__imp__PyType_IsSubtype'
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o:fib1module.c:(.text+0x93): undefined reference to `__imp__PyErr_Occurred'
... (Thousands of "undefined reference to" errors I didn't put it here) ...
collect2.exe: error: ld returned 1 exit statuserror: Command "D:\Anaconda2\envs\arc103\Scripts\gfortran.bat -Wall -Wall -shared c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fib1module.o
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\users\dkim1\appdata\local\temp\tmpvyedhg\src.win32-2.7\fortranobject.o
c:\users\dkim1\appdata\local\temp\tmpvyedhg\Release\fib1.o -Ld:\anaconda2\envs\arc103\mingw\lib\gcc\i686-w64-mingw32\4.7.0 -LD:\Anaconda2\envs\arc103\libs
-LD:\Anaconda2\envs\arc103\PCbuild -lpython27 -lgfortran -o .\fib1.pyd" failed with exit status 1
Sorry for the mess. I have spent almost a few months finding out the fix, but it's too hard for me and all gone to no avail. It would be hugely appreciated if you can help me out. Thanks.
Since this is a couple month old, I am not sure if these tips will still help, but I found when building a Fortran to Python module on Win 10, that only compiling for 32bit worked, and you need to use a signature file, i.e. something along the lines of:
f2py.py -c cuncsd.pyf cuncsd.f
Instead of using the i686-w64-mingw32 toolchain I used a straight mingw32 one (to reduce the risk that I accidentally end up with anything 64bit).
I also found that you need to install a special Visual Studio for Python instance as described here:
Microsoft Visual C++ Compiler for Python 3.4
If you are using Python 2.7 this VSC version should do the trick for you, only newer version (3.5, 3.6) are left out at this time.
For reference here is my complete f2py invocation on the console that I ended up using (neither python nor f2py were on the execution PATH):
python C:\Python34\Scripts\f2py.py -c cuncsd.pyf --opt="-frecursive -fmax-stack-var-size=66560" cuncsd.f -llapack -lrefblas -ltmglib
This particular module depends on 32 bit LAPCK shared libraries that I compiled previously, and we found it even works on XP systems.
I later went back and tried to compile this for 64 bit, but eventually gave up, when I always encountered ld errors. I think going forward for Windows 10 it will be much easier to use the embedded Ubuntu to execute and extend Python.
(See How to enable Bash in Windows 10 developer preview? and Getting PyCharm to recognize python on the windows linux subsystem (bash on windows))
I get the following error when running make trying to compile WordNet 3.0:
gcc -m64 -g -O2 -o wishwn wishwn-tkAppInit.o wishwn-stubs.o -L../lib -lWN - F/Library/Frameworks -framework Tk -F/Library/Frameworks -framework Tcl -lpthread -framework CoreFoundation -framework Cocoa -framework Carbon -framework IOKit -lz -lpthread -framework CoreFoundation
ld: warning: ignoring file /Library/Frameworks/Tk.framework/Tk, file was built for i386 which is not the architecture being linked (x86_64): /Library/Frameworks/Tk.framework/Tk
Undefined symbols for architecture x86_64:
"_Tk_Init", referenced from:
_Tcl_AppInit in wishwn-tkAppInit.o
"_Tk_MainEx", referenced from:
_main in wishwn-tkAppInit.o
"_Tk_SafeInit", referenced from:
_Tcl_AppInit in wishwn-tkAppInit.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [wishwn] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I'm running Tcl 8.6 installed via ActiveTcl.
Any ideas?
Each executable must (under all normal circumstances) be built for a single architecture, e.g., for just i386 (32-bit Intel-ish) or x86_64 (64-bit Intel-ish), as while it is possible to have a single CPU support multiple architectures, switching between them is formally a context switch and so is only done between the OS kernel and your code. (Some platforms — notably OSX — have supported multi-architecture binaries — “fat” binaries — in the past, but that's very much like having a single meta-architecture, and you're not supposed to do that now.) This in turn means that the libraries that are linked in, whether shared libraries or not, must also match the architecture you're building for.
Unfortunately, the libraries that you're trying to actually use are built for a different architectures: the ActiveState build you're trying to link against looks like it is for i386, yet you're trying to make a 64-bit version. That won't work.
The simplest way is probably to get the sources for Tcl and Tk and build them in the configuration you want; that's what I do on OSX, and it's easy. Grab the sources from the official release location on SourceForge. To build Tcl for OSX, run:
cd tcl8.6.1/unix
./configure --prefix=/where/you/will/install --enable-64bit
make
make test
sudo make install
You might pass in --enable-framework to configure (but I don't), you might omit the make test and you might not need to use sudo with make install (it depends on where you're installing to).
For Tk, you do:
cd tk8.6.1/unix
./configure --prefix=/where/you/will/install --enable-64bit --enable-aqua
make
sudo make install
You might need to pass in --with-tcl=/location/of/tclConfig.sh (where that's the tclConfig.sh that you just installed above) but the build scripts find it automatically if you've put the Tk sources next to the Tcl sources. There's a test suite for Tk, but it's much more intrusive than the Tcl one (since it has to pop up windows, steal the focus, grab the mouse pointer, that sort of thing; it's a GUI toolkit, so you should expect that sort of thing) which means I can totally understand you not running the unit tests.
Make sure you have i386 and x86_64 listed in your Architectures in Build settings for your lib. Also set Build Active Architecture Only explicitly to No.
I'd like to convert Octave to use CuBLAS for matrix multiplication. This video seems to indicate this is as simple as typing 28 characters:
Using CUDA Library to Accelerate Applications
In practice it's a bit more complex than this. Does anyone know what additional work must be done to make the modifications made in this video compile?
UPDATE
Here's the method I'm trying
in dMatrix.cc add
#include <cublas.h>
in dMatrix.cc change all occurences of (preserving case)
dgemm
to
cublas_dgemm
in my build terminal set
export CC=nvcc
export CFLAGS="-lcublas -lcudart"
export CPPFLAGS="-I/usr/local/cuda/include"
export LDFLAGS="-L/usr/local/cuda/lib64"
the error I receive is:
libtool: link: g++ -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast
-Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2
-o .libs/octave octave-main.o -L/usr/local/cuda/lib64
../libgui/.libs/liboctgui.so ../libinterp/.libs/liboctinterp.so
../liboctave/.libs/liboctave.so -lutil -lm -lpthread -Wl,-rpath
-Wl,/usr/local/lib/octave/3.7.5
../liboctave/.libs/liboctave.so: undefined reference to `cublas_dgemm_'
EDIT2:
The method described in this video requires the use of the fortran "thunking library" bindings for cublas.
These steps worked for me:
Download octave 3.6.3 from here:
wget ftp://ftp.gnu.org/gnu/octave/octave-3.6.3.tar.gz
extract all files from the archive:
tar -xzvf octave-3.6.3.tar.gz
change into the octave directory just created:
cd octave-3.6.3
make a directory for your "thunking cublas library"
mkdir mycublas
change into that directory
cd mycublas
build the "thunking cublas library"
g++ -c -fPIC -I/usr/local/cuda/include -I/usr/local/cuda/src -DCUBLAS_GFORTRAN -o fortran_thunking.o /usr/local/cuda/src/fortran_thunking.c
ar rvs libmycublas.a fortran_thunking.o
switch back to the main build directory
cd ..
run octave's configure with additional options:
./configure --disable-docs LDFLAGS="-L/usr/local/cuda/lib64 -lcublas -lcudart -L/home/user2/octave/octave-3.6.3/mycublas -lmycublas"
Note that in the above command line, you will need to change the directory for the second -L switch to that which matches the path to your mycublas directory that you created in step 4
Now edit octave-3.6.3/liboctave/dMatrix.cc according to the instructions given in the video. It should be sufficient to replace every instance of dgemm with cublas_dgemm and every instance of DGEMM with CUBLAS_DGEMM. In the octave 3.6.3 version I used, there were 3 such instances of each (lower case and upper case).
Now you can build octave:
make
(make sure you are in the octave-3.6.3 directory)
At this point, for me, Octave built successfully. I did not pursue make install although I assume that would work. I simply ran octave using the ./run-octave script in the octave-3.6.3 directory.
The above steps assume a proper and standard CUDA 5.0 install. I will try to respond to CUDA-specific questions or issues, but there are any number of problems that may arise with a general Octave install on your platform. I'm not an octave expert and I won't be able to respond to those. I used CentOS 6.2 for this test.
This method, as indicated, involves modification of the C source files of octave.
Another method was covered in some detail in the S3527 session at the GTC 2013 GPU Tech Conference. This session was actually a hands-on laboratory exercise. Unfortunately the materials on that are not conveniently available. However the method there did not involve any modification of GNU Octave source, but instead uses the LD_PRELOAD capability of Linux to intercept the BLAS library calls and re-direct (the appropriate ones) to the cublas library.
A newer, better method (using the NVBLAS intercept library) is discussed in this blog article
I was able to produce a compiled executable using the information supplied. It's a horrible hack, but it works.
The process looks like this:
First produce an object file for fortran_thunking.c
sudo /usr/local/cuda-5.0/bin/nvcc -O3 -c -DCUBLAS_GFORTRAN fortran_thunking.c
Then move that object file to the src subdirectory in octave
cp /usr/local/cuda-5.0/src/fortran_thunking.o ./octave/src
run make. The compile will fail on the last step. Change to the src directory.
cd src
Then execute the failing final line with the addition of ./fortran_thunking.o -lcudart -lcublas just after octave-main.o. This produces the following command
g++ -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast -Wformat
-Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual
-I/usr/local/cuda/include -o .libs/octave octave-main.o
./fortran_thunking.o -lcudart -lcublas -L/usr/local/cuda/lib64
../libgui/.libs/liboctgui.so ../libinterp/.libs/liboctinterp.so
../liboctave/.libs/liboctave.so -lutil -lm -lpthread -Wl,-rpath
-Wl,/usr/local/lib/octave/3.7.5
An octave binary will be created in the src/.libs directory. This is your octave executable.
In a most recent version of CUDA you don't have to recompile anything. At least as I found in Debian. First, create a config file for NVBLAS (a cuBLAS wrapper). It won't work without it, at all.
tee nvblas.conf <<EOF
NVBLAS_CPU_BLAS_LIB $(dpkg -L libopenblas-base | grep libblas)
NVBLAS_GPU_LIST ALL
EOF
Then use Octave as you would usually do running it with:
LD_PRELOAD=libnvblas.so octave
NVBLAS will do what it can on a GPU while relaying everything else to OpenBLAS.
Further reading:
Benchmark for Octave.
Relevant slides for NVBLAS presentation.
Manual for nvblas.conf
Worth noting that you may not enjoy all the benefits of GPU computing depending on used CPU/GPU: OpenBLAS is quite fast with current multi-core processors. So fast that time spend copying data to GPU, working on it, and copying back could come close to time needed to do the job right on CPU. Check for yourself. Though GPUs are usually more energy efficient.
I'm trying to set up a development environment on my aging Macbook Pro that matches my Linux EC2 production environment. I'm on the home stretch now, need only to get the mod_auth_mysql plugin for apache working. After a few hours of googling and patching and scratching my head, I think I'm almost there, but I've hit something that nothing I've found online has been able to solve.
nathan#ichigo:/usr/local/mod_auth_mysql-2.9.0$ sudo apxs -c -L/usr/local/mysql/lib -I/usr/local/mysql/include/ -lmysqlclient -lm -lz mod_auth_mysql.c
/usr/share/apr-1/build-1/libtool --silent --mode=compile gcc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/usr/local/include -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/local/mysql/include/ -c -o mod_auth_mysql.lo mod_auth_mysql.c && touch mod_auth_mysql.slo
/usr/share/apr-1/build-1/libtool --silent --mode=link gcc -o mod_auth_mysql.la -L/usr/local/mysql/lib -lmysqlclient -lm -lz -rpath /usr/libexec/apache2 -module -avoid-version mod_auth_mysql.lo
ld: warning: in /usr/local/mysql/lib/libmysqlclient.dylib, file is not of required architecture
ld: warning: in /usr/local/mysql/lib/libz.a, file is not of required architecture
warning: no debug symbols in executable (-arch x86_64)
I think this is complaining because it's trying to build for 64-bit, but I'm on a 32-bit platform? I'm not entirely sure. I've tried forcing a 32-bit build with env ARCHFLAGS and -D arch on apxs, to no avail.
FWIW, I also tried mod_auth_mysql-3.0.0, and hit more or less the same result.
Alternatively, is there a more modern way to auth against mysql in Apache? I didn't find anything else, but this module hasn't gotten any love in a good 5 years, and I had to apply some patches I found scattered about the 'net to even get this far.
First, check what architectures your libraries support with file /usr/local/mysql/lib/libmysqlclient.dylib, etc. Once you know that, I think you can control what apxs builds for by adding flags like -Wc,"-arch i386" -Wl,"-arch i386"