Hi,

This issue has come up before in a fcl-db discussion regarding the Firebird Database, where the libfbclient.so was missing from many Linux distros (eg: Ubuntu 10.04), but a libfbclient.so.2.0 was available instead. FCL-DB only checks for the unversioned shared libraries, thus your application will probably not run out of the box.

I've stumbled across this problem again today with OpenSUSE 12.1 and Synapse where I send emails from inside my applications via a secure SMTP connection. The Synapse library is looking for libssl.so, but by default OpenSUSE only has libssl.so.1.0.0.

In both these cases, I manually created unversioned symlinks to those libraries, and that got my applications working again. This is not ideal, but I don't know how else to handle this.

Does any body know what is the "most correct" way of handling this? Am I supposed to modify my copies of fcl-db and synapse to look for specific versions of these shared libraries, or should I somehow add a function in my application installation that checks in unversioned shared libraries exist, and if not, try and create those (which would require root access - and might cause problems an client installs).

Anybody know of any Linux documentation URL that explain when unversioned shared libraries are used and when not, and how applications are supposed to handle this?

But creating correct symlinks IS one of the tasks of a system administrator... His up to know the distro he is using and the software he wants to install.

I bet a "in the field" sysadmin will be much more flexible than a hardcoded implementation that would need to take zillions of obscure distros in consideration from the limited perspective of compile time...

2012/8/15 Graeme Geldenhuys :

The official way to get the unversioned symbolic links is to install the -dev or -devel package for that library. Of course, you're not supposed to require end-users to do that.

Does any body know what is the "most correct" way of handling this?

Determine which major version of the library you require (e.g. 1.x, or 2.x, or even something like 5.1.x if the library in question only supports API compatibility across minor releases), and explicitly load that one. That is also how it works when linking against a library at compile time: the unversioned name is simply a symbolic link to a versioned file name, and it's that versioned file name that the linker will hardcode in your application. The reasoning is that your application was written and tested against that version of the library, so letting it use arbitrary other versions is not a good idea.

If you can work with multiple major versions, you can try to dynamically load them all until you have found one that exists. At least most (if not all) FCL units that dynamically load libraries have a function that you can call to explicitly specify the name of the dynamic library to use. Since the units themselves have presumably been written to work with certain versions of those libraries, it would however probably be best if that code were directly added to those units (and to remove any *default* dynamic loading of unversioned file names, since such libraries usually only exist on a developer's machine -- except maybe on non-Unix platforms).

Jonas

Quite a long way from ideal, since it implies that an administrator has to be involved even if the program is only sitting in an unprivileged user's home directory (or is a symlink in ~ good enough?).

I'm tempted to say that this is a distro issue, and that if an upstream project (FireBird, OpenSSL, PostgreSQL) normally publishes an unversioned library that a distro is at fault if it "decorates" it with an appended version number without providing a symlink chain.

I'd suggest that the best solution would be for FPC policy to mandate that all shared library (.so etc.) usage in the RTL/FCL/LCL should be capable of taking a library name parameter, and for application code to allow this name to be specified in a .ini file. I think this would be safer than having the app try to deduce the location of the appropriate file, since sooner or later there will be a case where it sees multiple versions and selects the wrong one, or assumes that e.g. /usr/local/opt is permanently available when in fact it's a short-term NFS mount.

And doing it that way means that the user would be aware of the problem, and if enough users are aware of the problem it might trickle through to the awareness of the distreaux maintainers.

Hi,

Jonas Maebe wrote

The official way to get the unversioned symbolic links is to install the -dev or -devel package for that library. Of course, you're not supposed to require end-users to do that.

Yes, I know that bit, but even as a developer, if I don't do actual Firebird or OpenSSL development (I don't work on those project, I simply use there libraries), I don't need to install those libraries. That is why my Ubuntu and OpenSUSE system didn't have the -devel packages for them installed. FCL-db and Synapse dynamically load those libraries on my development machines, so no -devel package requirement.

... that the linker will hardcode in your application. The reasoning is that your application was written and tested against that version of the library, so letting it use arbitrary other versions is not a good idea.

In a way I understand the reasoning for the unversioned symlink, I just don't know how best to handle it in my apps. I also don't know the rules as to which version the unversioned symlib will normally point to.I know my apps work with Firebird 2.1 and Firebird 2.5, so should I then change fcl-db to look for libfbclient.so.2 or libfbclient.so.2.0 - instead of the unversioned default. Because the unversioned default could very easily point to a v1.x library of Firebird, and that would be untested with my app (it will probably not work).

If you can work with multiple major versions, you can try to dynamically load them all until you have found one that exists.

OK, I'll take a look at this idea. That seems better, because then I know I am trying to load library versions my app is known to work with.

I'm not so much concerned about my development system (I can fix that)
- I am thinking more in line of when I deploy my apps. I want them to obviously work as easily as possible.

Does not always work, e.g. in the case of Debian. -dev will install the .h and .a files, but won't necessarily set up unversioned symlinks.

Anybody: what's the position with Ubuntu, as the leading Debian derivative?

Hi,

Mark Morgan Lloyd wrote

Quite a long way from ideal, since it implies that an administrator has to be involved even if the program is only sitting in an unprivileged user's home directory (or is a symlink in ~ good enough?).

Correct, definitely not ideal. I was just thinking about the $HOME directory. I'll try and play with that now, and see what happens to my apps. Maybe my apps should all have startup scripts that define local LD_LIBRARY_PATH options?

I'm tempted to say that this is a distro issue, and that if an upstream project (FireBird, OpenSSL, PostgreSQL) normally publishes an unversioned library that a distro is at fault if it "decorates" it with an appended version number without providing a symlink chain.

They explicitly mention that general runtime libraries should not include the unversioned symlink. Only the -devel packages should include those. That makes me think, why do we then need the unversioned symlink in the first place!

Fedora:
http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

OpenSUSE:
http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Unversioned_packages

Ubuntu/Debian:
?? I can't remember the URL now.

I've never found a -dev package that doesn't set up symlinks in many years of using Debian for development. (Except if only static versions of a specific library exists, obviously). Could you give an example?

Henry

The dev/devel packages are not for people working on those libraries, they are for building programs that use those libraries. It's developers that do work on those packages themselves that don't necessarily need those packages, since they can just use their own source code.

That is why my Ubuntu and OpenSUSE system didn't have the -devel packages for them installed. FCL-db and Synapse dynamically load those libraries on my development machines, so no -devel package requirement.

You said that you manually created the symbolic link. I simply explained that you should never do that, and instead install the development packages because they will do that (correctly) for you. Whether or not it is desirable for the FCL/Synapse units to require an unversioned symlink to be present is a separate issue.

