Thread: BUG #3983: pgxs files missing from binary installation

BUG #3983: pgxs files missing from binary installation

From
"Mike Leahy"
Date:
The following bug has been logged online:

Bug reference:      3983
Logged by:          Mike Leahy
Email address:      mgleahy@alumni.uwaterloo.ca
PostgreSQL version: 8.3.0
Operating system:   Win32
Description:        pgxs files missing from binary installation
Details:

I've tried to compile the PL/R module, which I have been doing with 8.2.x
versions.  PL/R requires the pgxs.mk file, and determines its location from
pg_config.  The location of pgxs.mk reported by pg_config in my case (from
windows binary installer) is "C:/Program
Files/PostgreSQL/8.3/lib/pgxs/src/makefiles/pgxs.mk".  However, there is no
such pgxs folder located in the /lib directory...nor is there any other
instance of pgxs.mk anywhere in the PostgreSQL install location.

There also seem to be no pgxs files in any of the other distributed 8.3
binaries for win32.  Tom Lane's suggestion in the pgsql-general mailing list
is that this is a bug with the installer.  At this time, I'm unable to
compile PL/R for PostgreSQL, which I think has a growing user base that
relies on the installer normally posted at http://www.joeconway.com/plr.

Re: BUG #3983: pgxs files missing from binary installation

From
Bruce Momjian
Date:
Has this been addressed?

---------------------------------------------------------------------------

Mike Leahy wrote:
>
> The following bug has been logged online:
>
> Bug reference:      3983
> Logged by:          Mike Leahy
> Email address:      mgleahy@alumni.uwaterloo.ca
> PostgreSQL version: 8.3.0
> Operating system:   Win32
> Description:        pgxs files missing from binary installation
> Details:
>
> I've tried to compile the PL/R module, which I have been doing with 8.2.x
> versions.  PL/R requires the pgxs.mk file, and determines its location from
> pg_config.  The location of pgxs.mk reported by pg_config in my case (from
> windows binary installer) is "C:/Program
> Files/PostgreSQL/8.3/lib/pgxs/src/makefiles/pgxs.mk".  However, there is no
> such pgxs folder located in the /lib directory...nor is there any other
> instance of pgxs.mk anywhere in the PostgreSQL install location.
>
> There also seem to be no pgxs files in any of the other distributed 8.3
> binaries for win32.  Tom Lane's suggestion in the pgsql-general mailing list
> is that this is a bug with the installer.  At this time, I'm unable to
> compile PL/R for PostgreSQL, which I think has a growing user base that
> relies on the installer normally posted at http://www.joeconway.com/plr.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: BUG #3983: pgxs files missing from binary installation

From
"Michael G. Leahy"
Date:
Not that I know of...the win32 binaries on the PostgreSQL website haven't
been updated, and I haven't seen any other mention of this issue in either
pgsql-general or on this list.

On Tue, Mar 4, 2008 at 4:24 PM, Bruce Momjian <bruce@momjian.us> wrote:

>
> Has this been addressed?
>
>
> ---------------------------------------------------------------------------
>
> Mike Leahy wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference:      3983
> > Logged by:          Mike Leahy
> > Email address:      mgleahy@alumni.uwaterloo.ca
> > PostgreSQL version: 8.3.0
> > Operating system:   Win32
> > Description:        pgxs files missing from binary installation
> > Details:
> >
> > I've tried to compile the PL/R module, which I have been doing with
> 8.2.x
> > versions.  PL/R requires the pgxs.mk file, and determines its location
> from
> > pg_config.  The location of pgxs.mk reported by pg_config in my case
> (from
> > windows binary installer) is "C:/Program
> > Files/PostgreSQL/8.3/lib/pgxs/src/makefiles/pgxs.mk".  However, there is
> no
> > such pgxs folder located in the /lib directory...nor is there any other
> > instance of pgxs.mk anywhere in the PostgreSQL install location.
> >
> > There also seem to be no pgxs files in any of the other distributed 8.3
> > binaries for win32.  Tom Lane's suggestion in the pgsql-general mailing
> list
> > is that this is a bug with the installer.  At this time, I'm unable to
> > compile PL/R for PostgreSQL, which I think has a growing user base that
> > relies on the installer normally posted at http://www.joeconway.com/plr.
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
>
> --
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://postgres.enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +
>

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Mike Leahy
Date:
Is this actually a bug, or is there a specific reason that the pgxs
files omitted in the windows installer?  I noticed the 8.3.1 installer
has been posted (as the updates had appeared on my linux machines).
 From what I can tell, the 8.3.1 version of the win32 installer is still
