Good day,

Please I got a problem with libpq.dll library file, want I tried to select the Connected property to True, I received the Error: Can not load PostgreSQL client library "libpq.dll". Ckeck you installation.

The library has been installed and copied to the project file.

Have you copied all required dlls? I noticed some more dlls in such as libintl-8.dll, libiconv-2.dll and libeay32.dll

Are you using the right bitness (e.g. 32 bit dlls for 32 bit compiler (not OS), 64 bit for 64 bit)?

BTW, specifying Lazarus version (and bitness) can be helpful...

Regards,
Reinier

Libpq.dll has many dependencies. Probably one of them is not satisfied. Here is the list of files I needed to copy on a wine system to get libpq.dll loaded:
comerr32.dll
krb5_32.dll
libintl-2.dll
libpq.dll
pg_dump.dll
pg_restore.dll
libeay32.dll
ssleay32.dll

Ludo

the files libintl-8.dll, libiconv-2.dll are in the mingw folder already. and I copied the libeay32.dll file to the project folder.

Are you using the right bitness (e.g. 32 bit dlls for 32 bit compiler (not OS), 64 bit for 64 bit)?

am running on debian amd64, I installed virtualbox where I ran lazarus on windows XP 32bit.

BTW, specifying Lazarus version (and bitness) can be helpful...

the version is 1.1

Thanks

I did say "such as"... not a PostgreSQL expert - there may be more involved.
Presumably your mingw folder is in your path?? If you rely on dlls in your path you could just as well copy all dlls to your windows\system32 directory... which would set up the dlls for any project.

Anyway, you could try running depends.exe on libpq.dll to see if all dependencies have been met...
Just to confirm: with project file you mean the directory where your project .lpi is located, right?

Ok, thanks, so 32 bit drivers would be in order...

am running on debian amd64, I installed virtualbox where I ran lazarus on windows XP 32bit.

Here is the opened files output of Process Explorer for a simple fpc program on win xp sp2 that makes a connection to a postgres database over the network:

Process: project1.exe Pid: 4268

Name Description Company Name Version
ADVAPI32.dll API avanc?es Windows 32 Microsoft Corporation 5.01.2600.2180
comerr32.dll COM_ERR - Common Error Handler for MIT Kerberos v5 / GSS distribution Massachusetts Institute of Technology. 1.03.0005.0000 ctype.nls
GDI32.dll GDI Client DLL Microsoft Corporation 5.01.2600.3159 hnetcfg.dll Gestionnaire de configuration de r?seau domestique Microsoft Corporation 5.01.2600.2180
IMM32.DLL Windows XP IMM32 API Client DLL Microsoft Corporation 5.01.2600.2180
kernel32.dll DLL du client API BASE Windows NT Microsoft Corporation 5.01.2600.3119
krb5_32.dll Kerberos v5 - MIT GSS / Kerberos v5 distribution Massachusetts Institute of Technology. 1.03.0005.0000 libeay32.dll OpenSSL Shared Library The OpenSSL Project, http://www.openssl.org/ 0.09.0008.0011
libiconv-2.dll
libintl-2.dll
libpq.dll PostgreSQL Access Library 8.02.0004.7110 locale.nls
LPK.DLL Language Pack Microsoft Corporation 5.01.2600.2180 MSVCR90.dll Microsoft? C Runtime Library Microsoft Corporation 9.00.30729.5570
msvcrt.dll Windows NT CRT DLL Microsoft Corporation 7.00.2600.2180
mswsock.dll Fournisseur de service Sockets 2.0 de Microsoft Windows Microsoft Corporation 5.01.2600.2180
ntdll.dll DLL Couche NT Microsoft Corporation 5.01.2600.2180 ole32.dll Microsoft OLE pour Windows Microsoft Corporation 5.01.2600.2726
oleaut32.dll Microsoft Corporation 5.01.2600.3139 project1.exe
RPCRT4.dll Remote Procedure Call Runtime Microsoft Corporation 5.01.2600.3173
SHFOLDER.DLL Shell Folder Service Microsoft Corporation 6.00.2900.2180
snxhk.dll avast! snxhk AVAST Software 6.00.1125.0000 sortkey.nls
sorttbls.nls
ssleay32.dll OpenSSL Shared Library The OpenSSL Project, http://www.openssl.org/ 0.09.0008.0011
unicode.nls
USER32.dll DLL client de l'API Utilisateur de Windows XP Microsoft Corporation 5.01.2600.3099
USP10.dll Uniscribe Unicode script processor Microsoft Corporation 1.420.2600.2180
wldap32.dll DLL API LDAP Win32 Microsoft Corporation 5.01.2600.2180
WS2_32.dll Windows Socket 2.0 32-Bit DLL Microsoft Corporation 5.01.2600.2180
WS2HELP.dll Application d'assistance de Windows Socket 2.0 pour Windows NT Microsoft Corporation 5.01.2600.2180
wshtcpip.dll Windows Sockets Helper DLL Microsoft Corporation 5.01.2600.2180
WSOCK32.dll DLL Socket 32-bits Windows Microsoft Corporation 5.01.2600.2180