It will point to the library of the version corresponding to the dev/devel package that has been installed.

I know my apps work with Firebird 2.1 and Firebird 2.5, so should I then change fcl-db to look for libfbclient.so.2 or libfbclient.so.2.0 - instead of the unversioned default.

libfbclient.so.2.0 means Firebird 2.0.x. libfbclient.so.2 means Firebird 2.x. If you only support 2.1 and 2.5, you should link against libfbclient.so.2 and then call a function to get the actual version. If the library does not contain such a function, then there is simply no way to dynamically load that library and use it in a safe way in your scenario.

Jonas

[Checks a couple of systems] I can't be /absolutely/ certain without building a system from clean, but the thing that regularly bites me is the PostgreSQL client library and I've recently been bitten by libcap2.

However, I suspect that in both cases I might have set up a symlink myself and later installed the -dev package, I don't have an easy way of reconciling usage of ln -s (logged in root's .bash_history) with the date a package was installed (which I log into RCS). So I might have to recant, or to deprecate my testimony as unreliable :-)

I do agree with Graeme's position though: a -dev is described as containing files for developers, and it should not be necessary for a non-developer user to start encumbering his system with .h files etc. What's more, part of the reason that I've had to create symlinks manually in the past is because things like (if I recall correctly) OpenOffice's interface to PostgreSQL require libpq.so without declaring -dev as a prerequisite... which rather reinforces my position that this is a distro issue even if they prefer to disclaim it.

In other words, you'd have to add the relevant -dev/-devel packages as dependencies in your .deb or .rpm package, right?

Hi,

Jonas Maebe wrote

You said that you manually created the symbolic link. I simply explained that you should never do that, and instead install the development packages because they will do that (correctly) for you.

So my applications that I deploy to clients will now require -devel packages? This just doesn't sound sane, sorry. Maybe there is just a fundamental flaw in all distros and how they package software. Initially a great idea (in theory), but in reality it is seriously flawed.

Whether or not it is desirable for the FCL/Synapse units to require an unversioned symlink to be present is a separate issue.

FCL-DB uses dynamic linking by default, and looks for the unversioned shared library. So what specific Firebird version is the FCL-DB coded too? Because remember, libfbclient.so can point to a v1.x or a v2.x - depending on what -devel package was installed.

This uncertain (version mismatch) is what I would like to avoid, plus the fact that my clients now need to install -devel packages too.

Maybe I should simply install my apps into /home/<user>/<appname>. My installer would then ship the required/expected *.so files, and setup the unversioned symlink. My app would then be launched via a script which sets the LD_LIBRARY_PATH to the application directory. My app would then be totally self-contained. This seems like the only way to get around these flawed package management rules and dependencies.

It will point to the library of the version corresponding to the dev/devel package that has been installed.

So one minute it could point to a v1.x library, and the next it could point to a v2.x library. This will surely break many apps that only look at the unversioned symlink.

libfbclient.so.2.0 means Firebird 2.0.x. libfbclient.so.2 means Firebird 2.x.

OK, thanks for that.

My apps are tiOPF based, and tiOPF uses the bare minimum functionality from each backend database server. Basically just the CRUD (create, read, update and delete) functions. So even though I say our apps use Firebird DB v2.x, it will most probably run on a v1.x system too, but like I said, that would be untested. We only test with v2.x Firebird servers.

I'd say that it's the OpenOffice interface that's broken. They shouldn't link to a library that doesn't specify a version. They need to link to a specific version by using the naming conventions as Jonas explained. This is to protect yourself from api/feature breakage. Linking directly to, e.g. libpq.so, is only o.k. if you can check the version by means of some api, which the library needs to supply in all the versions that exist - past, present and future. Which is probably what they're doing. This isn't very good practice, in my opinion, but can work.

If they really support multiple versions of libpq, then they will have to try to dynamically link against all the versions they support. This won't be much more effort than checking the version in the first place.

Even on Windows some libraries are using names that reflect the version, e.g. I link to some opencv libs, which are named
libopencv_{module}231.dll. I suspect this is much less of a problem in the Windows world, since library reuse isn't that common.

Henry

They always have required them until now (as have any other applications that use fcl-db).

This just doesn't sound sane, sorry. Maybe there is just a fundamental flaw in all distros and how they package software. Initially a great idea (in theory), but in reality it is seriously flawed.

It's the fcl-db/Synapse units that are flawed. As explained in my first reply, the unversioned symlink is only for use by the linker (ld), and they work perfectly well for that purpose.

I have no idea, which is why I also said in my first reply:

***
At least most (if not all) fcl units that dynamically load libraries have a function that you can call to explicitly specify the name of the dynamic library to use. Since the units themselves have presumably been written to work with certain versions of those libraries, it would however probably be best if that code were directly added to those units (and to remove any *default* dynamic loading of unversioned file names, since such libraries usually only exist on a developer's machine -- except maybe on non-Unix platforms). ***

While shipping all libraries yourself is an option, the package management rules and dependencies are not flawed (or at least the scenario you are describing currently does not point to a flaw in them). If you start shipping libraries yourself, you'd better make sure that you also ship all libraries they in turn depend on as well, because otherwise you're more likely to make the problem worse than solve it.

As mentioned in my previous replies, applications should never look at the unversioned link in the first place when dynamically loading a library.

Jonas

In our previous episode, Graeme Geldenhuys said:

(1) avoid _dyn versions.
(2) override the built-in naming by calling
ibase60dyn.initializeibase60('whatever.so');

before connection or other db parts initializes.

In our previous episode, Graeme Geldenhuys said:

No. It all works fine WITHIN a distribution (in a particular version). And basically that is the only supported way on Linux.

Anything crossdistribution and cross-distroversion is assumed to be on source level, not binary level (IOW rebuild your app). According to common linux philosophy distributing crossdistro binaries is asking for pain.

Basically if you link to a .so the normal way, to simplify build systems, a symlink from a generic name to a versioned name is used. But the generic binary contains a reference to the versioned name, and thus will work without symlink, which is why end-users systems don't have the link.

But this way of linking is more dependent on the exact version of the library, so in the past some people changed everything to dynamically loaded via dlload/dlsym.

This alleviates the versioning problem somewhat, but discards the only distribution provided way to fix this.

I still think that changing everything to _dyn created more problems than it solved. (except for special disaster case mysql maybe)

Hi,

Umm, so ideally the ibconnection.pp unit should really be split into various units with version numbers in their names. That way we will know to which Firebird version they are referring too.

eg: ibconnection.pp // old interbase only (eg: Delphi 7) firebird-1.x.pp
firebird-2.1.pp
firebird-2.5.pp

Include files could probably be used to reduce some duplication of code.

As mentioned in my previous replies, applications should never look at the unversioned link in the first place when dynamically loading a library.

OK, for now I'll modify my fcl-db and synapse code to look for the versioned shared libraries that I know I have tested with. eg: libfbclient.so.2

Thanks for all the help guys.

OT: that would be useful for another reason.
Firebird 3 will introduce the BOOLEAN datatype and other innovations (encrypted connections, etc).
Interbase has had BOOLEAN support for a while now.

It would be nice to be able to support new functionality without sacrificing the ability to connect to older clients.

Of course, this has an obvious parallel to the mysql4....5...6 units; sorry that I don't know how things are handled there; I've stayed away from them as much as possible...

That has nothing to do with dyn versus static linking.

You can perfectly detect which library version you are loading, and enable/disable certain functions based on this.

Mysql is a different story in that the internals of the structures change with each release, making it almost impossible to unite all versions in 1 unit.

Firebird has a long tradition of keeping the API and structures backwards/forwards compatible, thus obliviating the need for different units for each version.

Conclusion:
At least for firebird, there will be 1 unit, loading dynamically what is available. If you want to load something else than the default, you have been able to do so since day 1.

Contrary to Marco's belief, I am firmly convinced that this is the best and easiest approach.

Michael.

Yes, that's why I mentioned it's OT ;)

You can perfectly detect which library version you are loading, and enable/disable certain functions based on this.

Ok.
And you can use the (Firebird/Interbase Services IIRC) API to get the server version. I seem to remember Ludo's recent addition to FPC has this functionality.

Firebird has a long tradition of keeping the API and structures backwards/forwards compatible, thus obliviating the need for different units for each version.

Yep.

As far as FB is concerned, that might indeed very well be true.

Thanks,
Reinier

Hi,

Reinier Olislagers wrote

And you can use the (Firebird/Interbase Services IIRC) API to get the server version. I seem to remember Ludo's recent addition to FPC has this functionality.

Yes, but you are jumping the gun here! My problem is that I can't even start my app, because the libfbclient.so is missing in every distro I tried. Linux distros (on client PC's at least), do not include the -devel packages by default, so they only have the versioned shared libraries setup.

I had a quick look to see what other (non FPC based) application do. FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so library). That's why it works without having to install the -devel package.

So why does FCL-DB look at the unversioned *.so by default? Wouldn't it make more sense to change FCL-DB to look for libfbclient.so.2 instead? 2 being the latest major version of Firebird DB, and that is also the latest version that ibconnection.pp was written for.

It makes sense.

Michael.

FWIW, on Mac OS X Firebird only ships a libfbclient.dylib (no libfbclient.2.dylib -- on Mac OS X, the version number is placed before the shared library extension rather than after it). The reason is probably the library is not shipped with Mac OS X by default, so you have to embed the library/framework into your application bundle anyway and then you know which version you use).

Jonas

Completely agreed.

The default library file can be overrided but this is all but self explaining (and barely documented AFAIK):
- firebird: uses ibase60dyn; ... InitialiseIBase60('libraryname');
- postgres: uses postgres3dyn; ... InitialisePostgres3('libraryname');
- mysql5.1: uses mysql51dyn; ... InitialiseMysql('libraryname'); It can only be done at run-time, so no way to activate any connections in the OI.

A libraryfilename property for the different sqldb components would be nice.

Ludo

No, this would suggest that you can set a different value for each instance.

I think a settings dialog in the component editor (from the form designer) would be better. Or a settings dialog under 'Tools'.

Patches welcome :-)

Michael.

No, this would suggest that you can set a different value for each instance.

I don't see what is wrong with that. You get a nice exception when you try to load a different library than the one that is alread loaded. But if I want to make an app that works with embedded firebird or firebird client (user selectable at any time) that have completely different settings (user, password, database, etc), what is I wrong with creating 2 instances in the OI and connect only one at the time? You can't be connected the 2 at the same time but that is a run-time issue, not design time.

I think a settings dialog in the component editor (from the form designer) would be better. Or a settings dialog under 'Tools'.

Where would you store the value(s) then so that
1) it can be streamed
2) the instances can pick up the value (instances decide whether connection is active or not. Current implementation will load library when the first connection becomes active)
3) when using multiple db backends (FB + postgres for example) the instances pick up the correct library

Patches welcome :-)

ROFLMAO

No comment.

Ludo

IMHO that would be a total waste:
Since you'll have to store username/password/db file anyway in some form of user settings, you might as well store the library name as well.

It so happens that I have an application in production that does all this.

It only requires a restart in case you choose another library.

You can't be connected the 2 at the same time but that is a run-time issue, not design time.

Because only 1 library can be loaded for each type of connection: the entry points are global.

What you suggest implicates keeping a reference count, unloading, and then reloading.

Ivo Steinmann tried implementing that once, and all his efforts were undone because it gave too much problems (specially the unloading if I recall correctly).

It does not need to be streamed, I imagined an IDE setting only.

You pointed out that one cannot set the library for the IDE;
I merely point out a solution for that.

The library name to use - per type of connection - can be stored in the IDE settings.

2) the instances can pick up the value (instances decide whether connection is active or not. Current implementation will load library when the first connection becomes active)

But does not unload correctly.

3) when using multiple db backends (FB + postgres for example) the instances pick up the correct library

The setting is for the IDE only: One setting per type of backend.

I do not think a solution is required for the components. Yes, you cannot set the location in the OI, but I do not think this is needed in the first place, see the use case at the beginning.

Michael.

Ludo Brands wrote

You can't be connected the 2 at the same time but that is a run-time issue, not design time.

I'm not sure I'm following. Do you mean SqlDB can't connect to two different database at the same time? I can't think that is true, so could you explain this limitation you are talking about.

For example, in tiOPF I often connect to multiple databases - migrating data from one database to another.

Wasn't that what I suggested, a libraryfilename property for the connection component? Next to username/password/db.

That is why I said it is a runtime issue, not a design time issue.

What you are saying is that all the code in for example ibase60.inc, where ReleaseIBase60 calls UnloadLibrary when RefCount=0 is all unused? The debugger says the contrary. ReleaseIBase60 is called from TIBConnection.DoInternalDisconnect.

Ah, that is not what I meant. Since Graeme's comments were mainly about rolling out applications on customer machines I didn't explicitly repeat that point.

You pointed out that one cannot set the library for the IDE; I merely point out a solution for that.

Set the library -from- the IDE, ie. the Object Inspector.

The library name to use - per type of connection - can be stored in the IDE settings.