missing pgxs.mk and any related files.

Mike

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Alvaro Herrera
Date:
Mike Leahy wrote:
> Is this actually a bug, or is there a specific reason that the pgxs
> files omitted in the windows installer?  I noticed the 8.3.1 installer
> has been posted (as the updates had appeared on my linux machines). From
> what I can tell, the 8.3.1 version of the win32 installer is still
> missing pgxs.mk and any related files.

It is a bug in the Win32 installer.  Please report it on the Win32
installer project, http://pgfoundry.org/projects/pginstaller/

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
"Dave Page"
Date:
On Tue, Mar 18, 2008 at 12:47 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Mike Leahy wrote:
>  > Is this actually a bug, or is there a specific reason that the pgxs
>  > files omitted in the windows installer?  I noticed the 8.3.1 installer
>  > has been posted (as the updates had appeared on my linux machines). From
>  > what I can tell, the 8.3.1 version of the win32 installer is still
>  > missing pgxs.mk and any related files.
>
>  It is a bug in the Win32 installer.  Please report it on the Win32
>  installer project, http://pgfoundry.org/projects/pginstaller/

It's not an installer bug - pgxs doesn't make sense to the VC++
PostgreSLQ build because we don't use (or configure) any of the build
system on which it relies.

I wonder if we can either build whatever is needed to make pgxs work
(I'm guessing Makefile.global and more) when we run the perl scripts
that generate the project files, or come up with a VC++ alternative to
pgxs.


--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

Re: BUG #3983: pgxs files missing from binary installation

From
Bruce Momjian
Date:
Added to Win32 TODO:

        o Support pgxs


---------------------------------------------------------------------------

Mike Leahy wrote:
>
> The following bug has been logged online:
>
> Bug reference:      3983
> Logged by:          Mike Leahy
> Email address:      mgleahy@alumni.uwaterloo.ca
> PostgreSQL version: 8.3.0
> Operating system:   Win32
> Description:        pgxs files missing from binary installation
> Details:
>
> I've tried to compile the PL/R module, which I have been doing with 8.2.x
> versions.  PL/R requires the pgxs.mk file, and determines its location from
> pg_config.  The location of pgxs.mk reported by pg_config in my case (from
> windows binary installer) is "C:/Program
> Files/PostgreSQL/8.3/lib/pgxs/src/makefiles/pgxs.mk".  However, there is no
> such pgxs folder located in the /lib directory...nor is there any other
> instance of pgxs.mk anywhere in the PostgreSQL install location.
>
> There also seem to be no pgxs files in any of the other distributed 8.3
> binaries for win32.  Tom Lane's suggestion in the pgsql-general mailing list
> is that this is a bug with the installer.  At this time, I'm unable to
> compile PL/R for PostgreSQL, which I think has a growing user base that
> relies on the installer normally posted at http://www.joeconway.com/plr.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Joe Conway
Date:
Dave Page wrote:
> On Tue, Mar 18, 2008 at 12:47 AM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> Mike Leahy wrote:
>>  > Is this actually a bug, or is there a specific reason that the pgxs
>>  > files omitted in the windows installer?  I noticed the 8.3.1 installer
>>  > has been posted (as the updates had appeared on my linux machines). From
>>  > what I can tell, the 8.3.1 version of the win32 installer is still
>>  > missing pgxs.mk and any related files.
>>
>>  It is a bug in the Win32 installer.  Please report it on the Win32
>>  installer project, http://pgfoundry.org/projects/pginstaller/
>
> It's not an installer bug - pgxs doesn't make sense to the VC++
> PostgreSLQ build because we don't use (or configure) any of the build
> system on which it relies.
>
> I wonder if we can either build whatever is needed to make pgxs work
> (I'm guessing Makefile.global and more) when we run the perl scripts
> that generate the project files, or come up with a VC++ alternative to
> pgxs.

I'm finally getting back to this, and finding that plr.dll built against
a MinGW compiled postgres will not load in running cluster built with
VC++ (i.e. the standard binary install). Is that to be expected? If so,
can you give me pointers (either direct guidance or literal URLs) on how
to build postgres and related extensions with VC++?

Thanks,

Joe

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Magnus Hagander
Date:
Joe Conway wrote:
> Dave Page wrote:
> > On Tue, Mar 18, 2008 at 12:47 AM, Alvaro Herrera
> > <alvherre@commandprompt.com> wrote:
> >> Mike Leahy wrote:
> >>  > Is this actually a bug, or is there a specific reason that the
> >>  > pgxs files omitted in the windows installer?  I noticed the
> >>  > 8.3.1 installer has been posted (as the updates had appeared on
> >>  > my linux machines). From what I can tell, the 8.3.1 version of
> >>  > the win32 installer is still missing pgxs.mk and any related
> >>  > files.
> >>
> >>  It is a bug in the Win32 installer.  Please report it on the Win32
> >>  installer project, http://pgfoundry.org/projects/pginstaller/
> >
> > It's not an installer bug - pgxs doesn't make sense to the VC++
> > PostgreSLQ build because we don't use (or configure) any of the
> > build system on which it relies.
> >
> > I wonder if we can either build whatever is needed to make pgxs work
> > (I'm guessing Makefile.global and more) when we run the perl scripts
> > that generate the project files, or come up with a VC++ alternative
> > to pgxs.
>
> I'm finally getting back to this, and finding that plr.dll built
> against a MinGW compiled postgres will not load in running cluster
> built with VC++ (i.e. the standard binary install). Is that to be
> expected? If so, can you give me pointers (either direct guidance or
> literal URLs) on how to build postgres and related extensions with
> VC++?

In general, mingw built modules should load just fine in msvc built
postgres. AFAIK, that's how PostGIS does it for 8.3 (though I know Mark
is working on getting MSVC build support for them). Debugging may be a
bit harder (since they use different kinds of debug symbols - postgres
uses Windows style and mingw uses mingw style), but it should certainly
load.

What trouble exactly are you seeing?

//Magnus

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Joe Conway
Date:
Magnus Hagander wrote:
> In general, mingw built modules should load just fine in msvc built
> postgres. AFAIK, that's how PostGIS does it for 8.3 (though I know Mark
> is working on getting MSVC build support for them). Debugging may be a
> bit harder (since they use different kinds of debug symbols - postgres
> uses Windows style and mingw uses mingw style), but it should certainly
> load.
>
> What trouble exactly are you seeing?

Basically, "Procedure not found", even though it is there. Also note
that the same R.dll is being used from the MinGW Postgres installation
(where plr loads successfully) and the MSVC Postgres.

Joe

p.s. actual output below

8<------------------------------

Welcome to psql 8.3.1, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
        \h for help with SQL commands
        \? for help with psql commands
        \g or terminate with semicolon to execute query
        \q to quit

Warning: Console code page (437) differs from Windows code page (1252)
          8-bit characters might not work correctly. See psql reference
          page "Notes for Windows users" for details.

postgres=# load '$libdir/dblink';
LOAD
postgres=# load '$libdir/plr';
ERROR:  could not load library "C:/Program
Files/PostgreSQL/8.3/lib/plr.dll": The specified procedure could not be
found.

postgres=# CREATE TYPE plr_environ_type AS (name text, value text);
CREATE TYPE
postgres=# CREATE OR REPLACE FUNCTION plr_environ ()
postgres-# RETURNS SETOF plr_environ_type
postgres-# AS '$libdir/plr','plr_environ'
postgres-# LANGUAGE 'C';
ERROR:  could not load library "C:/Program
Files/PostgreSQL/8.3/lib/plr.dll": The specified procedure could not be
found.


Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\jconway>dir "C:\Program Files\PostgreSQL\8.3\lib"
  Volume in drive C has no label.
  Volume Serial Number is A006-8372

  Directory of C:\Program Files\PostgreSQL\8.3\lib

[...]
03/17/2008  03:49 AM            57,344 dblink.dll
[...]
03/17/2008  03:47 AM            28,264 libpq.lib
[...]
04/06/2008  12:50 PM           686,579 plr.dll

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Magnus Hagander
Date:
Joe Conway wrote:
> Magnus Hagander wrote:
>> In general, mingw built modules should load just fine in msvc built
>> postgres. AFAIK, that's how PostGIS does it for 8.3 (though I know Mark
>> is working on getting MSVC build support for them). Debugging may be a
>> bit harder (since they use different kinds of debug symbols - postgres
>> uses Windows style and mingw uses mingw style), but it should certainly
>> load.
>>
>> What trouble exactly are you seeing?
>
> Basically, "Procedure not found", even though it is there. Also note
> that the same R.dll is being used from the MinGW Postgres installation
> (where plr loads successfully) and the MSVC Postgres.

