Lazarus
Programming => Databases => Topic started by: 99Percent on September 20, 2011, 11:01:09 pm
-
I can run my Lazarus program fine in my development machine, but when I move my executable to another computer I get:
Can not load PostgreSQL client. Is it Installed? (libpq.so)
I have tried almost everything I can think of to get it working to no avail incluiding a copying the libpq.so file on the same directory, recreating the library directory structure the same as in my development computer (it is /usr/local/pgsql/lib vs /opt/PostgreSQL/9.1/lib), adding symlinks all over, adding the library path to the PATH environment variable.
pgadmin3 works fine on the target computer, so I am at my wits end. Please help.
-
So, where is your libpq.so ? Is your library in the LD_LIBRARY_PATH environment or listed in /etc/ld.so.conf?
-
Lazarus Postgre component depends on libpq. libpq depends on other libraries. Have not looked into the the required libraries for libpq 9.1 yet. If you figure them out I would be interested to know what they are.
If pgAdmin works then that suggests all the required libs are already installed somewhere.
-
So, where is your libpq.so ? Is your library in the LD_LIBRARY_PATH environment or listed in /etc/ld.so.conf?
echo $LD_LIBRARY_PATH returns nothing
my libpq.so is anywhere I want it, with the same result
if I add text file indicating the directory of the library files for /etc/ld.so.d is useless
-
debian x64
-
install libpq-dev
-
install libpq-dev
it will install 8.4 no matter?
-
I installed libpq-dev anyway and that did the trick. I would like to know what the hell it fixed though, because obviously this is not the right way.
-
Hi,
Is SQLdb compatible with PG 64 on 64 platform?
Thx.
-
Hi,
Is SQLdb compatible with PG 64 on 64 platform?
Thx.
yes, it works fine
-
Really? :o thank you guy.
After this news, I'll retire the Zeos.
Thanks again.
-
That is good, I never liked Zeos, its just too big.
Hopefully soon someone will make a direct TPQConnection that doesn't require libpq.so or libpq.dll
-
Maybe there should be a light database package.
-
I installed libpq-dev anyway and that did the trick. I would like to know what the hell it fixed though, because obviously this is not the right way.
Actually, I think that's the proper way: use your distribution's package manager to install the database client library package.
If you distribute your application in a .deb or. rpm, you can specify this package as a dependency...
-
when you install libpq, you have the library: /usr/lib/libpq.so-XX, and lazarus needs libpq.so, so you have to alternatives
1. make the simbolik link
2. Install libpq-dev to isntall the source and it makes the simbolik link
-
when you install libpq, you have the library: /usr/lib/libpq.so-XX, and lazarus needs libpq.so, so you have to alternatives
1. make the simbolik link
2. Install libpq-dev to isntall the source and it makes the simbolik link
I rather add the simbolic links than install libpq-dev because the package provided by debian is 8.4 and I am using 9.1 however I tried adding the symlinks to /usr/lib and it doesn't work.
-
The debian libpq-dev in sid and testing is version 9.1.0. There does not appear to be a backport for 9.1 yet. Either install the sid/testing package or manually install the 9.1 lib from the postgreSQL download site. The 8.4 lib does not work with 9.0 so it will not work with 9.1 either.
http://www.enterprisedb.com/products-services-training/pgdownload
http://packages.debian.org/wheezy/libpq-dev
http://packages.debian.org/sid/libpq-dev
-
No matter what versions are available or what the package does, it is wrong to manually install anything on a package-managed linux distro. The correct way is to specify a package which provides the correct service, as described above.
If there is a REALLY good reason to provide another library version than provided by the system, it should NEVER be installed to the main system directory tree, e.g. in /usr/lib, but it could be installed under the /usr/local tree, e.g. in /usr/local/lib. However, this stil poses a danger of a version conflict in a future system upgrade, even if there is no immediate conflict at the install time...
-
I agree that the best way is to use an available package. There is now a libpq 9.1 backport package for stable so there is no longer any reason to do a manual install for libpq.
http://packages.debian.org/squeeze-backports/libpq-dev
If a package is available in Debian unstable and not in stable it is usually possible to install the source package and compile for your current stable system.
-
BTW why there is a need install a *-dev package at all? For deployment, all it should be necessary would be a runtime libpq package...
And considering versions, libpq 8.x connects normally to 9.x servers. I'd dare to say, if you don't really use anything 9.x specific, you could test how it works with 8.x client and use that as an option for the application. Having dependency on libpq of 9.x or newer will create incompatibility with many distributions which don't have it... And leaving workarounds for the user to do is often a recipe for disastrer ;)
-
The libpq5 package installs the symbolic link below.
/usr/lib/libpq.so.5 -> libpq.so.5.2
The libpq-dev package installs the desired link
/usr/lib/libpq.so -> libpq.so.5.2
Do not know why this is but I'm sure there is a good reason it happens this way.
Considering PostgreSQL 9.1.0 was released on Sept 16th and it is about 10 days later that it is available for the stable distribution. I would say that is a good turnaround time for a prepackaged system. The 9.1.1 bug fix released yesterday is in the unstable distribution today. It will take some days for the package to filter through to testing and backport.