Package Details: libmysqlclient 8.2.0-1

Git Clone URL: https://aur.archlinux.org/mysql.git (read-only, click to copy)
Package Base: mysql
Description: MySQL client libraries
Upstream URL: https://www.mysql.com/products/community/
Licenses: GPL
Conflicts: libmariadbclient, mariadb-libs
Provides: libmariadbclient, libmysqlclient, mariadb-libs
Submitter: Barthalion
Maintainer: muflone
Last Packager: muflone
Votes: 80
Popularity: 0.000190
First Submitted: 2013-04-25 19:13 (UTC)
Last Updated: 2023-11-15 01:11 (UTC)

Required by (310)

Sources (7)

Pinned Comments

muflone commented on 2023-08-16 17:21 (UTC) (edited on 2023-08-16 20:41 (UTC) by muflone)

Warning

https://dev.mysql.com/doc/refman/8.1/en/downgrading.html

Downgrade from MySQL 8.1 to MySQL 8.0 or earlier is not supported. The only supported alternative is to restore a backup taken before upgrading. It is therefore imperative that you back up your data before starting the upgrade process.

MySQL 8.0 is available in https://aur.archlinux.org/packages/mysql80

Latest Comments

1 2 3 4 5 6 .. 19 Next › Last »

Speykious commented on 2023-12-18 18:42 (UTC)

@muflone Thanks, yeah I did rebuild the package after sending that message. It took 3 hours to compile but it works now!

muflone commented on 2023-12-18 17:51 (UTC)

@Speykious this sort of error means you haven't rebuilt the package after the icu change: https://wiki.archlinux.org/title/Arch_User_Repository#Updating_packages

Speykious commented on 2023-12-18 15:11 (UTC) (edited on 2023-12-18 15:14 (UTC) by Speykious)

mysqld kept failing to launch, so I looked at the logs with journalctl and saw this:

/usr/bin/mysqld: error while loading shared libraries: libicuuc.so.73: cannot open shared object file: No such file or directory

The package core/icu just got an update and is now apparently on version 74. I'd love to rollback icu but way too many things depend on it, I'd be happy for some kind of solution.

muflone commented on 2023-08-16 17:21 (UTC) (edited on 2023-08-16 20:41 (UTC) by muflone)

Warning

https://dev.mysql.com/doc/refman/8.1/en/downgrading.html

Downgrade from MySQL 8.1 to MySQL 8.0 or earlier is not supported. The only supported alternative is to restore a backup taken before upgrading. It is therefore imperative that you back up your data before starting the upgrade process.

MySQL 8.0 is available in https://aur.archlinux.org/packages/mysql80

muflone commented on 2023-08-13 21:04 (UTC) (edited on 2023-08-13 21:08 (UTC) by muflone)

@bokic the PKGBUILDs must never change the user preferences, like the building processes, until there's a strong reason to do, like disabling some option which may cause issues

https://wiki.archlinux.org/title/Makepkg#Parallel_compilation

bokic commented on 2023-08-13 20:39 (UTC)

@muflone If set in makepkg.conf might fail to build some packages that do not support it. thus AFAIK is best to be per project setting.

muflone commented on 2023-08-13 14:27 (UTC)

@bokic

you have to configure this in your MAKEFLAGS in makepkg.conf

bokic commented on 2023-08-13 13:34 (UTC)

Can we build with make -j$(nproc) to use all cores?

zenochen commented on 2023-08-11 01:36 (UTC) (edited on 2023-08-27 08:07 (UTC) by zenochen)

this bug fixed in glibc 2.38-3, mysql cannot be started only in 2.38-2.

old post below: After updating to glibc 2.38, mysqld is no longer available, upgrade cautiously.

mysqld --initialize --user=mysql --basedir=/usr --datadir=/var/lib/mysql
2023-08-11T01:12:40.308126Z 0 [System] [MY-013169] [Server] /usr/bin/mysqld (mysqld 8.0.34) initializing of server in progress as process 405
2023-08-11T01:12:40Z UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=8bce192f80e0338fa73a2ba7266c4d76c054e30d
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000
/usr/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x42) [0x558c830b0e22]
/usr/bin/mysqld(print_fatal_signal(int)+0x3e7) [0x558c826e7887]
/usr/bin/mysqld(handle_fatal_signal+0x82) [0x558c826e7a12]
/usr/lib/libc.so.6(+0x3e710) [0x7fc6c803e710]
/usr/bin/mysqld(+0x90b14e) [0x558c823d514e]
/usr/bin/mysqld(delegates_init()+0x33) [0x558c82e6d793]
/usr/bin/mysqld(+0x9e9ab3) [0x558c824b3ab3]
/usr/bin/mysqld(mysqld_main(int, char**)+0x1d84) [0x558c824bc264]
/usr/lib/libc.so.6(+0x27cd0) [0x7fc6c8027cd0]
/usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7fc6c8027d8a]
/usr/bin/mysqld(_start+0x25) [0x558c8248e9d5]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

maybe this is the bug of glibc, it only can be reproduced in vps runs in proxmox virtual environment and also the glibc is 2.38, I tried the same version in esxi, but no problem.