I really don't see the use for such a setting on the IDE level. On the project level it could be useful.

I do not think a solution is required for the components. Yes, you cannot set the location in the OI, but I do not think this is needed in the first place, see the use case at the beginning.

We differ there. If it was easier to set the library file name we probably wouldn't have all these discussions on client not found or wrong client (embedded or not) loaded.

Ludo.

In our previous episode, Graeme Geldenhuys said:

Did you try ibase60dyn.initializeibase60('whatever.so'); in your dpr ? I noticed you didn't react to that suggestion (and a similar suggestion from Jonas)

Since 2.4.2 afaik most db routines have such routines, though I haven't seen them tested much.

The main reason is exactly discussions like this popping up every half year about library naming purposes, adding embedded or odd ball versions and so on.

In our previous episode, Michael Van Canneyt said:

I might be wrong, but if Zeos behaviour is any comparison, I think this is all used designtime too?

On a development system one can assume that the libfbclient symlink is there, and that is about the only certain point in this whole mess.

Note that currently also multiple names are tested for some client libs. (e.g. fbembedded). That functionality should persist.

And contrary to user apps with the most likely _current_ name, inserting a call on startup is much more annoying for Lazarus

And IMHO this all reeks of that. (dll name in component). Sounds "easy", but it doesn't really solve anything.

2 instances of the same database connections (ibconnection for example) using different librairies. For example having one connection that uses the FB embedded library and another that uses the FB client client library. That is not working. The connection library is global for all instances using the same ConnectionClass.

Ludo

"Graeme Geldenhuys" wrote

I had a quick look to see what other (non FPC based) application do. FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so library). That's why it works without having to install the -devel package.

Did you look at the source/makefile or the binary? If the latter then this is exactly what FPC (or more precisely the linker) does when you statically link to a shared library: the unversioned symlink is resolved and the versioned one is stored in the recuires section of the binary.

Regards,
Sven

In our previous episode, Graeme Geldenhuys said:

I had a quick look to see what other (non FPC based) application do. FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so library). That's why it works without having to install the -devel package.

Is that a cross-distro binary? Since that is exactly what you get when libraries wouldn't build with -dyn.

Blend perfectly with the distro they are build for, but if changes occur chances on recovery are slim.

Hi,

Marco van de Voort wrote

Did you try ibase60dyn.initializeibase60('whatever.so'); in your dpr ?

I'm sure I can add that, and I'm sure it will work for my Firebird connections, but other libraries I use don't have such functionality.

I'm trying to get to the bottom of....
* Why must developers jump through hoops to get there DB apps to work
* Why did FPC decide to use unversioned shared libraries under linux when they (fpc developers) clearly know than those -devel packages are not installed
as standard - thus making deployment of FPC+DB apps unnecessary complex.

Yes it's great that the Firebird dynamic linking unit supports passing in aditional library names, but why not simply use the correct name as standard. Other apps that talk to Firebird link to libfbclient.so.2 because that is the latest version of Firebird, and when you install the standard Firebird Client libraries, only the versioned ones are installed.

I also believe that the ibconnection.pp unit is coded for Firebird 2.1 and 2.5, so assuming the default shared library (libfbclient.so.2) is really not a great leap.

Sven Barth wrote

Did you look at the source/makefile or the binary? If the latter then this is exactly what FPC (or more precisely the linker) does when you statically link to a shared library

Yes, FlameRobin was statically linked. But that's beside the point. It works in FPC is you statically like your SqlDB+Firebird application (though I had a libfbclient.so symlink already), but it fails if you dynamically link that same app. Not to mention that SqlDB defaults to dynamically linked - something myself and others seem to prefer.

I just think ibconnection.pp should rather look at the versioned shared library, just like the linker does with static linking. Thus making applications easier to deploy. Is that too much to ask?

Marco van de Voort wrote

Blend perfectly with the distro they are build for, but if changes occur chances on recovery are slim.

Be more specific, what changes?

Dynamic linking and Static linking both have there pros and cons. Most seem to prefer dynamic linking, that is why it is the default in ibconnection.pp. Only problem at the moment in FPC is, with dynamic linking it is looking for an unversioned library instead of libfbclient.so.2 (the latest major version of Firebird DB). Making that simple change means apps that are dynamically linked can be just as easily deployed as apps with static linking.

In our previous episode, Graeme Geldenhuys said:

It's not a FPC problem, it is a linux problem that apps are not crossdistribution distributable. Creating a lot of drama if you see a minor discrepancy here 6 months after release won't benefit anyone.

Just like we had a similar drama discussions about adding fbembedded 9 months ago, we'll just rehash this charade in 9 months for some other library where a new version came out or where naming changed.