Ludo

I've also found that on some win32 machines libpq.dll cannot be loaded, and found that it's because of deps on visual c++ msvcrXXX. dll's , so I've found somewhere mingw compiled libpq.dll and it works fine.It's builded by postgresdac guys.
http://www.microolap.com/downloads/postgresdac/deploy/deploy_mingw.zip

zeljko

Historically, I've used ODBC on Win-32 and sometimes on unix. The libpq.dll the comes with the ODBC drivers looks as though it's been compiled with gcc running natively, and there are minimal dependencies. So it's definitely worth "shopping around", /particularly/ if the alternative is to use MS runtimes in a VM on top of Linux.

I may be missing something here, but what does the fact that Windows may be running in a VM have to do with which compiler/runtime is used? If anything, the Microsoft runtime is more likely to be installed on Windows in any case...

If you're talking about running Windows Lazarus programs that use libpq.dll etc under Wine, that could be a different story...

Anyway, the OP is awfully quiet. I wonder whether his problem has been solved or if he just decided to go out and braai...

Regards,
Reinier

I wasn't thinking of the technical side, but rather of the time that MS leaned heavily on somebody who was about to demonstrate using FoxPro runtimes in an early VM on Linux to implement a multiuser database (they sent at least one lawyer to the usergroup meeting). Now I accept that it's probably difficult for MS to start dictating the terms under which msvcrt may be used, but I can't help but feel that it's something which is best avoided when alternatives exist.

I understand but I think you're talking about wine, which is not a VM (as least as the term is commonly known - of course it is virtual in the sense that Windows programs think they run on Windows while running on *nix).

I'll shut up now.

Thanks,
Reinier

No, it was Foxpro (rather than Visual Foxpro) and I believe the platform was Linux+Dosemu- but it's a long time ago so I could be wrong. This was back when MS was their own (and everybody else's) worst enemy, and whilst they're much more tolerant these days I still don't like pushing it.

Don't copy around dll files. This makes the mess worse. Make sure the postgres bin folder is part of your user/system path.

A problem we encouter lately is that other software vendors come with an outdated ssleay32.dll, which they put in sytem32 or int the path before postgres. simply deleting the outdated ssleay32.dll will solve the issue (as long as the postgres version is in the path)

Marc

Yes, such problem can exist when on client machine is installed an bank card reader which puts old ssleay32 into system32, but I had problem with Visual C++ runtimes (cannot load libpq.dll on some machines, on some works fine), so decided to use mingw compiled libpq (and then it uses only few dll's: libeay32.dll libpq.dll pg_dump.dll pg_restore.dll ssleay32.dll , now everything looks ok. Also, to prevent ssleay32.dll problem I'm putting needed dll's into client app folder.

zeljko

<snip>

Don't copy around dll files. This makes the mess worse. Make sure the postgres bin folder is part of your user/system path.

Unless you use an incompatible set of dlls in your postgres bin folder. What's wrong with distributing known good/tested dll files to the *program directory* (or project/Lazarus dir when developing)? That way, they won't interfere with any existing DLLs in windows.

Yes, I know it interferes with the concept of actually sharing DLL but it avoids versioning issue.
Also, IIRC, Windows Vista+ has some issue to provide side-by-side DLL installation, so copying dlls to the windows system directory may again be allowed; haven't looked at that.

A problem we encouter lately is that other software vendors come with an outdated ssleay32.dll, which they put in sytem32 or int the path before postgres. simply deleting the outdated ssleay32.dll will solve the issue (as long as the postgres version is in the path)

Now you may have broken the other vendor's ssleay32 (if the newer version has regressions).
I'd rather copy over dlls to my application's directory than try to mess with system dlls.
Just my 2 cents.