Could this be somethingl ike missing PGDLLIMPORT specifications in your
addon module or something like that? Try checking the names of the
functions that are actually exported using "depends" or a similar tool.


> postgres=# load '$libdir/dblink';
> LOAD
> postgres=# load '$libdir/plr';
> ERROR:  could not load library "C:/Program
> Files/PostgreSQL/8.3/lib/plr.dll": The specified procedure could not be
> found.

Actually, this looks like perhaps the backend is unable to load a DLL
that plr.dll depends on. Again, the "depends" tool can hopefully show
you what's missing there.

//Magnus

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Joe Conway
Date:
Magnus Hagander wrote:
> Could this be somethingl ike missing PGDLLIMPORT specifications in your
> addon module or something like that? Try checking the names of the
> functions that are actually exported using "depends" or a similar tool.

Ah, that sounds likely, since I have never had to worry about explicit
exports with PL/R before. Can you point me to an example or cheat sheet
on what I need to do?

>> ERROR:  could not load library "C:/Program
>> Files/PostgreSQL/8.3/lib/plr.dll": The specified procedure could not
>> be found.
>
> Actually, this looks like perhaps the backend is unable to load a DLL
> that plr.dll depends on. Again, the "depends" tool can hopefully show
> you what's missing there.

That's what I was originally thinking (R.dll), but now I suspect the
exported functions is probably the issue. I'll check this out when I get
home tonight.

