Hello

I have problems defining user-defined types and functions in
PostgreSQL using a Visual C++ development environment.

In order to look for the solution I took the complex.c and
complex.source files coming with the PostgreSQL distribution
(src/tutorial).

When I run the examples there is a server crash. I used both Visual
C++ 2008 and 2005 for building the dll. I also used both PostgreSQL
versions 8.4 and 9.0. All versions produce the same problem.

Do you know how can I solve the problem ? Someone has a Visual C++
solution that works that can send me ?

Many many thanks for your help ! I have been struggling around with
this problem for several weeks without any success :-(

Regards

Esteban

--
------------------------------------------------------------
Prof. Esteban Zimanyi
Department of Computer & Decision Engineering  (CoDE) CP 165/15
Universite Libre de Bruxelles
Avenue F. D. Roosevelt 50
B-1050 Brussels, Belgium
fax: + 32.2.650.47.13
tel: + 32.2.650.31.85
e-mail: ezimanyi@ulb.ac.be
Internet: http://code.ulb.ac.be/
------------------------------------------------------------



--
------------------------------------------------------------
Prof. Esteban Zimanyi
Department of Computer & Decision Engineering  (CoDE) CP 165/15
Universite Libre de Bruxelles
Avenue F. D. Roosevelt 50
B-1050 Brussels, Belgium
fax: + 32.2.650.47.13
tel: + 32.2.650.31.85
e-mail: ezimanyi@ulb.ac.be
Internet: http://code.ulb.ac.be/
------------------------------------------------------------

Search Discussions

  • Itagaki Takahiro at Sep 26, 2010 at 4:35 am

    On Sun, Sep 26, 2010 at 12:56 AM, Esteban Zimanyi wrote:
    When I run the examples there is a server crash. I used both Visual
    C++ 2008 and 2005 for building the dll. I also used both PostgreSQL
    versions 8.4 and 9.0. All versions produce the same problem.

    Do you know how can I solve the problem ? Someone has a Visual C++
    solution that works that can send me ?
    If you're developing your project as VC++ standalone project, codes
    in tutorials and contrib modules don't work at all, because they
    don't have __declspec(dllexport) for each function and variable to
    be exported. They will work well as long as you use mingw or special
    VC++ environment used to build the core.

    I had the same problems before, and I wrote some hacks for VC++.
    The codes in pg_reorg/lib in pgFoundry might be a help:
    http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/reorg.c
    http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/pgut/pgut-be.h

    --
    Itagaki Takahiro
  • Euler Taveira de Oliveira at Sep 27, 2010 at 8:14 pm

    Itagaki Takahiro escreveu:
    I had the same problems before, and I wrote some hacks for VC++.
    Isn't there such a code in core or am i missing something? Is it worth
    supporting the VC++ standalone projects?


    --
    Euler Taveira de Oliveira
    http://www.timbira.com/
  • Itagaki Takahiro at Sep 28, 2010 at 12:45 am

    On Tue, Sep 28, 2010 at 5:13 AM, Euler Taveira de Oliveira wrote:
    Itagaki Takahiro escreveu:
    I had the same problems before, and I wrote some hacks for VC++.
    Isn't there such a code in core or am i missing something? Is it worth
    supporting the VC++ standalone projects?
    Since we have PGDLLEXPORT in 9.0, we can mark some of exported
    functions with it in tutorial codes and maybe contrib modules.

    Is it worth doing? We don't need the marks in our build environment,
    but they might help users referencing our codes in standalone VC++ projects.

    --
    Itagaki Takahiro
  • Robert Haas at Sep 28, 2010 at 12:51 am

    On Mon, Sep 27, 2010 at 8:45 PM, Itagaki Takahiro wrote:
    On Tue, Sep 28, 2010 at 5:13 AM, Euler Taveira de Oliveira
    wrote:
    Itagaki Takahiro escreveu:
    I had the same problems before, and I wrote some hacks for VC++.
    Isn't there such a code in core or am i missing something? Is it worth
    supporting the VC++ standalone projects?
    Since we have PGDLLEXPORT in 9.0, we can mark some of exported
    functions with it in tutorial codes and maybe contrib modules.

    Is it worth doing?  We don't need the marks in our build environment,
    but they might help users referencing our codes in standalone VC++ projects.
    If that (a) works and (b) reduces user confusion, +1 from me. We've
    gotten this question a few times lately.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Itagaki Takahiro at Sep 28, 2010 at 3:09 am

    On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas wrote:
    Since we have PGDLLEXPORT in 9.0, we can mark some of exported
    functions with it in tutorial codes and maybe contrib modules.
    If that (a) works and (b) reduces user confusion, +1 from me.  We've
    gotten this question a few times lately.
    If we do so, many PGDLLEXPORT will be added:
    * 17 in src/tutorial
    * 507 in contrib
    for each exported PGFunction, _PG_init, and _PG_fini.

    Any objections? Am I missing something?

    --
    Itagaki Takahiro
  • Robert Haas at Sep 28, 2010 at 3:12 am

    On Mon, Sep 27, 2010 at 11:09 PM, Itagaki Takahiro wrote:
    On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas wrote:
    Since we have PGDLLEXPORT in 9.0, we can mark some of exported
    functions with it in tutorial codes and maybe contrib modules.
    If that (a) works and (b) reduces user confusion, +1 from me.  We've
    gotten this question a few times lately.
    If we do so, many PGDLLEXPORT will be added:
    *  17 in src/tutorial
    * 507 in contrib
    for each exported PGFunction, _PG_init, and _PG_fini.

    Any objections? Am I missing something?
    Oh - I didn't realize this meant marking lots of things in contrib
    that didn't otherwise need to be marked. Why do other people need
    this if we don't?

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Itagaki Takahiro at Sep 28, 2010 at 3:26 am

    On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas wrote:
    If we do so, many PGDLLEXPORT will be added:
    *  17 in src/tutorial
    * 507 in contrib
    for each exported PGFunction, _PG_init, and _PG_fini.
    Oh - I didn't realize this meant marking lots of things in contrib
    that didn't otherwise need to be marked.  Why do other people need
    this if we don't?
    As I mentioned, we don't need the marks in our build environment at all.
    So, the PGDLLEXPORT marks are for users who refers our tutorials and
    contrib modules as sample codes.

    Personally, I learned many idioms from contrib modules, but didn't
    notice the tutorial directory. I think codes in contribs are often
    copied-and-pasted. So, if we add PGDLLEXPORTs to some places,
    I'd like to add them to contribs, too.

    --
    Itagaki Takahiro
  • Robert Haas at Sep 28, 2010 at 3:33 am

    On Mon, Sep 27, 2010 at 11:26 PM, Itagaki Takahiro wrote:
    On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas wrote:
    If we do so, many PGDLLEXPORT will be added:
    *  17 in src/tutorial
    * 507 in contrib
    for each exported PGFunction, _PG_init, and _PG_fini.
    Oh - I didn't realize this meant marking lots of things in contrib
    that didn't otherwise need to be marked.  Why do other people need
    this if we don't?
    As I mentioned, we don't need the marks in our build environment at all.
    Why not?

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 28, 2010 at 6:54 am

    Itagaki Takahiro writes:
    On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas wrote:
    Oh - I didn't realize this meant marking lots of things in contrib
    that didn't otherwise need to be marked.  Why do other people need
    this if we don't?
    As I mentioned, we don't need the marks in our build environment at all.
    In that case, anybody who does need it should fix their build
    environment.

    I grow really weary of the idea that we should submit to arbitrary
    amounts of uglification of our source code so that it will deal with
    this week's Windows oddness. The Windows folk need to be willing to
    do a bit of work on their end.

    regards, tom lane
  • Itagaki Takahiro at Sep 28, 2010 at 7:26 am

    On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane wrote:
    As I mentioned, we don't need the marks in our build environment at all.
    In that case, anybody who does need it should fix their build
    environment.

    I grow really weary of the idea that we should submit to arbitrary
    amounts of uglification of our source code so that it will deal with
    this week's Windows oddness.  The Windows folk need to be willing to
    do a bit of work on their end.
    Windows has 3 levels of function visibilities in a DLL:
    1. exported from the DLL
    2. module global, but not exported
    3. static (private in file), of course not exported

    On UNIXes, 2 is always 1. So we don't have to distinguish between
    global and exported functions. But standard DLL projects on Windows
    require marking which functions should be exported.

    I'm not sure why we can build modules without any EXPORT marks,
    though we can do it actually... It is very unnatural on Windows.


    If we want to avoid adding PGDLLEXPORTs, we could have "sample MSVC
    project with proper settings" in tutorial or documentation instead.
    It should be opened with VC++ GUI (not from command line!) and can
    be generate DLLs in the same way we're using to build the core.

    --
    Itagaki Takahiro
  • Magnus Hagander at Sep 28, 2010 at 9:16 am

    On Tue, Sep 28, 2010 at 09:26, Itagaki Takahiro wrote:
    On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane wrote:
    As I mentioned, we don't need the marks in our build environment at all.
    In that case, anybody who does need it should fix their build
    environment.

    I grow really weary of the idea that we should submit to arbitrary
    amounts of uglification of our source code so that it will deal with
    this week's Windows oddness.  The Windows folk need to be willing to
    do a bit of work on their end.
    Windows has 3 levels of function visibilities in a DLL:
    1. exported from the DLL
    2. module global, but not exported
    3. static (private in file), of course not exported

    On UNIXes, 2 is always 1. So we don't have to distinguish between
    global and exported functions. But standard DLL projects on Windows
    require marking which functions should be exported.

    I'm not sure why we can build modules without any EXPORT marks,
    though we can do it actually... It is very unnatural on Windows.


    If we want to avoid adding PGDLLEXPORTs, we could have "sample MSVC
    project with proper settings" in tutorial or documentation instead.
    It should be opened with VC++ GUI (not from command line!) and can
    be generate DLLs in the same way we're using to build the core.
    We're talking about the "export all symbols" thing, right? I *don't*
    think we want to recommend people to do that - it creates bloated DLL
    files, for no really good reason. Also, it's not just a matter of a
    msvc project - we do that with a perl hack
    (http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/tools/msvc/gendef.pl;h=b8538dd79b8baf21ede87b2ec1aba0276fd3b3d9;hb=62b6aaa40b2abb26edf18d1cd00dffcac090f67a).
    It's not a good way.

    We might, however, want to add a specific section to the
    *documentation* about building extensions on Windows. We have section
    35.9.6 which lists a bunch of OSes, where windows is clearly missing.
    But perhaps a complete section of it's own, like the one for pgxs in
    35.9.6, would be even better?
  • Euler Taveira de Oliveira at Sep 28, 2010 at 1:51 pm

    Magnus Hagander escreveu:
    We might, however, want to add a specific section to the
    *documentation* about building extensions on Windows.
    +1.


    --
    Euler Taveira de Oliveira
    http://www.timbira.com/
  • Itagaki Takahiro at Sep 28, 2010 at 11:52 pm

    On Tue, Sep 28, 2010 at 6:16 PM, Magnus Hagander wrote:
    We're talking about the "export all symbols" thing, right? I *don't*
    think we want to recommend people to do that - it creates bloated DLL
    files, for no really good reason. Also, it's not just a matter of a
    msvc project - we do that with a perl hack
    (http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/tools/msvc/gendef.pl;h=b8538dd79b8baf21ede87b2ec1aba0276fd3b3d9;hb=62b6aaa40b2abb26edf18d1cd00dffcac090f67a).
    It's not a good way.
    What a great hacking! I agree that it is not recommendable, but users
    need to build their codes in different build environment from ours if so.
    We might, however, want to add a specific section to the
    *documentation* about building extensions on Windows
    +1. It will be a longer section than ones for other platforms.

    --
    Itagaki Takahiro
  • Craig Ringer at Sep 28, 2010 at 8:51 am

    On 28/09/10 11:09, Itagaki Takahiro wrote:
    On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas wrote:
    Since we have PGDLLEXPORT in 9.0, we can mark some of exported
    functions with it in tutorial codes and maybe contrib modules.
    If that (a) works and (b) reduces user confusion, +1 from me. We've
    gotten this question a few times lately.
    If we do so, many PGDLLEXPORT will be added:
    * 17 in src/tutorial
    * 507 in contrib
    for each exported PGFunction, _PG_init, and _PG_fini.

    Any objections? Am I missing something?
    For what it's worth, these macros are useful for more than Windows.

    They can be used with gcc's visibility features to reduce the size of
    the symbol table and therefore speed linking and backend startup. This
    isn't as important in a C-only program as it is in a C++ program (which
    has huge collections of private symbols) but it still won't hurt. If
    building with gcc4 on a non-Windows platform, the PGDLLEXPORT macro can
    be defined as:

    #define PGDLLEXPORT __attribute__ ((visibility("default")))

    and gcc can be invoked with -fvisibility=hidden to make symbols not
    explicitly exported hidden by default. A handy advantage of this is that
    it'll cause code that would compile and run correctly on *nix and fail
    on Windows to also fail on *nix, making it easier for *nix based
    developers (ie sane, happy people) to catch issues that'll break Windows.

    Such macros also serve as documentation markers indicating public API.
    They're ugly, but they're not purely Windows ugly.

    --
    Craig Ringer

    Tech-related writing: http://soapyfrogs.blogspot.com/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 25, '10 at 3:56p
activeSep 28, '10 at 11:52p
posts15
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase