Re: [aur-general] Unresponsive maintainer (=TU)
* Fabio Castelli (Wed, 12 Nov 2014 10:35:25 -0600): > 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 to #include "../driver/mysql_public_iface.h" and issue $ g++ -o prepared_statement -Wl,-Bdynamic -lmysqlcppconn \ prepared_statement.cpp Then you can run $ ./prepared_statement I did the same with resultset.cpp, resultset_meta.cpp (which resulted in a runtime error) and exceptions.cpp. Others needed more tinkering, which I'm now unable to do. Good luck and I'll be back within a few hours. Regards, Marcel [1] https://aur.archlinux.org/packages/mysql-workbench/
Re: [aur-general] Unresponsive maintainer (=TU)
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
Re: [aur-general] Unresponsive maintainer (=TU)
* Fabio Castelli (Wed, 12 Nov 2014 12:18:30 +0100): > 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=packages/mariadb [3]https://aur.archlinux.org/packages/mysql-connector-c%2B%2B/ [4]https://lists.archlinux.org/pipermail/arch-general/2014-October/037497.html
Re: [aur-general] Unresponsive maintainer (=TU)
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
Re: [aur-general] Unresponsive maintainer (=TU)
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 ha scritto: >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/ -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 7 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 1 fully signed off package * 16 packages missing signoffs * 5 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (7 total) == * ibus-googlepinyin-0.1.2-6 (any) * fcitx-4.2.8.5-6 (i686) * librime-1.2.20141112-1 (i686) * opencc-1.0.2-1 (i686) * fcitx-4.2.8.5-6 (x86_64) * librime-1.2.20141112-1 (x86_64) * opencc-1.0.2-1 (x86_64) == Incomplete signoffs for [community] (12 total) == * freevo-1.9.0-14 (any) 0/2 signoffs * ibus-googlepinyin-0.1.2-6 (any) 0/2 signoffs * salt-2014.7.0-1 (any) 0/2 signoffs * avr-gcc-4.9.2-1 (i686) 0/1 signoffs * fcitx-4.2.8.5-6 (i686) 0/1 signoffs * librime-1.2.20141112-1 (i686) 0/1 signoffs * opencc-1.0.2-1 (i686) 0/1 signoffs * avr-gcc-4.9.2-1 (x86_64) 0/2 signoffs * fcitx-4.2.8.5-6 (x86_64) 0/2 signoffs * librime-1.2.20141112-1 (x86_64) 0/2 signoffs * opencc-1.0.2-1 (x86_64) 0/2 signoffs * uwsgi-2.0.7-6 (x86_64) 1/2 signoffs == Incomplete signoffs for [unknown] (4 total) == * bluegriffon-1.7.2-1 (i686) 0/1 signoffs * packagekit-qt-0.9.2-2 (i686) 0/1 signoffs * bluegriffon-1.7.2-1 (x86_64) 0/2 signoffs * packagekit-qt-0.9.2-2 (x86_64) 0/2 signoffs == Completed signoffs (1 total) == * uwsgi-2.0.7-6 (i686) == All packages in [community-testing] for more than 14 days (5 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * packagekit-qt-0.9.2-2 (i686), since 2014-09-29 * packagekit-qt-0.9.2-2 (x86_64), since 2014-09-29 * uwsgi-2.0.7-6 (i686), since 2014-10-27 * uwsgi-2.0.7-6 (x86_64), since 2014-10-27 == Top five in signoffs in last 24 hours == 1. fyan - 8 signoffs 2. bisson - 6 signoffs 3. bpiotrowski - 4 signoffs 4. anatolik - 2 signoffs