Because it is the _only_ fixed point in this whole mess. This sounds all very smart now, but once .2 will start changing you can explain people how to fix everything so that designtime components keep working. (and installing -dev won't help, manual intervention must be done)

Yes it's great that the Firebird dynamic linking unit supports passing in aditional library names, but why not simply use the correct name as standard. Other apps that talk to Firebird link to libfbclient.so.2

Which apps, do they dlload at all?

In our previous episode, Graeme Geldenhuys said:

> Blend perfectly with the distro they are build for, but if changes occur > chances on recovery are slim. Be more specific, what changes?

Change in naming, (either root (gds->fbclient) or version numbers) non standard directories (the $prefix/lib/mysql/ has been a problem in the past).

And always, always, we work with 6 months to an year latency. If we were finalizing 2.6.2 now, and a distro had already changed in some devel version, it will probably not make 2.6.2.

With a low FPC release frequency and distro packages that generally not fix this on their own, this is a lost battle.

And despite all assurances that this change is all pretty invariant, this discussion returns in some way or the other every 6-9 months as new developments occur.

(or, like in thise case, if somebody wants to be smart and turns the screws on status quo a bit tighter).

If dynamic linking is so great, why do we constant, constantly have these discussions and worse all these illadvised changes?

IMHO dynamic linking is a boon for a few people that want attempt crossdistro distribution, and a burden on everything else.

Dynamic linking and Static linking both have there pros and cons. Most seem to prefer dynamic linking, that is why it is the default in ibconnection.pp.

An "it is because it is" argument.

Fact is that we don't support the distribution recommended way.

Don't know what drama you refer to exactly (quick search through the archives on fbembed showed nothing relevant) but for the Windows side: fbembed.dll is a DLL distributed by the Firebird installer, just like fbclient.dll (and, if you go the masochistic route, if you check the box on installation, perhaps gds32.dll will also be installed).

I don't see how sqldb not searching for fbembed.dll by default and letting devs search for this manually in their program for every program makes things easier.

As for Linux: if libfbembed is distributed by the distro packages... well, yes, it might be a "drama" to add it to ibase60.inc, but doing things half way and leaving only libgds and libfbclient there will only confuse things more.
Is a change every say 9 months really such a big problem? Why not add an FPC FAQ entry (if it's not already there) stating these problems and decisions, and say that mainstream library names will be added after name changes, but indicate the delay you mentioned.

Either something like that or throw out the entire concept and force devs to specify library names in every program...

We differ only in the implementation of the 'easier way':

I meant that I do not see the advantage of writing something like

  With Inifile do
    begin
    IBConnection1.LibraryName:=ReadString('Connection','libraryName','fbclient.dll');
    end
over
   With IniFile do
     begin
     InitializeInterbase(ReadString('Connection','libraryName','fbclient.dll'));
     end;

Which is what you will end up writing in any real-world scenario. I have never seen a real project where the databasename set in the OI was the one actually used in the deployed app.

I cannot remember when I've last used the OI for setting the username/password/databasename for a connection.

That, combined with the fact that the library name is project wide, lead me to the conclusion that there is no need in a property at the connection level.

That said, if an easier way is needed to set the library name in the IDE, I'm all for it. I just don't think it should be a TSQLConnection property, for the reasons explained above.

Michael.

Hi,

Marco van de Voort wrote

It's not a FPC problem, it is a linux problem that apps are not crossdistribution distributable.

My applications ARE all cross-dirstro capable. And they are damn good at running on new and old distros. eg: I have compiled an fpGUI app 6 months ago on Ubuntu 10.04 (32-bit), and ran that app without problems on a 10 year old distro (SUSE 9.0). That should be good enough for most don't you think. Also says a lot about your "fear" regarding Linux library API/Naming/Versioning changes.

Creating a lot of drama if you see a minor discrepancy here 6 months after release won't benefit anyone.

Coming from someone that admitted that they don't release any commercial FPC based applications and only work with Delphi in commercial environment.... Excuse me if I take whatever you say with a large pinch of salt.

months ago, we'll just rehash this charade in 9 months for some other library where a new version came out or where naming changed.

Library naming seem to be the ONLY consistent thing here. From what I have seen, and what Jonas mentioned, there are well established rules for naming libraries and versioning. So it should be perfectly fine and cross-distro compatible to look for libfbclient.so.2 - which has been the latest Firebird major version for a few years now.

If Firebird 3.0 gets released, ibconnection.pp must be upgraded anyway, then the searched library name could be updated at the same time. There is no problem in this working.

Because it is the _only_ fixed point in this whole mess. This sounds all very smart now, but once .2 will start changing you can explain people how to fix everything so that designtime components keep working. (and

Once again very vague. What do you mean by changing.... a new v3 Firebird release? In that case libfbclient.so could just as easily point to the .3 library, and any applications which only support 2.x firebird might not work. As Michael stated, unlike other database vendors, Firebird is pretty good at keeping backward/forwards API compatibility, so in theory the v2.x firebird apps should work, but one never knows when it comes to major version number changes. Minor version number changes is a whole different game.

Anyway, why bother arguing with someone that doesn't distribute FPC based might only be a hobby to you, but for others it is there bread and butter. We need to support apps as best we can, and with that make them run as easily as possible on all supported platforms. This is what I am trying to do here.

Anyway, Michael van Canneyt seems to have agreed with my suggestion (if I understood his email correctly) of adding '.2' to the Linux-only library name. Michael is a lot more involved in FPC database work than you.

And IMHO this all reeks of that. (dll name in component). Sounds "easy", but it doesn't really solve anything.

Making it easier for the programmer to specify the library he wants will put a halt on "this discussion returning in some way or the other every 6-9 months". What is recurring in these discussions also is the non- or badly-documented ibase60dyn.initializeibase60('whatever.so'), or equivalent, being brought up at one stage as "the" solution that should make an end to the discussion. So if a libraryfilename property would only solve the recurring discussions and miscomprehensions (assuming that is a shared objective) then it would already be a big step forward.

Ludo

Hi,

Marco van de Voort wrote

Change in naming, (either root (gds->fbclient) or version numbers)

For God's sake!!! The gds -> fbclient was a once off deal after Interbase was released to the open-source world and shortly thereafter retracted that decision. The open source project continued (to Borlands detriment), but to differentiate their work from the commercial Interbase, they changed the library name. A once of deal - as if this happens even second day! F*cken ridiculous argument.

As for version numbers... Major version numbers also take long to change. How long has v2 been the major version number in Firebird, FPC, etc?

non standard directories (the $prefix/lib/mysql/ has been a problem in the past).

MYSQL is a mess, and my discussion about database libraries are limited to Firebird only, as that is the only database we use in commercial work. As for the location of 99.99% of libraries under Linux.... that is defined by the OS and normally falls under /usr/lib or /usr/lib64, and it has been like that since forever!

And always, always, we work with 6 months to an year latency. If we were finalizing 2.6.2 now, and a distro had already changed in some devel version, it will probably not make 2.6.2.

Yes, and if you know anything amount maintaining commercial software, you would know that NOBODY (in there right mind) would instantly jump onto a new major version library change. It will probably require some software update, lots of testing, new installs being generated, more testing etc... another 6+ months latency. So again you "fear" something that is not really an
Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net

Marco van de Voort wrote

If dynamic linking is so great, why do we constant, constantly have these discussions and worse all these illadvised changes?

Because the problem is not in dynamic versus static.

We would have exactly the same discussions if they were statically linked. Only it would be 'the app XYZ does not start, fails with library not found'. which would be a system message.

Now, when loading dynamically, it is an FPC-generated error.

But the actual problems that people experience would be 100% the same: a library not found.

At the same time, creating statically linked binaries, the developers would have more difficulties making an configurable application:

Creating an application where the connection type (remote/embedded) for firebird is somehow settable would require creating 2 binaries, since having the option in 1 binary would require both libraries be present on the system.

Having different sound backends on linux would require the same scenario.

The list is endless. So yes, dynamically loading is a good thing.

So, what is the problem, and what started the whole discussion: the FPC team (i.e. us) simply chose a poor default for the default library name in several cases.

That's all that needs to be changed to get rid of most of the problems and discussions.

Michael.

In our previous episode, Ludo Brands said:

It won't. More importantly, it cannot be ifdeffed easily.

In the case of using multiple dlls (and thus multiple addresses per function), how will you deal with the current procedural interface btw (based on global procvar's)?

Hi,

Michael Van Canneyt wrote

The list is endless. So yes, dynamically loading is a good thing.

Indeed. I much rather prefer dynamic linking.

Thank you someone understands.

I agree.

Unfortunately your example illustrates nicely the difference. InitializeInterbase is unknown in the fpc I'm using. InitialiseIBase60 does exist but you have to add the non-trivial ibase60dyn to the uses clause to get to it (Google has 146 hits for "InitialiseIBase60", non of the hits are documentation or wiki pages). If it where a property of TIBConnection, non of these difficulties would exist.

That is your usage case. The fact that username/password/databasename properties exist in all db components I know of seems to suggest that there are usage cases where it is used. I happen to use these properties frequently for writing quick'n dirty (RAD) test programs or mock-ups or during the development phase of a program. I hope that is still inside the supported use of fpc?

Made a quick tour of the other dbcomponents I have on my system: Zeos (TZConnection.LibraryLocation) , MDO (TMDODataBase.ClientLib), Delphi's DBExpress (TSQLConnection.VendorLib). They have all this useless component property to specify a project wide library. True, sqldb doesn't claim compatibility with anything, so that shouldn't be a reason to do the same as the others. But afaik the other components don't have the recurring discussions on libraries not found or wrong library loaded, etc.

Ludo

A valid point.

Remains the fact that I think that - no matter what the other component sets do
- the library name should NOT be a connection component property, unless you allow each connection to use a different library. Since that is not possible with the current *dyn units, the property should not be made at this level.

What is then the solution ?

If you look at AnyDac, you'll see that it is the only DB component set that IMHO does it correctly. It has a separate component for the library (the "physical link") of each type of connection.
You drop this component on the form and set the library name (it has a reasonable default). Only one such component is needed for the whole application, no matter how much connections you make..

Now, I happened to think that this may be a bit overkill, which is why I proposed a component editor popup to set the library, which can simply insert the correct statement in code.

But if people want a point-and-click interface, we can always make a new component: TSQLDBLibraryLoader or so.
With a property for the library name of each supported DB, so we need only 1 component.

Michael.

In our previous episode, Ludo Brands said:

Documentation is a different story.

Easy. Designtime packages must also be able to find it. (e.g. to query the database for fieldnames to make field selection in grids etc easier).

Made a quick tour of the other dbcomponents I have on my system: Zeos (TZConnection.LibraryLocation)

Zeos' dbconnection is not database dependent. The database dependency is provided by adapter interfaces that are separately registered. Schemes like this could make a database type (and version) possible by merely adding an unit which registers some new datatype.

This avoids a potential problem with sqldb (deleteing connection, adding new) forces you to reconnect all queries with the new connection. This can be monkeyed around with lfm editing, but that is not "nice".

This is all IIRC, it was some time ago. I think mysql users are more familiar with these problems :-)

MDO (TMDODataBase.ClientLib), Delphi's DBExpress (TSQLConnection.VendorLib). They have all this useless component property to specify a project wide library.

It might be because of the above designtime requirement. I don't know how much sqldb supports there.

I understand you prefer the perfect solution instead of the easy 3 line solution most others have implemented and that appear to work very well for them in 99% of the cases. I'm just afraid this quest for the perfect solution will make that in 6-9 months nothing has changed and this same discussion will pop up again.

Ludo

It is a different story but an integral part of this particular problem. Why else has the "solution" to be spelled out everytime the problem pops up? You'll say people don't make the effort to read old messages. But in this thread alone you'll find a "InitializeInterbase" and a "Did you try ibase60dyn.initializeibase60('whatever.so'); in your dpr ?" in messages from people that are supposed to be references. Both functions don't exist...

That is very similar to TSQLConnector in sqldb and exactly how the mssql connections were introduced, before TMSSQLConnection and TSybaseConnection were implemented.

Correct but I fail to see the relation to the subject at hand: the library being used.

Ludo

Al 16/08/2012 9:50, En/na Michael Van Canneyt ha escrit:

Static linking to me means the executable is self-contained and doesn't rely on any external libraries.
Maybe you mean "static" as in "the executable has the dynamic library name hardcoded and it will be automatically loaded by ld instead of dynloading it explicitly"?

Bye

Yes.

Michael.

Well, first of all, I don't think something needs to be changed in the first place :)

So, if we must do something extra anyway, then I prefer it to be the correct solution, and not a shortcut.

If we didn't go for the correct solution but for the 'easy' solution, we wouldn't have had TSQLTransaction either, but would have implemented transaction control in the connection component, which probably also covers 99% of cases...

And let's not forget: if we choose a reasonable default library name, 99% of all problems fall away by themselves, and the component will not be needed in the first place; Just for special cases will you need it.

Michael.

Michael Van Canneyt wrote

And let's not forget: if we choose a reasonable default library name, 99% of all problems fall away by themselves, and the component will not be needed in the first place; Just for special cases will you need it.

I did not follow the thread, but what about searching a filename 'otherlibrarynames.txt' and if this file is existing then the program looks into this file for other librarynames instead of the default names.

In our previous episode, Ludo Brands said:

That is the whole point of these discussions. They are heated and overfocus on some detail that is considered all inhibiting, and they compare detail problems of the current implementation with a future implementation that is perfect on paper. (and of course it never is).

If you want documentation, write documentation, don't discuss change requests.

If drastic changes (like postponing header initialization till larger parts of the LCL are in the air) must be made, I rather fix all issues.

Anyway, the crucial question still hasn't been answered, does sqldb/lazarus have designtime database connections like Delphi/zeos has?

In our previous episode, Luca Olivetti said:

Yes. The _dependency_ on the library is static. Not the library itself.

In our previous episode, Rainer Stratmann said:

If we would depend on customer configuration, we might as well have them create a symlink.

And that is how also this attempt to improve sqldb grinds to a halt ...

Ludo

Is anybody else receiving mailformed emails from the list?

I've received several, most or all from Marco, with all with most of the headers appearing as text since there is an extra blank line between the X-Mailer header and the previous ones.

Am Thursday 16 August 2012 14:53:05 schrieb

No Problems here with KMail (1.9.10 KDE 3.5)

In our previous episode, said:

If I look in the msgs that I get back from the list, I see no blank line.

My guess is that somewhere in the mailer path close to you (your client, your ISP or their uplink) this line is inserted. Maybe as part of some anti spam measure.

I'm probably the only person using ELM, so if that server reacts badly to (a) ELM generated headerline(s), then that will probably be the reason why it is only in mail from me.

I haven't had complaints before, and am using ELM since the early nineties :)

Why do you say that?

It's not because I personally think that no extra solution is needed, that I am oblivious to the problems of users.

We'll solve the problem, thereby improving sqldb.
I will implement it myself next week:

* Change default library names to make more sense.
* Implement library loader for cases where the default library name is not the correct one.

That the implementation is not how you would have done it, is a minor detail, I hope; The problem can and will be solved, that's the main thing.

Michael.

I don't see any problem in the message here, and any message that is even slightly suspect gets rejected by our gateway- I'll fix that sometime.

I note that the headers you quote include a few X- headers that I don't see here:

X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: X-Mailman-Version: 2.1.5 X-Virus-Scanned: ClamAV using ClamSMTP

I can't remember whether our gateway is explicitly rejecting those but in any event I think that repeated header is suspect. Is your ISP doing extra scanning, and messing things up?

Yes, it does.

Michael.

Is anybody else receiving mailformed emails from the list?

The only weirdness I get is Ludo's subject header. The subject of the first message in the thread was:

[fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?

One of Ludo's later messages gives me:

RE : RE : RE : RE : RE : [fpc-pascal] Re: linux:
shouldwehard-codeversionedorunversioned shared libraries in our apps?

In gmail's web client, the conversation view only shows the original subject at the top, but it's still visible in the header. When using icedove (thunderbird), it's pretty annoying, though. Anyone else having this problem? Is gmail screwing around with this somehow?

Henry

Who is heating the discussion now? I said that lack of documentation is _part_ of the problem with the current implementation and the solution is "write documentation"?

I have read the line 5 times but I don't understand what you are trying to say.

Anyway, the crucial question still hasn't been answered, does sqldb/lazarus have designtime database connections like Delphi/zeos has?

Yes it has
(http://wiki.freepascal.org/SQLdb_Package#Using_the_SQLdb_Package). There are some differences with Delphi/Zeos like the ability to preview query results or specify the library to be used but I won't overfocus on these details.

Ludo

Screenshot attached.

Henry

I see it, again with IceDove, and live with it provided that threading isn't messed up too badly.

More irritating is the very long lines that sometimes get inserted on behalf of some posters, which detracts from the legibility of their questions or opinions. I can't remember for certain, but I think that this was again a gmail issue.

In our previous episode, Michael Van Canneyt said:

Then changing the simple default to libfbclient.so.2 is a problem for designtime, since designtime code doesn't even have the emergency initializeibase60 workarounds as option. Lazarus will also start to look for .2.

Till now that dependency hasn't caused us grief because development systems generally have -dev or willing to install them.

Assume that at some point a distro decides to call it .2.1 or something, lazarus' designtime code will still link to .2, and people will have to make symlinks manually (installing -devel won't solve anything), which is uglier than it is now.

There are two solutions that I can think of quickly

1 somehow make the default libraryname different for designtime using some lazarus ifdef that checks for designtime (and keep designtime libxxx.so in general)

2 go with a configurable dllname property in the component

The component property has as disadvantage that you must have the same name as designtime and runtime.

A mix is also possible. Have defaults like it is now, or designtime and runtime differently, which will be used when the property is empty.

I'm glad to see I was mistaken in interpreting the way this discussion was going. Probably seen too many other discussions and initiatives that end up nowhere.

I only suggested the easiest and commonly used solution. You know I would have written the patch for it if that was needed. If your implementation is better in the overall sqldb scheme of things then so much the better;)

Ludo

Tatata. Don't sell the bearskin before the bear has been shot.

You can be glad when I actually commit the solution next week ;-)

Michael.

I'm still using a 10 year old Microsoft Outlook , french edition. Apparently it detects the "Re:" in the message, will not repeat it but makes a "RE:" out of it confusing other mailers. Result is an ever longer sequence of RE : RE : RE : RE : RE : I guess I'll need to look for an alternative mailer for mailing lists.

Ludo

Actually, you have 6-9 months ;)

Ludo

Well spotted. I don't know if zoho is using that or not. I usually turn off any AV if there is an option, I'll check again.

I can't remember whether our gateway is explicitly rejecting those but in any event I think that repeated header is suspect. Is your ISP doing extra scanning, and messing things up?

As much as I would like to be able to blame then, my ISP is off the hook this time (pun intended) because the problem is not appearing on my ISP email account, it's specific to this list and so far mostly or only from emails from Marco, I'll have to double check, and I do have other friends using Elm on this and other email accounts so I don't think that particular MUA is the problem either. Not sure what triggers it.

Thanks for the help and sorry to everyone for the off-topic post. If I am the only one seeing it I'll go from there.

Hi Michael,

I was about to create a patch for ibconnection.pp to add the '.2' part to the *nix (excluding Mac OSX - as per Jonas comment) library name. But from your message you seem to have other ideas too. So should I rather leave it up to you to fix the library name issue with other other modifications?

Hi,

I thought this is the FPC mailing list?? Lets not bring the Lazarus IDE limitations/usage into this discussion. Not everybody here uses Lazarus IDE, and definitely not the RAD-style dropping components on forms, and hard-coding field names into your GUI layer.

Assume that at some point a distro decides to call it .2.1 or something,

Please re-read Jona's earlier reply. There is a set naming standard for libraries in Linux (yes their does actually seem to be some standards that distros adhere too). I can confirm what Jonas said. I searched multiple Firebird client library *.rpm, *.debs and *.txz packages. Any Firefbird 2.x client library sets up the .2 and .2.m where m is the minor version number names. The one thing they DON'T do is the unversioned name - my issue with FPC, but which will luckily be fixed soon.

So using your example, there WILL be the following files.

libfbclient.so.2.1.5 <- the actual library file libfbclient.so.2.1 <- symlink to above (this does seem optional) libfbclient.so.2 <- symblink to above (always there)

The missing spaces where a topic some time ago already on one of the fpc or lazarus lists... I don't know what the outcome was though. AFAIK Graeme was the one who pointed it out that time.

Regards,
Sven

I wasn't necessarily saying that they were added en route to you, only that I think our code is dropping at least some. As a specific example, that X-Mailman-Version header must be originating at the list end.

Anybody: does any computer close to the list server use ClamAV?

Yes, agreed.

I should have been more specific. It looks to me there is a problem with my mail provider I use for this and other lists, but I only realized what it is after reading your post. The line break in inserted after their AV message. I don't know whether their AV is tripping over ClamAV or if it's some other error but it does seem to be in their AV code.

Since then I also received a mangled post from Ludo. So it's happening somewhat frequently and *seems* to be related to this list but may also be caused by reported the issue to them after your email since I have no option to turn off their virus scanning on my account with them.

Anybody: does any computer close to the list server use ClamAV?

Good question. Thanks again, Mark.

My plan (for linux) was:
Search fbclient.so
search fbclient.so.2 (2.x series of firebird)
search fbclient.so.1 (1.x series of Firebird)
if the library name has not been specified.

In case that is not ok for the developer, then she can specify anything she wants.

A separate isssue is the library loaded, but this is a different patch altogether.

If you provide a patch doing the above, go ahead, I'll gladly apply it.

If someone knows the correct version numbers for the various postgres and mysql libs, that would be appreciated.

Michael.

Michael Van Canneyt wrote

My plan (for linux) was: Search fbclient.so search fbclient.so.2 (2.x series of firebird) search fbclient.so.1 (1.x series of Firebird) if the library name has not been specified.

fbclient.so should not be searched. It could point to anything, including versions of the library not supported by the unit.

Jonas

@Michael
I have to agree with Jonas here. The unversioned symlink is potential trouble. Other than that, your solution sounds fine.

Hi,

Sven Barth wrote

The missing spaces where a topic some time ago already on one of the fpc or lazarus lists... I don't know what the outcome was though. AFAIK Graeme was the one who pointed it out that time.

I'm using Gmail (forced to plain/text) for years.... I do remember when using other mailers that I often saw the TAB character being inserted into the subject line. Gmail was hiding that fact as it only shows the top level subject. I think that was because the subject went over 65 characters, or something like that. I can't remember who was to blame for the inserting of TAB characters. One will have to check the message archives.

Potential trouble ? After we have been loading it for the past 10 years ? Let's not get carried away...

I will not add it, but only so you guys would sleep easier, not because I think there is any real danger involved :-)

Michael.

In our previous episode, Jonas Maebe said:

It should not be searched on the target system. Its definition on the host system is "the version of the library to use by default".

The database units shipped with FPC have been written against a particular version of the API, and hence should search for those specific library versions that are known to implement that version of the API. Target/host system does not enter the picture in this scenario. That difference is pretty much only relevant if you use the system's C headers because those will correspond to the library version pointed to by the unversioned symbolic link.

Jonas

If someone knows the correct version numbers for the various postgres and mysql libs, that would be appreciated.

libpq.so.3 pg 7.3 7.4
libpq.so.4 pg 8.0 8.1
libpq.so.5 pg >= 8.2.4

libmysqlclient.so.13 mysql 4.0
libmysqlclient.so.14 mysql 4.1
libmysqlclient.so.15 mysql 5.0
libmysqlclient.so.16 mysql 5.1
libmysqlclient.so.18 mysql 5.5

Ludo

Thank you very much. Just what I needed.

Michael.

Michael Van Canneyt wrote

Potential trouble ? After we have been loading it for the past 10 years ? Let's not get carried away...

I simply meant Firebird DB v3 has been in development for ages so could be released around the corner. It will be a major version change, so there is every chance that the API could change - though the Firebird project has been pretty good at not doing that. Anyway, at some point libfbclient.so could point to a v3 library, and all our apps are coded for a v2 library. That's all I meant. But thanks again for being understand.