Thanks,

Joe

Re: BUG #3983: pgxs files still missing in win32 install (8.3.1)

From
Magnus Hagander
Date:
Joe Conway wrote:
> Magnus Hagander wrote:
> > Could this be somethingl ike missing PGDLLIMPORT specifications in
> > your addon module or something like that? Try checking the names of
> > the functions that are actually exported using "depends" or a
> > similar tool.
>
> Ah, that sounds likely, since I have never had to worry about
> explicit exports with PL/R before. Can you point me to an example or
> cheat sheet on what I need to do?

Stick a PGDLLIMPORT where needed :-)

Though now that I think of it, you only need that for variables. We use
the (broken, really, but that's what we do) method of exporting every
single function we can find in the binaries... You should have the same
issue with pl/pgsql, and it doesn't add PGDLLIMPORT so you should be
good there.

So it shouldn't be that problem, really.


> >> ERROR:  could not load library "C:/Program
> >> Files/PostgreSQL/8.3/lib/plr.dll": The specified procedure could
> >> not be found.
> >
> > Actually, this looks like perhaps the backend is unable to load a
> > DLL that plr.dll depends on. Again, the "depends" tool can
> > hopefully show you what's missing there.
>
> That's what I was originally thinking (R.dll), but now I suspect the
> exported functions is probably the issue. I'll check this out when I
> get home tonight.

I hold this much more likely. It may be R.dll, it may be something that
R.dll depends on, or another direct dependency.


//Magnus