Stop linking plugins to the server executable on Windows.
Instead, extract whole server functionality into a large DLL, called
server.dll. Link both plugins, and small server "stub" exe to it.
This eliminates plugin dependency on the name of the server executable.
It also reduces the size of the packages (since tiny mysqld.exe
and mariadbd.exe are now both linked to one big DLL)
Also, simplify the functionality of exporing all symbols from selected
static libraries. Rely on WINDOWS_EXPORT_ALL_SYMBOLS, rather than old
self-backed solution.
fix compile error
replace GetProcAddress(GetModuleHandle(NULL), "variable_name")
for server exported data with actual variable names.
Runtime loading was never required,was error prone
, since symbols could be missing at runtime, and now it actually failed,
because we do not export symbols from executable anymore, but from a shared
library
This did require a MYSQL_PLUGIN_IMPORT decoration for the plugin,
but made the code more straightforward, and avoids missing symbols at
runtime (as mentioned before).
The audit plugin is still doing some dynamic loading, as it aims to work
cross-version. Now it won't work cross-version on Windows, as it already
uses some symbols that are *not* dynamically loaded, e.g fn_format
and those symbols now exported from server.dll , when earlier they were
exported by mysqld.exe
Windows, fixes for storage engine plugin loading
after various rebranding stuff
Create server.dll containing functionality of the whole server
make mariadbd.exe/mysqld.exe a stub that is only calling mysqld_main()
fix build
To change all executables to have a mariadb name I had to:
- Do name changes in every CMakeLists.txt that produces executables
- CREATE_MARIADB_SYMLINK was removed and GET_SYMLINK added by Wlad to reuse the function in other places also
- The scripts/CMakeLists.txt could make use of GET_SYMLINK instead of introducing redundant code, but I thought I'll leave that for next release
- A lot of changes to debian/.install and debian/.links files due to swapping of real executable and symlink. I did not however change the name of the manpages, so the real name is still mysql there and mariadb are symlinks.
- The Windows part needed a change now when we made the executables mariadb -named. MSI (and ZIP) do not support symlinks and to not break backward compatibility we had to include mysql named binaries also. Done by Wlad
post-merge fixes:
* .gitignore
* don't put the keyword COMPONENT into ${COMP} anymore
* don't alias mytop, but do alias mysql_client_test
* don't symlink manpages, use troff aliasing technique instead
(symlinked manpages break rpm and out-of-source bintar builds)
* move debian to use troff aliased manpages, fix typos in debian files,
put aliases in the correct packages, add more aliases to match
rpm/bintar packaging
Don't install server files if WITHOUT_SERVER is specified.
"Server files" are defined as files going into the MariaDB-Server RPM,
that is files in the components Server, ManPagesServer, Server_Scripts,
IniFiles, SuportFiles, and Readme.
- the probably ultimate fix for dependencies on VS
- remove some GET_TARGET_PROPERTY(LOCATION ...), they are deprecated in
cmake 3.9
- simplify signing targets on Windows.
- remove INSTALL_DEBUG_TARGET, we do not mix binaries from different builds
in the same package
~40% bugfixed(*) applied
~40$ bugfixed reverted (incorrect or we're not buggy)
~20% bugfixed applied, despite us being not buggy
(*) only changes in the server code, e.g. not cmakefiles
Bug#18187290 ISSUE WITH BUILDING MYSQL USING CMAKE 2.8.12
We want to upgrade to VS2013 on Windows.
In order to do this, we need to upgrade to cmake 2.8.12
This has introduced some incompatibilities for .pdb files,
and "make install" no longer works.
To reproduce:
cmake --build . --target package --config debug
The fix:
Rather than installing .pdb files for static libraries, we use the /Z7 flag
to store symbolic debugging information in the .obj files.
Backported only the softlink part of the patch,
*not* the bumping of library version.
With this patch, the libmysql/ directory contains:
libmysqlclient.a
libmysqlclient_r.a -> libmysqlclient.a
libmysqlclient_r.so -> libmysqlclient.so*
libmysqlclient_r.so.18 -> libmysqlclient.so.18*
libmysqlclient_r.so.18.0.0 -> libmysqlclient.so.18.0.0*
libmysqlclient.so -> libmysqlclient.so.18*
libmysqlclient.so.18 -> libmysqlclient.so.18.0.0*
libmysqlclient.so.18.0.0*
mysql-test/suite/innodb/t/group_commit_crash.test:
remove autoincrement to avoid rbr being used for insert ... select
mysql-test/suite/innodb/t/group_commit_crash_no_optimize_thread.test:
remove autoincrement to avoid rbr being used for insert ... select
mysys/my_addr_resolve.c:
a pointer to a buffer is returned to the caller -> the buffer cannot be on the stack
mysys/stacktrace.c:
my_vsnprintf() is ok here, in 5.5
- Mark test components, plugins etc with COMPONENT Test, to get them excluded from the MSI
- Only include debug symbols for client and embedded libs and also
mysqld.exe and server plugins (so we can still can get a callstack in case of crash)
The rest (all *.pdbs, test components, MTR) can be obtained from the big ZIP distribution, if required.
Backport version info handling (Windows-specific) from next-mr.
Instead of adding ".res" object as linker flag, add resource file (.rc) file to the source list.
This is more obvious and less error prone method.
mysqld-debug.exe in 5.5.3 on windows
Fix:
- Do not rename PDB, install mysqld.pdb matching
mysqld-debug.exe into bin\debug subdirectory
- Stack tracing code will now additionally look in
debug subdirectory of the application directory
for debug symbols.
- Small cleanup in stacktracing code: link with
dbghelp rather than load functions dynamically
at runtime, since dbghelp.dll is always present.
- Install debug binaries with WiX
cmake/install_macros.cmake:
Add optional COMPONENT and PDB_DESTINATION
to INSTALL_DEBUG_TARGET
mysys/stacktrace.c:
If binary is build with DBUG, also look in debug subdirectory
of executable directory. Packaging will put some PDBs there
(e.g bin\mysqld-debug.exe will have corresponding pdb in
bin\debug)
Also some cleanup: do not load dbghelp dynamically, instead
link with it. dbghelp is present on all Windows starting with
XP.
packaging/WiX/CPackWixConfig.cmake:
Install debug binaries
sql/CMakeLists.txt:
Do not rename PDB for mysqld-debug.exe, install it in debug subdirectory