Presumably the sqldb would be changed for the v3 library then?

Regardless, as mentioned, the Firebird services API allows you to find out what version a server is running.
You can apparently find out what client lib is loaded. Together, this info should be enough to modify sqldb to not issue unsupported calls (i.e. use only those supported by the lowest denominator). In other words: I'd rather build intelligence into the driver code about what should work or shouldn't work.

In any case apparently that hasn't been a big problem up to now with Interbase 6-whatever they've got now and
Firebird 1-2.5

Hi Reinier,

Reinier Olislagers wrote

Presumably the sqldb would be changed for the v3 library then?

Yes, but that will only be in Trunk, and could take up to a year before the next FPC "stable" release. I only deploy my commercial apps with stable FPC releases. In the mean time Linux distros get released about twice a year now. So distros will be ahead of FPC, and during that time libfbclient.so could be point at a version our software (and FPC) doesn't support. I hope that makes it clear now.

Regardless, as mentioned, the Firebird services API allows you to find out what version a server is running.

Yes, but as someone else also did the same thing as you. You are jumping the gun. You assume a database connection can be established. My problem was that the app can't even run because the libfbclient.so is missing in every standard Linux install, and that symlink is not included in the standard Firebird Client library package.

Anyway, I got the answer to my question, and the next FPC release will be fixed. Plus I now also know how to modify my copy of FPC 2.6.1 so our products can be deployed with ease.

