I upgraded my laptop to Fedora Core 12, which has MySQL 5.1.42 installed. I have installed the latest Lazarus RPM, which is 0.9.28.2 and FPC 2.2.4. My Lazarus App won't connect to the server. I have the libmysqlclient.so.16.0.0 installed. I am not sure where to get the libmysqlclient.so.15.0.0. What are my options? Please do not recommend Zeos, On my installation I have never seen it compile correctly and if I have trouble a newbie would definitly have problems.

since you're on linux, what's wrong with going into the dir where your libmysqlclient is and creating a link pointing to it for the 15 version you need? ;)

Where does ".15.0.0" come from in this discussion? It is a filename that seems to have fallen from the air, connecting to nothing ?

I presume it comes from here (in mysql.inc):

  const
    mysqllib = 'libmysqlclient.'+sharedsuffix;
  {$IF DEFINED(mysql50)}
    mysqlvlib = mysqllib+'.15';
  {$ELSEIF DEFINED(mysql41)}
    mysqlvlib = mysqllib+'.14';
  {$ELSE}
    mysqlvlib = mysqllib+'.12';
  {$ENDIF}

This probably doesn't cover all the cases. Assuming that a specific client library can only talk to a specific server may also be wrong. Debian testing also has libmysqlclient 16 and mysql-server 5.1.

Henry

mysql version is a disaster (and one of the reasons why I avoid mysql when I can). IMHO FPC should never hardcode the number in the first place, but should link to mysqlclient.so (using the symlink, the unix way).

Anyway, long story short, FPC has a provision for such mistakes, -XLA

Try passing -XLAlibmysqlclient.so.15=libsqlclient.so.16 and pray.

I have tried this and it doesn't work.

How do I do this in Lazarus?

Terry A. Haimann wrote

I have tried this and it doesn't work.

in what way "it doesn't work"?? do you get an error or a complete failure with nothing indicating what went wrong?

FWIW: "it doesn't work" is pretty poor for an analysis to work from :P ;)

How do I do this in Lazarus?

Project / Project Options / Compiler / Other

[...] > Try passing -XLAlibmysqlclient.so.15=libsqlclient.so.16 and pray.

Mattias

Hi together!

I'm using MySQL 5.1 without problems on my Linux machine.

The problem is not mysqlvlib as also mysqllib is checked for. The problem is the version string returned by the API. This is checked for in fcl-db/src/sqldb/mysql/mysqlconn.inc/TConnectionName.DoInternalConnect.

Until 5 months ago this only checked for '5.0', but since then (thanks to Joost) it also checks for '5.1'. But I don't think that this is even part of the 2.4.0 release...

You can also view my issue about this topic here: http://mantis.freepascal.org/view.php?id=14587

Regards,
Sven

Marco van de Voort wrote

mysql version is a disaster (and one of the reasons why I avoid mysql when I can). IMHO FPC should never hardcode the number in the first place, but should link to mysqlclient.so (using the symlink, the unix way).

I agree completely, and there is already a way to check the client library version in the mysql api.

Henry

Sven Barth wrote

The problem is not mysqlvlib as also mysqllib is checked for. The problem is the version string returned by the API. This is checked for in fcl-db/src/sqldb/mysql/mysqlconn.inc/TConnectionName.DoInternalConnect.

This is good to know, but the issue was that the compiler was trying to link against a version of a library that didn't exist on the system.

Henry

P.S. Your email client strips the references header, breaking threaded view, or perhaps you didn't reply to my message, but composed a new one?

Hi again!

As far as I see it, it tries to load two libaries dynamically: libmysqlclient.so.15 at first and libmysqlclient.so as fallback. On my system (ArchLinux) libmysqlclient.so is a symlink to the current version (.16), so the application is able to load it. Other systems (like Ubuntu and Co.) might ommit this symlink as it is only included with development packages. May be libmysqlclient.so.16 should be added as a SECOND accepted library version inside the mysql50 define in mysql.inc (and also in InitialiseMysql).

That is a known, expected and disturbing issue ^^. I check this mail account very seldom and so I'm using Digest Mode to not reach the memory limit (10MB) that fast. Also I'm prefering the web view on freepascal.org, so that I don't rely on a certain PC to read the messages (I'm using three: work, home, UMPC). Thus replying is a bit... well... thread breaking. If you have a good solution for this problem (modifying headers?), I'd love to read it :)

Regards,
Sven

2010/3/2 Marco van de Voort :

Anyway, long story short, FPC has a provision for such mistakes, -XLA Try passing -XLAlibmysqlclient.so.15=libsqlclient.so.16 and pray.

Isn't this only useful for dynamic linking at compile time, not for dynamic loading at run time?

Vincent

But what if they're dynamically loaded? Most users won't have the libname.so symlink installed.

Henry

Sven Barth wrote

As far as I see it, it tries to load two libaries dynamically: libmysqlclient.so.15 at first and libmysqlclient.so as fallback. On my system (ArchLinux) libmysqlclient.so is a symlink to the current version (.16), so the application is able to load it. Other systems (like Ubuntu and Co.) might ommit this symlink as it is only included with development packages. May be libmysqlclient.so.16 should be added as a SECOND accepted library version inside the mysql50 define in mysql.inc (and also in InitialiseMysql).

Yes, the development package must be installed for the .so symlink to be created. This is o.k. for developers, but doesn't particularly help users. The .16 library needs to be added to the list, you're right, but .15 must also be there.

I thought you might be using digest mode, but it's also stripping the reference. I don't think there's much you can do about it, either way.

Henry

That's impossible for MySQL.

Because, for example, an 'integer' field in version .13 can have the id 1, but for version .14 the id 1 can be used for a 'varchar'.

There is no way to know what the field-type of a column is, if you don't take the MySQL version into account.

To avoid these kind of problems most distributions come with more version of the mysql-client libraries, which they call .15, .16 etc. So fpc first tries to find the right client-version (using the .15 suffix) and then the general one.

Why MySQL 5.1. doesn't works is because as an extra check it checks if the version number is the number it expects. That check doesn't search for mysql 5.1 for older versions of fpc. (including 2.4.0)

Anyway, long story short, FPC has a provision for such mistakes, -XLA Try passing -XLAlibmysqlclient.so.15=libsqlclient.so.16 and pray.

Doesn't work. The version check will fail.

Bottom-line: don't use MySQL. And do not upgrade your MySQL-client library version.

Joost.

Joost van der Sluis wrote

Bottom-line: don't use MySQL. And do not upgrade your MySQL-client library version.

Currently i don't use client server client server i would prefer Firebird given other experiences. But the problem is that most web host companies only offer MySQL. Very few offer Firebird.

Luiz

IMHO that should be dealt with by a application specific configuration system, and left to the programmer.

It is not something that IMHO the libs should try to decide for everybody.