Thread: BUG #3983: pgxs files missing from binary installation
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.
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. +
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. + >
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
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
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
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. +
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
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
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
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
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
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