[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 16-8-2012 5:31, Marco van de Voort wrote: 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. 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... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 16 August 2012 04:31, Marco van de Voort mar...@stack.nl 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 apps at all. FPC 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On Thu, 16 Aug 2012, 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 16 August 2012 08:50, Michael Van Canneyt mich...@freepascal.org wrote: The list is endless. So yes, dynamically loading is a good thing. Indeed. I much rather prefer dynamic linking. 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. Thank you someone understands. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Al 16/08/2012 9:50, En/na Michael Van Canneyt ha escrit: On Thu, 16 Aug 2012, 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. 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 -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Luca Olivetti said: 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. 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? Yes. The _dependency_ on the library is static. Not the library itself. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15-8-2012 13:49, Jonas Maebe wrote: On 15 Aug 2012, at 13:32, Graeme Geldenhuys wrote: On 15 August 2012 12:10, Jonas Maebe jonas.maebe-3rqwkoel1alvsukgzv2...@public.gmane.org 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. 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. In other words, you'd have to add the relevant -dev/-devel packages as dependencies in your .deb or .rpm package, right? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15-8-2012 15:59, Graeme Geldenhuys wrote: Hi, On 15 August 2012 14:39, Jonas Maebe jonas.maebe-3rqwkoel1alvsukgzv2...@public.gmane.org wrote: 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? I have no idea, which is why I also said in my first reply: 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. 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 mysql45...6 units; sorry that I don't know how things are handled there; I've stayed away from them as much as possible... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15-8-2012 16:19, Michael Van Canneyt wrote: On Wed, 15 Aug 2012, Reinier Olislagers wrote: On 15-8-2012 15:59, Graeme Geldenhuys wrote: 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. 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. That has nothing to do with dyn versus static linking. 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. 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. As far as FB is concerned, that might indeed very well be true. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 15:32, Reinier Olislagers reinierolislag...@gmail.com 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On Wed, 15 Aug 2012, Graeme Geldenhuys wrote: Hi, On 15 August 2012 15:32, Reinier Olislagers reinierolislag...@gmail.com 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 Aug 2012, at 17:19, Michael Van Canneyt wrote: On Wed, 15 Aug 2012, Graeme Geldenhuys wrote: 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. 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___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said:
Hi,
On 15 August 2012 15:32, Reinier Olislagers reinierolislag...@gmail.com
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.
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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Am 15.08.2012 17:02 schrieb Graeme Geldenhuys graemeg.li...@gmail.com: 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi,
On 15 August 2012 19:02, Marco van de Voort mar...@stack.nl 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.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 August 2012 21:53, Sven Barth pascaldra...@googlemail.com 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? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 August 2012 22:10, Marco van de Voort mar...@stack.nl 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. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said: 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 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. * 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. 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? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