It's been clear to me all along. That's the problem Marco was warning about. The alternatives have been discussed ad nauseam as well.

No, here you were not talking about library not found/db connection not established scenarios. Read your earlier posts above. Seen e.g.:

So a library (perhaps "including versions of the library not supported by the unit") would already be loaded.

Anyway, that is still irrelevant. The problem of various versions of FB clients and servers with different capabilities still needs to be addressed. The simple solution would be to just only support the latest version for both of them. Would that be enough? Who knows.

Personally, I don't really care anymore anyway. I'm just a hobby programmer anyway.
I'm sure Michael will do a good job with his db changes and I'll leave it to people like you who have production code running to submit patches.

Good luck,
Reinier

MSEgui searches for the *.so as last option. First the newest version it has been tested, then the older which are supported too, if none found the versionless.

Martin

So in near future we will add also fbclient.so.3 (for incomming Firebird
3) ?

BTW: packages/ibase is intended to be translation of Firebird client API not Interbase, right ?
(because I expect, that current Firebird API diverges from current Interbase API)

At least Firebird3 introduces BOOLEAN datatype, which will require update ibase60.inc when we will support them.
(so name "ibase" which evokes Interbase will be no more "precise")

-Laco.

I wrote a little VBA module in Outlook that modifies the RE: back to Re: before sending the message and that seems to solve the problem. Note that Outlook detects RE: and Re: correctly and will not duplicate them but other mailers seem to have problems with RE: and prepend a Re:. I have plenty of Re: RE: RE:... messages in my inbox.

Ludo

Ludo Brands wrote

I wrote a little VBA module in Outlook that modifies the RE: back to Re: before sending the message and that seems to solve the problem.

Almost. You now have an "Re :" in the front, and not a "Re:". Removing the space before the colon should fix it completely I think.

Notice:
I just switched from Gmail (web interface) to Gmail (via IMAP and Thunderbird). You are correct in what you said. Thunderbird is looks as specific text "Re:" and if it doesn't find it, it prefixes it, thus this message will show "Re: Re :".

Regards,
- Graeme -

Well spotted. Outlook indeed generates "RE :" with the additional space. This should be fixed now.

Ludo

Ludo Brands wrote

Well spotted. Outlook indeed generates "RE :" with the additional space. This should be fixed now.

Well done, it seems to work 100% now. :-)

Regards,
- Graeme -