[patch_done] Need libmysqlclient.so.18 for mysql5.5 linux

[ism]

Not connect in Linux with this but libmysqlclient.so.18 present in system
none of dynamic libraries can be found libmysqlclient.so.16 libmysqlclient.so.15 libmysqlclient.so

[EgonHugeist]

ism,

Did you use the new TZConnection.LibraryLocation property?

example:
TZConnection.LibraryLocation := 'libmysqlclient.so.18'; Or
TZConnection.LibraryLocation := 'C:\MyApp\libmysqlclient.so.18';

We've now a dynamic location for the Driver-Dll's.

The reason, why i added this feature was just like your post here... Also the SQLite 64 Bit dll's have different names. So it was slightly time to do this job.

Michael

[ism]

Did you use the new TZConnection.LibraryLocation property?

No , but will have :)

Maybe search libraries with mask libmysqlclient.so*

[EgonHugeist]

are such filenames like "libmysqlclient.so*" valid in linux?

If yes then this job is done quickly otherwise i've to say NO.

Let me explain:

the new TZConnection.LibraryLocation property supports now different Libraries for different Connections. The Project-Manager and me had a short discussion concerning this support. He told me: What if you've two servers installed and want to access the old one with the old dll and the new server doesn't support the old dll? Or just reverted?

Now you can have different TZConnections with different dll's and you can easiely upgrade your old database with Zeos7. Just use ZConnectionOld.LibraryLocation := 'old.dll' and ZConnectionNew.LibraryLocation := 'new.dll'.

We've still the standart *_DLL_LOCATIONS in our sources but your proposal can make trouble if such a case is present. Do you understand me?

Michael

[ism]

Good , Then only thing left, add in message hint about LibraryLocation

none of dynamic libraries can be found ... Use LibraryLocation

Thanks for the explanation, I not previously used LibraryLocation

[ism]

Ups with TZConnection.LibraryLocation := '/usr/lib64/libmysqlclient.so.18.0.0' in linux 64
program crushed with Access violation

External: SIGSEGV

in

function TZMySQLDriver.GetPlainDriver(const Url: TZURL;
const InitDriver: Boolean = True): IZPlainDriver;
begin
// added by tohenk, 2009-10-11
// before PlainDriver is initialized, we can perform pre-library loading
// requirement check here, e.g. Embedded server argument params
Result := inherited GetPlainDriver(URL, False);
(Result as IZMySQLPlainDriver).SetDriverOptions(Url.Properties); <-------
// end added by tohenk, 2009-10-11
Result.Initialize(Url.LibLocation);
end;

[ism]

Second problem
ZConnection1.PreprepareSQL not save in design time in lazarus , always false

[EgonHugeist]

Hmm curious.

Implemented some samll fixes. Rev. 1251
I like your Exception change!. So everybody knows about it!

Problem present?

[ism]

TZConnection.LibraryLocation := '/usr/lib64/libmysqlclient.so.18.0.0' in linux 64
now

Code: Select all

Can''t receive Plaindriver!

in
function TZMySQLDriver.GetPlainDriver(const Url: TZURL;
const InitDriver: Boolean = True): IZPlainDriver;
begin
// added by tohenk, 2009-10-11
// before PlainDriver is initialized, we can perform pre-library loading
// requirement check here, e.g. Embedded server argument params
Result := inherited GetPlainDriver(URL, False);
if Assigned(Result) then
begin
if Url.Properties.Count >0 then
(Result as IZMySQLPlainDriver).SetDriverOptions(Url.Properties);
// end added by tohenk, 2009-10-11
Result.Initialize(Url.LibLocation);
end
else
raise Exception.Create('Can''t receive Plaindriver!'); <-------
end;

ZConnection1.PreprepareSQL
no effect

rev 1251

i reinstall zeos

[EgonHugeist]

No i got it rev 1252...

[ism]

TZConnection.LibraryLocation := '/usr/lib64/libmysqlclient.so.18.0.0' in linux 64
All working good !

ZConnection1.PreprepareSQL
no effect, not save , always false

rev 1252

[EgonHugeist]

ism,

bug found, patch done.

Michael

[marcov]

are such filenames like "libmysqlclient.so*" valid in linux?

The story about unix library naming is this:

1. Different versions of libmysqlclient are number libmysqlclient.so.x (some packages have more complex version numbers)
2. For development people there is a symlink from libmysqlclient.so to the default one for (new) development.
3. When a package is linked, they _LINK_ against libmysqlclient.so, but the binary get a dependency on the exact number (libmysqlclient.so.x)
4. This binary will also run when the symlink is not there, and if other (newer) libs have been installed.
5. Under linux, the creation of this symlink is often done by the so called "-dev" package. Not the core package, but the development package.

But this is for static-dynamic (non loadlibrary .so) linking obviously.

This is where a loadlibrary approach brings pain, you need to keep track of these, and select the version that you want, while by static-dynamic linking the name of the lib it was linked against is added to the binary.

[EgonHugeist]

marcov,

you're right here. But the reason for the LibrayLocation 'em selves was another one.

Example:
We've to start from the premise we've got two libmysql.dll's in different versions. The newer one is not compatible to the old server-files. Both files exist in different directories. Now you can write easiely an update application with Zeos. Just use two TZConnections with different LibraryLocations. Before i did this patch, Zeos was only able to use one library and Zeos used always only the first which was found. That behavior is changed completely.

IF that is brings up lead of pain, then this is not the problem of Zeos, Marco. That's the task of the Developer to handle this correct. On the other hand we had a lot of users which asked for that feature.

All standart library names are still available and will be linked to the application exe file, like it was before. That part is not changed, Marco.

Michael

[marcov]

you're right here.

First, I was just trying to explain what happens on *nix.

Second, there is no right or wrong way. But any way where you have to explain users several times a day where to fill in what is not optimal.

But the reason for the LibrayLocation 'em selves was another one.

Example:
We've to start from the premise we've got two libmysql.dll's in different versions. The newer one is not compatible to the old server-files. Both files exist in different directories. Now you can write easiely an update application with Zeos. Just use two TZConnections with different LibraryLocations. Before i did this patch, Zeos was only able to use one library and Zeos used always only the first which was found. That behavior is changed completely.

True, but this means you will just change the "do it this way" on Windows to a "do it this way" on Linux.

IF that is brings up lead of pain, then this is not the problem of Zeos,
...

That's the task of the Developer to handle this correct.

If so, why didn't you simply make Windows users rename mysql DLL versions to include a version number? You can also see that is "the task of the developer".

This way you are creating a deployment problem on Linux, where a Zeos developer will have to instruct all his users to adapt their installation in a non-standard way.

Maybe give up the one size fits all?