Обсуждение: Compilations failing
I have a problem when compiling libpqxx with the tools from VS.NET 2005 for
use on Windows XP.
Let me tell the story from the beginning: I installed the postgresql msi
distribution for windows. I checked all the development features during the
installation. So in the installation folder there is a libpq.dll in the /bin
folder. The database itself is working and I have been able to add tables
etc.
However, after downloading libpqxx, as I wanted to compile and use it, I ran
into problems. First, after having creating the common file in the win32
folder and when I was to change the paths inside, all three paths did not
comply with my installation. First for the path to the source code, I
installed by using the msi distribution and hence did not have the source at
hand.
Therefore I downloaded the source and put it in a /src folder in the
installed root folder of postgre. After that I pointed to this /src folder
in the common file. The next two paths should point to a /debug and /release
folder for the compiled libpq, but the only compiled file I have is the
libpq.dll in the /bin folder.
I read that the /debug and /release folders will be created when compiling
libpq by calling "nmake /f win32.mak" in the src/interfaces/libpq folder. So
after running vcvars32.bat in the visual studio folder to enable nmake and
thereafter executing the call "nmake /f win32.mak", I get the following
error:
------------------------------
Building the Win32 static library...
cl.exe @C:\DOCUME~1\Andreas\LOCALS~1\Temp\nm75.tmp
cl : Command line warning D9035 : option 'GX' has been deprecated and will
be re
moved in a future release
cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
cl : Command line warning D9002 : ignoring unknown option '/YX'
wchar.c
..\..\backend\utils\mb\wchar.c(100) : error C2054: expected '(' to follow
'inlin
e'
..\..\backend\utils\mb\wchar.c(101) : error C2085: 'pg_euc_mblen' : not in
forma
l parameter list
..\..\backend\utils\mb\wchar.c(101) : error C2143: syntax error : missing
';' be
fore '{'
..\..\backend\utils\mb\wchar.c(116) : error C2054: expected '(' to follow
'inlin
e'
..\..\backend\utils\mb\wchar.c(117) : error C2085: 'pg_euc_dsplen' : not in
form
al parameter list
..\..\backend\utils\mb\wchar.c(117) : error C2143: syntax error : missing
';' be
fore '{'
..\..\backend\utils\mb\wchar.c(143) : warning C4013: 'pg_euc_mblen'
undefined; a
ssuming extern returning int
..\..\backend\utils\mb\wchar.c(180) : warning C4013: 'pg_euc_dsplen'
undefined;
assuming extern returning int
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
8\VC\BIN\c
l.exe"' : return code '0x2'
Stop.
--------------------------------------------
Does someone have an idea what the problem can be?
_________________________________________________________________
Premiär 17/11 för Casino Royale! http://www.msn.se/noje/casinoroyale/
On Wed, September 27, 2006 05:41, Andreas Gidlund wrote: > I have a problem when compiling libpqxx with the tools from VS.NET 2005 > for use on Windows XP. But the actual errors you run into happen while compiling postgres itself, right? You may want to come over the the libpqxx-general mailing list (see http://pqxx.org/ ) for help with libpqxx-specific problems. > However, after downloading libpqxx, as I wanted to compile and use it, I > ran > into problems. First, after having creating the common file in the win32 > folder and when I was to change the paths inside, all three paths did not > comply with my installation. First for the path to the source code, I > installed by using the msi distribution and hence did not have the source > at hand. From what I've heard, the Windows installer doesn't install the header files for libpq, and those are needed for compiling libpqxx (or any other program that uses libpq). That's why you need the postgres source archive. The paths are a painful obstacle; there just don't seem to be any real standards for these things on Windows. I guess there really ought to be a separate "development package" of postgres for Windows like there is for other systems. The problem seems to be that Windows lacks the necessary compiler standards--a development package would have to be compiler-specific. :-( You should be able to get away with compiling just the Release version of libpqxx if that's what you want, using the Release version of libpq, and just "stealing" the libpq headers from the postgres source tree. But chances are that you'll want to debug your software sometimes, if only during development, so it's better to have both Debug and Release versions of everything available. Jeroen
I am getting so frustrated here...
As compiling with the command prompt failed so hard, I went over to compile
with msys and mingw and actually managed to compile postgres, but it failed
on compiling a dynamic library of libpxx in the next step.
I have therefore left the ambitions to compile libpqxx for now. So I went on
with making a project in visual studio 2005.net and the aim to use only the
libpq dll I managed to compile in msys. That also failed...
So I have been searching all over the internet to find out how to use libpq
in VS, but with no luck at all. I am missing a short and easy to follow
guide. My test program only tries to create a connection object as follows:
PGconn *conn;conn = PQconnectdb("dbname = postgres");
I also have #include "libpq-fe.h" in the beginning. However, I get the
following two messages when compiling:
error LNK2028: unresolved token (0A00000A) "extern "C" struct pg_conn *
__clrcall PQconnectdb(char const *)" (?PQconnectdb@@$$J0YMPAUpg_conn@@PBD@Z)
referenced in function "public: __clrcall
IDBConnection::claPostgreSQL::claPostgreSQL(char *)"
(??0claPostgreSQL@IDBConnection@@$$FQAM@PAD@Z) claPostgreSQL.obj
error LNK2019: unresolved external symbol "extern "C" struct pg_conn *
__clrcall PQconnectdb(char const *)" (?PQconnectdb@@$$J0YMPAUpg_conn@@PBD@Z)
referenced in function "public: __clrcall
IDBConnection::claPostgreSQL::claPostgreSQL(char *)"
(??0claPostgreSQL@IDBConnection@@$$FQAM@PAD@Z) claPostgreSQL.obj
Though, it is quite obvious it is at least because there is no reference to
libpq.dll. I simply don't know how to refer to that file. I also read
somewhere that I have to include libpqdll.lib, is that true?
Even more spoiling my attempts is that the only compiled file for libpq I
get while compiling postgres through msys is the libpq.dll file. I found in
the documentation of 7.4.13 that libpqdll.lib and libpq.lib also should be
created, but they are not for me... The "make" call doesn't return any
errors, just that postgres is ready to be installed. Has this been changed
in v8 or should these files also be created there?
Can someone please help me? I'm soon starting to cry for real...
>From: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
>To: "Andreas Gidlund" <vaxis@hotmail.com>
>CC: pgsql-interfaces@postgresql.org
>Subject: Re: [INTERFACES] Compilations failing
>Date: Wed, 27 Sep 2006 10:23:41 +0700 (ICT)
>
>On Wed, September 27, 2006 05:41, Andreas Gidlund wrote:
> > I have a problem when compiling libpqxx with the tools from VS.NET 2005
> > for use on Windows XP.
>
>But the actual errors you run into happen while compiling postgres itself,
>right? You may want to come over the the libpqxx-general mailing list
>(see http://pqxx.org/ ) for help with libpqxx-specific problems.
>
>
> > However, after downloading libpqxx, as I wanted to compile and use it, I
> > ran
> > into problems. First, after having creating the common file in the win32
> > folder and when I was to change the paths inside, all three paths did
>not
> > comply with my installation. First for the path to the source code, I
> > installed by using the msi distribution and hence did not have the
>source
> > at hand.
>
>From what I've heard, the Windows installer doesn't install the header
>files for libpq, and those are needed for compiling libpqxx (or any other
>program that uses libpq). That's why you need the postgres source
>archive. The paths are a painful obstacle; there just don't seem to be
>any real standards for these things on Windows.
>
>I guess there really ought to be a separate "development package" of
>postgres for Windows like there is for other systems. The problem seems
>to be that Windows lacks the necessary compiler standards--a development
>package would have to be compiler-specific. :-(
>
>You should be able to get away with compiling just the Release version of
>libpqxx if that's what you want, using the Release version of libpq, and
>just "stealing" the libpq headers from the postgres source tree. But
>chances are that you'll want to debug your software sometimes, if only
>during development, so it's better to have both Debug and Release versions
>of everything available.
>
>
>Jeroen
>
>
_________________________________________________________________
Börjar bilen krångla? Köp en ny http://motor.msn.se/
I just wanted to share my experience with other novice users as me...
For me to get it to work with first the windows installer for PostgreSQL and
to setup a project in Visual Studio 2005 I followed this steps:
* Install PostgeSQL (obviously!)
* Add the \bin directory in the PostgreSQL root to the PATH environment
variable (My computer -> Properties -> Advanced -> Environment variables ->
System variables -> add the \bin directory at the end of the PATH variable.
This way the compiled program has access to all necessary dlls.
* As the windows installer does not compile libpqdll.lib (hint at developers
of postgres!), it has do be compiled manually. This is done by first
downloading the source code. Thereafter run the command prompt and navigate
to and run vsvars32.bat in the \VC\bin folder of the Visual Studio root
installation folder.
Libpqdll.lib is compiled by compiling the whole libpq API. This is done by,
still in the command prompt, navigating into \src\interfaces\libpq in the
source distribution and running nmake /f win32.mak. Though, besides the
numerous warnings the compiler gives while compiling, it will stop when
compiling \src\backend\utils\mb\wchar.c, because there are two functions
which cannot be compiled, pg_euc_mblen and pg_euc_dsplen. The reason is that
they are declared both static and inlined, which is a syntax nmake
appearantly does not support. It is safe to remove the inline keywords, as
they do not change any functionality (right?!).
After recompiling with nmake /f win32.mak again the libpqdll.lib is
successfully compiled and put into \src\interfaces\libpq\Release.
* In Visual Studio it is needed to do the following:
- Right-click the project -> Add -> Existing item -> browse to libpqdll.lib
and import it. I got a warning saying there is now custom build rule for
*.lib. Just ignore and press no.
- Right-click the project -> Properties -> Configuration properties -> C/C++
-> add the path to \include of the PostgreSQL root to "Additional Include
Directories".
- In the code add #include <libpq-fe.h>
With this I managed to connect to the database with:
PGconn *pgcConn;
pgcConn = PQconnectdb("dbname=postgres user=postgres password=password");
Though, here comes a problem. When I tried to execute a query and hence
recieve the result into a PGresult, the compiler complains about that the
variable uses an undefined struct, pg_result. I thought all the structures
were incorporated in the libpqdll.lib file... I solved this by copying
libpq-int.h from \src\interfaces\libpq in the source tree into \include in
the postgres root and adding #include <libpq-int.h> into my code. But this
also makes the libpqdll.lib obsolete, as all structure definitions can be
found in libpq-int.h, right? And neither does it fell like the right
approach to include libpq-int.h into the project instead of the
libpqdll.lib, especially since it is stated in libpq-int.h that it is only
for the frontend libpq library to include and should not be used by
applications that call the library.
Anyone has a thought about this?
>From: "Andreas Gidlund" <vaxis@hotmail.com>
>To: pgsql-interfaces@postgresql.org
>Subject: Re: [INTERFACES] Compilations failing
>Date: Fri, 29 Sep 2006 14:38:43 +0200
>
>I am getting so frustrated here...
>
>As compiling with the command prompt failed so hard, I went over to compile
>with msys and mingw and actually managed to compile postgres, but it failed
>on compiling a dynamic library of libpxx in the next step.
>I have therefore left the ambitions to compile libpqxx for now. So I went
>on with making a project in visual studio 2005.net and the aim to use only
>the libpq dll I managed to compile in msys. That also failed...
>
>So I have been searching all over the internet to find out how to use libpq
>in VS, but with no luck at all. I am missing a short and easy to follow
>guide. My test program only tries to create a connection object as follows:
>
> PGconn *conn;
> conn = PQconnectdb("dbname = postgres");
>
>I also have #include "libpq-fe.h" in the beginning. However, I get the
>following two messages when compiling:
>error LNK2028: unresolved token (0A00000A) "extern "C" struct pg_conn *
>__clrcall PQconnectdb(char const *)"
>(?PQconnectdb@@$$J0YMPAUpg_conn@@PBD@Z) referenced in function "public:
>__clrcall IDBConnection::claPostgreSQL::claPostgreSQL(char *)"
>(??0claPostgreSQL@IDBConnection@@$$FQAM@PAD@Z) claPostgreSQL.obj
>
>error LNK2019: unresolved external symbol "extern "C" struct pg_conn *
>__clrcall PQconnectdb(char const *)"
>(?PQconnectdb@@$$J0YMPAUpg_conn@@PBD@Z) referenced in function "public:
>__clrcall IDBConnection::claPostgreSQL::claPostgreSQL(char *)"
>(??0claPostgreSQL@IDBConnection@@$$FQAM@PAD@Z) claPostgreSQL.obj
>
>Though, it is quite obvious it is at least because there is no reference to
>libpq.dll. I simply don't know how to refer to that file. I also read
>somewhere that I have to include libpqdll.lib, is that true?
>Even more spoiling my attempts is that the only compiled file for libpq I
>get while compiling postgres through msys is the libpq.dll file. I found in
>the documentation of 7.4.13 that libpqdll.lib and libpq.lib also should be
>created, but they are not for me... The "make" call doesn't return any
>errors, just that postgres is ready to be installed. Has this been changed
>in v8 or should these files also be created there?
>
>Can someone please help me? I'm soon starting to cry for real...
>
>
>>From: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
>>To: "Andreas Gidlund" <vaxis@hotmail.com>
>>CC: pgsql-interfaces@postgresql.org
>>Subject: Re: [INTERFACES] Compilations failing
>>Date: Wed, 27 Sep 2006 10:23:41 +0700 (ICT)
>>
>>On Wed, September 27, 2006 05:41, Andreas Gidlund wrote:
>> > I have a problem when compiling libpqxx with the tools from VS.NET 2005
>> > for use on Windows XP.
>>
>>But the actual errors you run into happen while compiling postgres itself,
>>right? You may want to come over the the libpqxx-general mailing list
>>(see http://pqxx.org/ ) for help with libpqxx-specific problems.
>>
>>
>> > However, after downloading libpqxx, as I wanted to compile and use it,
>>I
>> > ran
>> > into problems. First, after having creating the common file in the
>>win32
>> > folder and when I was to change the paths inside, all three paths did
>>not
>> > comply with my installation. First for the path to the source code, I
>> > installed by using the msi distribution and hence did not have the
>>source
>> > at hand.
>>
>>From what I've heard, the Windows installer doesn't install the header
>>files for libpq, and those are needed for compiling libpqxx (or any other
>>program that uses libpq). That's why you need the postgres source
>>archive. The paths are a painful obstacle; there just don't seem to be
>>any real standards for these things on Windows.
>>
>>I guess there really ought to be a separate "development package" of
>>postgres for Windows like there is for other systems. The problem seems
>>to be that Windows lacks the necessary compiler standards--a development
>>package would have to be compiler-specific. :-(
>>
>>You should be able to get away with compiling just the Release version of
>>libpqxx if that's what you want, using the Release version of libpq, and
>>just "stealing" the libpq headers from the postgres source tree. But
>>chances are that you'll want to debug your software sometimes, if only
>>during development, so it's better to have both Debug and Release versions
>>of everything available.
>>
>>
>>Jeroen
>>
>>
>
>_________________________________________________________________
>Börjar bilen krångla? Köp en ny http://motor.msn.se/
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
_________________________________________________________________
Prova nya Live Messenger! http://get.live.com/messenger/overview
On Mon, October 2, 2006 02:36, Andreas Gidlund wrote: > it will stop when > compiling \src\backend\utils\mb\wchar.c, because there are two functions > which cannot be compiled, pg_euc_mblen and pg_euc_dsplen. The reason is > that > they are declared both static and inlined, which is a syntax nmake > appearantly does not support. That's not nmake; that's the compiler. The combination of "inline static" sounds perfectly valid to me though--don't see why that would be a problem. Perhaps it's a simple matter of "static inline" vs. "inline static?" > Though, here comes a problem. When I tried to execute a query and hence > recieve the result into a PGresult, the compiler complains about that the > variable uses an undefined struct, pg_result. That's odd... Are you compiling postgres as "managed code," by any chance? That would explain runtime errors of this kind (which in C and C++ should give you compile-time errors or just work), and it's also known to cause lots of confusion and link errors with libpqxx. The problem with "managed code" is that it's not really compatible with C++, but this fact is apparently not made very obvious. From what I hear, the code can look similar but it's not possible to link "managed C++" to C++ DLLs. The situation with C may be similar. Jeroen