pgxs regression

Joe Conway wrote:

I'm not sure exactly what has changed, nor at the moment how to fix it,
but I'm finding that pgxs no longer works for PL/R or dblink. Error as
follows:

make: *** No rule to make target
`/usr/local/pgsql-dev/lib/pgxs/src/makefiles/../../src/port/pg_config_paths.h',
needed by `all-static-lib'. Stop.

The problem is related specifically to Makefiles using MODULE_big. I
tested a few contribs that use MODULES and they seem to work fine under
pgxs.

Joe

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Seems you have the same issue that I have with PL/Java. I had to
explicitly change my target from:

all: all_lib

to:

all: $(shlib)

The thread "Problems with pgxs" started in hackers on 10/31 may be of
some interest.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:

Joe Conway wrote:

The problem is related specifically to Makefiles using MODULE_big. I
tested a few contribs that use MODULES and they seem to work fine
under pgxs.

Seems you have the same issue that I have with PL/Java. I had to
explicitly change my target from:

all: all_lib

to:

all: $(shlib)

The thread "Problems with pgxs" started in hackers on 10/31 may be of
some interest.

I'll go take a look at the thread (haven't yet) but as of the moment
this is not fixed in cvs. Here are two examples from contrib (in each
case I inserted "USE_PGXS = 1" into the Makefile):

# cd contrib/dblink/
# vi Makefile
# make
make: *** No rule to make target
`/usr/local/pgsql-dev/lib/pgxs/src/makefiles/../../src/port/pg_config_paths.h',

needed by `all-static-lib'. Stop.
# cd ../pgcrypto/
# vi Makefile
# make
sed 's,MODULE_PATHNAME,$libdir/pgcrypto,g' pgcrypto.sql.in >pgcrypto.sql
make: *** No rule to make target
`/usr/local/pgsql-dev/lib/pgxs/src/makefiles/../../src/port/pg_config_paths.h',

needed by `all-static-lib'. Stop.

As stated above, *all* contribs using MODULE_big fail in this same
manner. Do they all need the workaround mentioned above? Seems to me
like we need a better solution than that.

Joe

Joe Conway <mail@joeconway.com> writes:

I'll go take a look at the thread (haven't yet) but as of the moment
this is not fixed in cvs. Here are two examples from contrib (in each
case I inserted "USE_PGXS = 1" into the Makefile):

# cd contrib/dblink/
# vi Makefile
# make
make: *** No rule to make target
`/usr/local/pgsql-dev/lib/pgxs/src/makefiles/../../src/port/pg_config_paths.h',
needed by `all-static-lib'. Stop.

My inclination is to get rid of the dependency of the Makefile.shlib
targets on pg_config_paths.h; Bruce has never satisfactorily explained
why he added that. There may be a need for a dependency on
pg_config_paths.h someplace, but surely this is the wrong place.

I don't understand what $(PTHREAD_H_WIN32) is doing there either --- the
only definition of it that I can see is
PTHREAD_H_WIN32 = yes
in libpq/Makefile, which does not look like a build target. (The
comment just above that saying "this doesn't work yet" doesn't increase
my faith any...)

regards, tom lane

Tom Lane wrote:

My inclination is to get rid of the dependency of the Makefile.shlib
targets on pg_config_paths.h; Bruce has never satisfactorily explained
why he added that. There may be a need for a dependency on
pg_config_paths.h someplace, but surely this is the wrong place.

I don't understand what $(PTHREAD_H_WIN32) is doing there either --- the
only definition of it that I can see is
PTHREAD_H_WIN32 = yes
in libpq/Makefile, which does not look like a build target. (The
comment just above that saying "this doesn't work yet" doesn't increase
my faith any...)

Indeed, backing out Bruce's commit
( http://archives.postgresql.org/pgsql-committers/2004-10/msg00158.php )
makes my problems go away. I have no idea how to fix the win32 stuff
though :(

Joe

Joe Conway <mail@joeconway.com> writes:

Indeed, backing out Bruce's commit
( http://archives.postgresql.org/pgsql-committers/2004-10/msg00158.php )
makes my problems go away. I have no idea how to fix the win32 stuff
though :(

Looking more closely, those dependencies were wrong anyway since they
didn't cause changes to propagate. I've committed corrections.

The win32 pthread stuff looks to me like it still doesn't work, but that
is someone else's problem to fix.

regards, tom lane