4:28 p.m.
Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x release
series to be GA status, I'm planning to push it into rawhide shortly to
replace the 5.1.x series. Theoretically, this will go pretty smoothly.
I'm aware of a couple of ABI-level issues:
1. libmysqlclient.so, which is linked into all manner of stuff, is
supposed to be ABI-compatible with the previous releases. However,
I got tired of the amount of visible churn in exported-symbols-you're-
not-supposed-to-use. The new release will use a linker --version-script
to hide everything except the documented API functions. This might
break any apps that are relying on non-API functions. If so, I'm
willing to consider on a case-by-case basis whether to add those symbols
back to the ABI or fix the callers.
2. libmysqlclient_r.so is gone altogether; there's no need for it since
the regular libmysqlclient.so library is supposed to be thread safe.
AFAIK this will require rebuilding only the following packages:
mysql++
mysql-connector-c++
nekovm
qt-mysql
For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
so that a simple rebuild with no source-code changes should be
sufficient. Eventually we'll probably want to fix the source code to
not refer to libmysqlclient_r, but that might take awhile if upstreams
are worried about portability.
There are also some SQL-level incompatibilities called out here:
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
I'm not sure to what extent these may affect Fedora applications,
but it seems like the easiest way to find out is to try them.
Any objections? Anything people think should be tested before pushing?
regards, tom lane
8:50 a.m.
Hi,
2010/12/22 Tom Lane <tgl(a)redhat.com>:
Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x
release
series to be GA status, I'm planning to push it into rawhide shortly to
replace the 5.1.x series. Theoretically, this will go pretty smoothly.
I'm aware of a couple of ABI-level issues:
1. libmysqlclient.so, which is linked into all manner of stuff, is
supposed to be ABI-compatible with the previous releases. However,
I got tired of the amount of visible churn in exported-symbols-you're-
not-supposed-to-use. The new release will use a linker --version-script
to hide everything except the documented API functions. This might
break any apps that are relying on non-API functions. If so, I'm
willing to consider on a case-by-case basis whether to add those symbols
back to the ABI or fix the callers.
Hmm...
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so:
symbol client_errors, version libmysqlclient_16 not defined in file
libmysqlclient.so.16 with link time reference in Unknown on line 0
I guess I need to rebuild php. Apart of this for now works ok on my F14 :)
2. libmysqlclient_r.so is gone altogether; there's no need for it since
the regular libmysqlclient.so library is supposed to be thread safe.
AFAIK this will require rebuilding only the following packages:
mysql++
mysql-connector-c++
nekovm
qt-mysql
For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
so that a simple rebuild with no source-code changes should be
sufficient. Eventually we'll probably want to fix the source code to
not refer to libmysqlclient_r, but that might take awhile if upstreams
are worried about portability.
There are also some SQL-level incompatibilities called out here:
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
I'm not sure to what extent these may affect Fedora applications,
but it seems like the easiest way to find out is to try them.
Any objections? Anything people think should be tested before pushing?
regards, tom lane
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Best regards,
Michal
Sent from my fscking awesome Black Hole Generator
4:36 p.m.
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4(a)gmail.com> writes:
2010/12/22 Tom Lane <tgl(a)redhat.com>:
> 1. libmysqlclient.so, which is linked into all manner of stuff, is
> supposed to be ABI-compatible with the previous releases. However,
> I got tired of the amount of visible churn in exported-symbols-you're-
> not-supposed-to-use. The new release will use a linker --version-script
> to hide everything except the documented API functions. This might
> break any apps that are relying on non-API functions. If so, I'm
> willing to consider on a case-by-case basis whether to add those symbols
> back to the ABI or fix the callers.
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so:
symbol client_errors, version libmysqlclient_16 not defined in file
libmysqlclient.so.16 with link time reference in Unknown on line 0
OK, looks like I'd better add that back to the ABI. Done in mysql-5.5.8-2.
I guess I need to rebuild php. Apart of this for now works ok on my
F14 :)
php will still need a rebuild.
regards, tom lane
9:01 a.m.
2010/12/27 Tom Lane <tgl(a)redhat.com>:
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4(a)gmail.com>
writes:
> 2010/12/22 Tom Lane <tgl(a)redhat.com>:
>> 1. libmysqlclient.so, which is linked into all manner of stuff, is
>> supposed to be ABI-compatible with the previous releases. However,
>> I got tired of the amount of visible churn in exported-symbols-you're-
>> not-supposed-to-use. The new release will use a linker --version-script
>> to hide everything except the documented API functions. This might
>> break any apps that are relying on non-API functions. If so, I'm
>> willing to consider on a case-by-case basis whether to add those symbols
>> back to the ABI or fix the callers.
> PHP Warning: PHP Startup: Unable to load dynamic library
> '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so:
> symbol client_errors, version libmysqlclient_16 not defined in file
> libmysqlclient.so.16 with link time reference in Unknown on line 0
OK, looks like I'd better add that back to the ABI. Done in mysql-5.5.8-2.
Ok, will check it later
> I guess I need to rebuild php. Apart of this for now works ok on my F14 :)
php will still need a rebuild.
Ok
regards, tom lane
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Best regards,
Michal
Sent from my fscking awesome Black Hole Generator
4:12 p.m.
W dniu 28 grudnia 2010 16:01 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com> napisał:
2010/12/27 Tom Lane <tgl(a)redhat.com>:
> =?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4(a)gmail.com> writes:
>> 2010/12/22 Tom Lane <tgl(a)redhat.com>:
>>> 1. libmysqlclient.so, which is linked into all manner of stuff, is
>>> supposed to be ABI-compatible with the previous releases. However,
>>> I got tired of the amount of visible churn in exported-symbols-you're-
>>> not-supposed-to-use. The new release will use a linker --version-script
>>> to hide everything except the documented API functions. This might
>>> break any apps that are relying on non-API functions. If so, I'm
>>> willing to consider on a case-by-case basis whether to add those symbols
>>> back to the ABI or fix the callers.
>
>> PHP Warning: PHP Startup: Unable to load dynamic library
>> '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so:
>> symbol client_errors, version libmysqlclient_16 not defined in file
>> libmysqlclient.so.16 with link time reference in Unknown on line 0
>
> OK, looks like I'd better add that back to the ABI. Done in mysql-5.5.8-2.
Ok, will check it later
>
>> I guess I need to rebuild php. Apart of this for now works ok on my F14 :)
>
> php will still need a rebuild.
Ok
I've rebuild both packages and now works just fine. Thanks!
--
Best regards,
Michal
Sent from my fscking awesome Black Hole Generator
12:46 p.m.
I have just notice, in the spec
-DWITH_READLINE=ON
Which means, according to INSTALL-SOURCE :
* -DWITH_READLINE=bool
Whether to use the readline library bundled with the
distribution.
Does this use of a bundled library is wanted ?
To use the system library, option should be
-DWITH_READLINE=OFF \
-DWITH_LIBEDIT=OFF \
With this :
ldd /usr/bin/client/mysql
...
libreadline.so.6 => /lib64/libreadline.so.6 (0x0000003530a00000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003531600000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003530e00000)
...
But, it's seems the readline.cmake is still buggy ...
(history feature not detected, readline/libedit choice...)
With readline-devel-6.1-2.fc14.x86_64:
-- Performing Test readline_HAVE_HIST_ENTRY
-- Performing Test readline_HAVE_HIST_ENTRY - Failed
-- Performing Test readline_USE_LIBEDIT_INTERFACE
-- Performing Test readline_USE_LIBEDIT_INTERFACE - Failed
-- Performing Test readline_USE_NEW_READLINE_INTERFACE
-- Performing Test readline_USE_NEW_READLINE_INTERFACE - Success
With only libedit-devel-3.0-2.20090923cvs.fc14.x86_64:
CMake Error at cmake/readline.cmake:223 (MESSAGE):
Cannot find system readline or libedit libraries.Use WITH_READLINE or
WITH_LIBEDIT
Call Stack (most recent call first):
CMakeLists.txt:256 (MYSQL_CHECK_READLINE)
Best regards,
Remi.
3:24 p.m.
Remi Collet <Fedora(a)FamilleCollet.com> writes:
I have just notice, in the spec
-DWITH_READLINE=ON
Which means, according to INSTALL-SOURCE :
* -DWITH_READLINE=bool
Whether to use the readline library bundled with the
distribution.
Does this use of a bundled library is wanted ?
Not really, but as you notice, using readline doesn't actually work,
and never has, and I know that upstream isn't exactly interested in
making it work. So I haven't bothered to try to hack it. The bundled
library isn't libreadline anyway, it's their own homebrew
implementation; so I don't think this is violating any packaging
guidelines.
regards, tom lane
9:27 a.m.
Le 22/12/2010 23:28, Tom Lane a écrit :
mysql++
I've just committed some minor changes to this one (not related to the
MySQL 5.5 update, but on my TODO for a while)
Just need to launch the build (I could do it as soon as -2 will hit rawhide)
PHP also build and works fine with -2.
Remi.
9:37 a.m.
Remi Collet <Fedora(a)FamilleCollet.com> writes:
Le 22/12/2010 23:28, Tom Lane a écrit :
> mysql++
I've just committed some minor changes to this one (not related
to the
MySQL 5.5 update, but on my TODO for a while)
Just need to launch the build (I could do it as soon as -2 will hit
rawhide)
mysql-5.5.8-2 should be in the buildroots as of yesterday.
regards, tom lane
1:43 p.m.
Tom Lane wrote:
Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x
release
series to be GA status, I'm planning to push it into rawhide shortly to
replace the 5.1.x series. Theoretically, this will go pretty smoothly.
I'm aware of a couple of ABI-level issues:
1. libmysqlclient.so, which is linked into all manner of stuff, is
supposed to be ABI-compatible with the previous releases. However,
I got tired of the amount of visible churn in exported-symbols-you're-
not-supposed-to-use. The new release will use a linker --version-script
to hide everything except the documented API functions. This might
break any apps that are relying on non-API functions. If so, I'm
willing to consider on a case-by-case basis whether to add those symbols
back to the ABI or fix the callers.
2. libmysqlclient_r.so is gone altogether; there's no need for it since
the regular libmysqlclient.so library is supposed to be thread safe.
AFAIK this will require rebuilding only the following packages:
mysql++
mysql-connector-c++
nekovm
qt-mysql
For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
so that a simple rebuild with no source-code changes should be
sufficient. Eventually we'll probably want to fix the source code to
not refer to libmysqlclient_r, but that might take awhile if upstreams
are worried about portability.
There are also some SQL-level incompatibilities called out here:
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
I'm not sure to what extent these may affect Fedora applications,
but it seems like the easiest way to find out is to try them.
Any objections? Anything people think should be tested before pushing?
regards, tom lane
Is the following a MySQL issue or a Bacula issue?
/builddir/build/BUILD/bacula-5.0.3/bacula-mysql/src/cats/mysql.c:295: undefined reference
to `my_thread_end'
http://koji.fedoraproject.org/koji/getfile?taskID=2699251&name=build.log
J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
2:16 p.m.
Jon Ciesla <limb(a)jcomserv.net> writes:
Tom Lane wrote:
> I got tired of the amount of visible churn in exported-symbols-you're-
> not-supposed-to-use. The new release will use a linker --version-script
> to hide everything except the documented API functions. This might
> break any apps that are relying on non-API functions. If so, I'm
> willing to consider on a case-by-case basis whether to add those symbols
> back to the ABI or fix the callers.
Is the following a MySQL issue or a Bacula issue?
/builddir/build/BUILD/bacula-5.0.3/bacula-mysql/src/cats/mysql.c:295:
undefined reference to `my_thread_end'
Well, it's certainly a byproduct of that change. So far as I can find,
mysql_thread_end is a documented part of the API and my_thread_end is
not. Is there a good reason for Bacula to be calling the latter?
A quick look into the mysql sources finds
void STDCALL mysql_thread_end()
{
#ifdef THREAD
my_thread_end();
#endif
}
which makes it look like the correct answer is "no" ...
regards, tom lane
1:23 p.m.
Tom Lane wrote:
Jon Ciesla <limb(a)jcomserv.net> writes:
> Tom Lane wrote:
>
>> I got tired of the amount of visible churn in exported-symbols-you're-
>> not-supposed-to-use. The new release will use a linker --version-script
>> to hide everything except the documented API functions. This might
>> break any apps that are relying on non-API functions. If so, I'm
>> willing to consider on a case-by-case basis whether to add those symbols
>> back to the ABI or fix the callers.
>>
> Is the following a MySQL issue or a Bacula issue?
>
> /builddir/build/BUILD/bacula-5.0.3/bacula-mysql/src/cats/mysql.c:295: undefined
reference to `my_thread_end'
>
Well, it's certainly a byproduct of that change. So far as I can find,
mysql_thread_end is a documented part of the API and my_thread_end is
not. Is there a good reason for Bacula to be calling the latter?
A quick look into the mysql sources finds
void STDCALL mysql_thread_end()
{
#ifdef THREAD
my_thread_end();
#endif
}
which makes it look like the correct answer is "no" ...
regards, tom lane
So should simply patching to call mysql_thread_end instead should do the
trick?
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
1:09 p.m.
Jon Ciesla wrote:
Tom Lane wrote:
> Jon Ciesla <limb(a)jcomserv.net> writes:
>
>
>> So should simply patching to call mysql_thread_end instead should do the
>> trick?
>>
>>
> Right.
>
> regards, tom lane
>
>
I'll give that a whirl, thanks!
J
That did indeed work. Thank you!
J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
2:15 p.m.
On Wed, Dec 22, 2010 at 5:28 PM, Tom Lane wrote:
For now I'll include a symlink libmysqlclient_r.so ->
libmysqlclient.so,
so that a simple rebuild with no source-code changes should be
sufficient. Eventually we'll probably want to fix the source code to
not refer to libmysqlclient_r, but that might take awhile if upstreams
are worried about portability.
Hi Tom,
With the above change, is it reasonable to assume that the mysql5.5
package will not be backwards compatible? In other words, if I build
some software against mysql5.5, can't I use it against mysql5.1 ?
Orcan
2:49 p.m.
Orcan Ogetbil <oget.fedora(a)gmail.com> writes:
On Wed, Dec 22, 2010 at 5:28 PM, Tom Lane wrote:
> For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
> so that a simple rebuild with no source-code changes should be
> sufficient. Eventually we'll probably want to fix the source code to
> not refer to libmysqlclient_r, but that might take awhile if upstreams
> are worried about portability.
With the above change, is it reasonable to assume that the mysql5.5
package will not be backwards compatible? In other words, if I build
some software against mysql5.5, can't I use it against mysql5.1 ?
If you're building it against libmysqlclient_r, yes you'll have an
issue, but ISTM you're likely to have other issues anyway if you expect
ABI compatibility in that direction.
regards, tom lane
4854
days inactive
4873
days old
17 comments
5 participants
participants (5)
-
Jon Ciesla -
Michał Piotrowski -
Orcan Ogetbil -
Remi Collet -
Tom Lane