[aur-general] Unresponsive maintainer (=TU)
Hi, On 10 October I discovered an error building mysql-connector-c++ when (Oracle's) MySQL [1] is build with compiler flag -fno-rtti. I posted a comment asking about the removal of this flag in PKGBUILD (it only saves a bit of memory, but everything works fine without this flag). On 29 October I sent the maintainer (cc'ed here) an email politely asking again to remove the problematic flag. Until now I didn't get a response, nor did he change his PKGBUILD. Now someone else is asking the same in a comment. What to do in this situation? Filing an orphanage request seems too harsh to me. Moreover, the maintainer is a TU. Any advice is welcome. Regards, Marcel [1] https://aur.archlinux.org/pkgbase/mysql/
Hi
First of all thank you for posting this discussion in the ML, I'd be glad to read some other opinions here.
About the unresponsive maintainer the situation requires testing and fixes to package that I'm not able to do now.
I could answer you to inform you about the point but I wished to do a better investigation to track the source of the issue.
The package here discussed is mysql-clients (sorry for no links, I'm writing from my mobile phone) and basically it's built like the mariadb-clients using the flag no-rtti .
Another package in the AUR called mysql-connector-c++, which unfortunately I don't use, requires the mysql-clients package to be built without the no-rtti flag.
This is entirely the point here, I don't know why the mysql-connector-c++ is unable to built without rtti. The same package builds fine using mariadb-clients WITH no-rtti.
I think the issue should be searched in the mysql-connector-c++ package, building the mysql-clients package using different build options is not the proper way to solve the issue. The same would happen if the mysql-clients package would be still in the official repository.
The current maintainer of mysql-connector-c++ should help me to find and solve the mysql-connector-c++ issues with mysql-clients when using the no-rtti instead of asking to alter the build process for the mysql-clients package.
I'm not at all convinced the issue is in mysql-clients package as the mariadb-clients is built with the same flags and it doesn't produce any issue with the mysql-connector-c++ package.
Regards,
--
Muflone
Il 12 novembre 2014 01:43:27 CET, Marcel Korpel
Hi,
On 10 October I discovered an error building mysql-connector-c++ when (Oracle's) MySQL [1] is build with compiler flag -fno-rtti. I posted a comment asking about the removal of this flag in PKGBUILD (it only saves a bit of memory, but everything works fine without this flag).
On 29 October I sent the maintainer (cc'ed here) an email politely asking again to remove the problematic flag. Until now I didn't get a response, nor did he change his PKGBUILD. Now someone else is asking the same in a comment.
What to do in this situation? Filing an orphanage request seems too harsh to me. Moreover, the maintainer is a TU.
Any advice is welcome.
Regards, Marcel
-- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
Am 12.11.2014 um 12:18 schrieb Fabio Castelli:
Another package in the AUR called mysql-connector-c++, which unfortunately I don't use, requires the mysql-clients package to be built without the no-rtti flag.
This is entirely the point here, I don't know why the mysql-connector-c++ is unable to built without rtti. The same package builds fine using mariadb-clients WITH no-rtti.
I think the issue should be searched in the mysql-connector-c++ package, ...
I don't. Using -fno-rtti to build a package that many other packages may link to seems wrong. It's a typical case of premature optimization. And it hurts, as is obviuous here. That flags cripples the c++ compiler to a (non-standard) subset of the language, in non-obvious ways: beside typeid, dynamic_cast and exception handling may work differently (if at all). The first is typically used in libraries like boost::variant, which are useful in applications communicating with a database. As Marcel already noted: To disable RTTI saves some kilobytes of executable size. (Code size and working set size is unaffected.) So it buys really nothing, considering that other build flags used routinely in Arch (-D_FORTIFY_SOURCE=2 or -fstack-protector-strong) are much more costly. Regards
* Fabio Castelli
The package here discussed is mysql-clients
No, it's libmysqlclient [1] that causes problems.
Another package in the AUR called mysql-connector-c++, which unfortunately I don't use, requires the mysql-clients package to be built without the no-rtti flag.
This is entirely the point here, I don't know why the mysql-connector-c++ is unable to built without rtti. The same package builds fine using mariadb-clients WITH no-rtti.
libmariadbclient [2] is indeed build with no-rtti, strange. The problem with mysql-connector-c++ [3] is this: …/driver/mysql_metadata.cpp:1216:74: error: ‘dynamic_cast’ not permitted with -fno-rtti which is set in libmysqlclient. I already asked a question about this on the Arch ML [4]. I'm willing to look at this as an issue of mysql-connector-c++, but I don't know how to circumvent this. Regards, Marcel (maintainer of [3]) [1]https://aur.archlinux.org/packages/libmysqlclient/ [2]https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=p... [3]https://aur.archlinux.org/packages/mysql-connector-c%2B%2B/ [4]https://lists.archlinux.org/pipermail/arch-general/2014-October/037497.html
Hello
libmariadbclient [2] is indeed build with no-rtti, strange. The problem with mysql-connector-c++ [3] is this:
…/driver/mysql_metadata.cpp:1216:74: error: ‘dynamic_cast’ not permitted with -fno-rtti
which is set in libmysqlclient. I already asked a question about this on the Arch ML [4].
I'm willing to look at this as an issue of mysql-connector-c++, but I don't know how to circumvent this.
After a bit of analysis I think to have found the source of the issue (in the mysql-connector-c++ source) and successfully built the mysql-connector-c++ package against libmysqlclient 5.6.20 WITH -fno-rtti build flag. Please explain me how can I use or send me a source example (with build instruction included please) which uses the mysql-connector-c++ to check if everything works fine with my build and if it works fine we'll see how to fix the package. Regards, -- Muflone
* Fabio Castelli
Please explain me how can I use or send me a source example (with build instruction included please) which uses the mysql-connector-c++ to check if everything works fine with my build and if it works fine we'll see how to fix the package.
The only program that uses mysql-connector-c++ I know of is
mysql-workbench [1], but that's a bit bloated to build only to test if
connector-c++ is working correctly (and I don't know which parts of
workbench use it, so that's rather uncertain).
I think the best you can do is test the examples in examples/ of
mysql-connector-c++. First set the credentials of your locally running
db in examples.h. Then change the line in the example file, e.g.
prepared_statement.cpp that reads
#include
Hi
The only program that uses mysql-connector-c++ I know of is mysql-workbench [1], but that's a bit bloated to build only to test if connector-c++ is working correctly (and I don't know which parts of workbench use it, so that's rather uncertain).
I cannot build the ctemplate package because I've no access to the Google Code SVN repository here, therefore I'm unable to check the mysql-connector-c++ package using mysql-workbench.
I think the best you can do is test the examples in examples/ of mysql-connector-c++.
I built the example source using: g++ -o prepared_statement -Wl,-Bdynamic -lmysqlcppconn \ -I ~/mysql-connector-c++/src/mysql-connector-c++-1.1.4/ \ prepared_statement.cpp The results of the command is exactly the same [1] rebuilding the prepared_statement against libmariadbclient or libmysqlclient packages with any of the following patches. The package libmysqlclient provides a mysql_config command which *HAS* the --cxxflags option. The package libmariadbclient provides a mysql_config command which *HAS NOT* the --cxxflags option. When the package mysql-connection-c++ is built against the libmariasqlclient it cannot get the build flags because it uses the missing --cxxflags option and then fallbacks to --cflags. When the package mysql-connection-c++ is built against the libmysqlclient it receives the build flags using the --cxxflags option and then builds the software including the -fno-rtti option. There are two different ways to fix the issue with the mysql-connector-c++ package: a) remove the -fno-rtti option from the cxxflags offered by mysql_config, see [2] b) fix the broken FindMySQL.cmake source which assumes that since the version 5.6.3 MySQL is *ALWAYS* built with the MYSQL_CXX_LINKAGE option set when cmake is run but it doesn't make anything to solve if the no-rtti flag was used. See [3] how to honor the MYSQL_CXX_LINKAGE option. The latter patch allows you to build your package with -DMYSQL_CXX_LINKAGE set to 0 (to disable the use of cxxflags) or to 1 to use the cxxflags. Without this patch the option MYSQL_CXX_LINKAGE is ignored at all since MySQL 5.6.3. Please update your PKGBUILD accordingly to these suggestions. I don't plan to change the build process in a way too much different from the libmariadbclient build process, therefore I will not remove the no-rtti flag until I can find a valid reason to do that. Best regards [1] http://paste.muflone.com/147 [2] https://gist.github.com/muflone/c6641fc1acce22583235/b92d41d44d11bbf9bd621f4... [3] https://gist.github.com/muflone/c6641fc1acce22583235/384d1a350e246092b57ad66... -- Muflone
* Fabio Castelli
b) fix the broken FindMySQL.cmake source which assumes that since the version 5.6.3 MySQL is *ALWAYS* built with the MYSQL_CXX_LINKAGE option set when cmake is run but it doesn't make anything to solve if the no-rtti flag was used. See [3] how to honor the MYSQL_CXX_LINKAGE option.
I chose this alternative, also due to the download link of [2] being broken (it actually downloads [3], and yes, I know how to clone a git repository). Thanks a lot for this patch, I updated my PKGBUILD. Regards, Marcel
participants (3)
-
Fabio Castelli
-
Marcel Korpel
-
Markus Schaaf