agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] Building from source for PG 8.2.4
8+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 04:52
0 siblings, 1 reply; 8+ messages in thread
From: @ 2007-08-31 04:52 UTC (permalink / raw)
For months, I have been running PL/Java successfully with PostgreSQL
8.1.8 on Kubuntu Linux using the PL/Java 1.3.0 binary distribution. I
recently upgraded to PG 8.2.4 and found that the 1.3.0 pljava.so binary
would no longer work, due to the version check mechanism
(PG_MAGIC_MODULE) introduced for extensions in 8.2. So, I set out to
compile PL/Java from source with the newer version of PostgreSQL
installed...
I have now rebuilt PL/Java from the latest CVS source tree, using Sun's
Java 1.5.0_11 (had to drop back from Java 6 due to some unimplemented
JDBC 4 methods). Simply running make from the top level directory
seemed to work. Curiously, I ended up with a pljava.so that was nearly
5 times larger than the version which was distributed with the PL/Java
1.3.0 release. Any idea why this would be? Does the default build
included debug symbols?
Anyway, when I try to deploy to a database using install.sql, it
complains that it is unable to locate the JVM:
psql:install.sql:6: ERROR: could not load library
"/usr/lib/postgresql/8.2/lib/pljava.so":
/usr/lib/postgresql/8.2/lib/pljava.so: undefined symbol: JNI_CreateJavaVM
I've made all the same changes to postgresql.conf that were necessary to
get this to work with my previous PG 8.1.8 installation. Likewise, I
have set LD_LIBRARY_PATH in exactly the same way as was working before.
For Kubuntu, this is set in /etc/postgresql/8.2/<mycluster>/environment,
as in:
LD_LIBRARY_PATH =
'/usr/lib/jvm/java-1.5.0-sun/jre/lib/i386:/usr/lib/jvm/java-1.5.0-sun/jre/lib/i386/server'
And yes, I've double checked that these are valid paths to the Sun 1.5
JVM on my system.
So, I'm not sure why I'm now seeing this JVM load error, but the extra
large pljava.so has me wondering if the build really worked properly
after all. Any suggestions on what to try next?
Thanks in advance,
Eric Faulhaber
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 18:45
parent:
0 siblings, 1 reply; 8+ messages in thread
From: @ 2007-08-31 18:45 UTC (permalink / raw)
On Fri, 31 Aug 2007, Eric Faulhaber wrote:
> Curiously, I ended up with a pljava.so that was nearly 5 times larger
> than the version which was distributed with the PL/Java 1.3.0 release.
> Any idea why this would be? Does the default build included debug
> symbols?
>
It will pick up the compile options used for the server it's built
against (see pg_config --cflags). I'm not sure how the release was made,
but you can certainly check your own config.
> Anyway, when I try to deploy to a database using install.sql, it
> complains that it is unable to locate the JVM:
>
> psql:install.sql:6: ERROR: could not load library
> "/usr/lib/postgresql/8.2/lib/pljava.so":
> /usr/lib/postgresql/8.2/lib/pljava.so: undefined symbol: JNI_CreateJavaVM
>
> I've made all the same changes to postgresql.conf that were necessary to
> get this to work with my previous PG 8.1.8 installation. Likewise, I
> have set LD_LIBRARY_PATH in exactly the same way as was working before.
> For Kubuntu, this is set in /etc/postgresql/8.2/<mycluster>/environment,
> as in:
Have you restarted the postgres server? These changes won't take effect
without that.
Kris Jurka
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 19:47
parent:
0 siblings, 1 reply; 8+ messages in thread
From: @ 2007-08-31 19:47 UTC (permalink / raw)
Kris Jurka wrote:
>
>
> On Fri, 31 Aug 2007, Eric Faulhaber wrote:
>
>> Curiously, I ended up with a pljava.so that was nearly 5 times larger
>> than the version which was distributed with the PL/Java 1.3.0
>> release. Any idea why this would be? Does the default build included
>> debug symbols?
>>
>
> It will pick up the compile options used for the server it's built
> against (see pg_config --cflags). I'm not sure how the release was
> made, but you can certainly check your own config.
pg_config --cflags output:
-g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
Interesting. I installed PG 8.2.4 using Kubuntu's package manager. Odd
that they would distribute a production release with debug symbols (and
they seem to want to be sure of it; '-g' shows up twice!). Well, that
explains the huge library file.
>
>> Anyway, when I try to deploy to a database using install.sql, it
>> complains that it is unable to locate the JVM:
>>
>> psql:install.sql:6: ERROR: could not load library
>> "/usr/lib/postgresql/8.2/lib/pljava.so":
>> /usr/lib/postgresql/8.2/lib/pljava.so: undefined symbol:
>> JNI_CreateJavaVM
>>
>> I've made all the same changes to postgresql.conf that were necessary to
>> get this to work with my previous PG 8.1.8 installation. Likewise, I
>> have set LD_LIBRARY_PATH in exactly the same way as was working before.
>> For Kubuntu, this is set in /etc/postgresql/8.2/<mycluster>/environment,
>> as in:
>
> Have you restarted the postgres server? These changes won't take
> effect without that.
Yes. BTW, on Kubuntu, apparently it's not enough to SIGHUP the
postmaster if you make changes to the
/etc/postgresql/8.2/<cluster>/environment file; a full restart seems to
be necessary.
Actually, it turns out something was wrong with my build: pljava.so was
not linking to libjvm.so. The problem area for me was with the setup of
the directory in which we look to link to the JVM (in
src/C/pljava/Makefile):
JVM_LIB := $(firstword $(shell /bin/ls -d \
$(JRE_LIB)/client \
$(JRE_LIB)/server \
$(JRE_LIB)/jrockit \
2> /dev/null))
For me, this was resulting in an empty string for JVM_LIB:
cc -g -Wall -O2 -fPIC -Wall -Wmissing-prototypes -Wpointer-arith
-Winline -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -g -fpic -shared -Wl,-soname,pljava.so
JNICalls.o Iterator.o SPI.o PgObject.o SQLOutputToChunk.o
SQLOutputToTuple.o ExecutionPlan.o SQLInputFromChunk.o Exception.o
PgSavepoint.o Session.o SubXactListener.o XactListener.o HashMap.o
type/Void.o type/Double.o type/Float.o type/ErrorData.o type/Array.o
type/Date.o type/Timestamp.o type/Boolean.o type/Coerce.o type/Any.o
type/Long.o type/AclId.o type/String.o type/HeapTupleHeader.o
type/Type.o type/Byte.o type/JavaWrapper.o type/Short.o type/Portal.o
type/BigDecimal.o type/LargeObject.o type/Integer.o type/UDT.o
type/Time.o type/Oid.o type/TriggerData.o type/Relation.o type/Tuple.o
type/TupleDesc.o type/Composite.o type/TupleTable.o type/byte_array.o
backports.o Invocation.o Function.o SQLInputFromTuple.o Backend.o
-L/usr/lib -L. -L"" -ljvm -o pljava.so
I temporarily worked around this by hard-coding the target JVM_LIB
directory in the Makefile, but clearly this is not a permanent
solution. So, something appears to be invalid with my build
environment. I had JAVA_HOME set to my Java 1.5 directory. Something
else I should have set?
>
> Kris Jurka
>
>
Thanks for your feedback!
Regards,
Eric Faulhaber
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 20:02
parent:
0 siblings, 1 reply; 8+ messages in thread
From: @ 2007-08-31 20:02 UTC (permalink / raw)
On Fri, 31 Aug 2007, Eric Faulhaber wrote:
> Actually, it turns out something was wrong with my build: pljava.so was
> not linking to libjvm.so. The problem area for me was with the setup of
> the directory in which we look to link to the JVM (in
> src/C/pljava/Makefile):
>
> JVM_LIB := $(firstword $(shell /bin/ls -d \
> $(JRE_LIB)/client \
> $(JRE_LIB)/server \
> $(JRE_LIB)/jrockit \
> 2> /dev/null))
>
> I temporarily worked around this by hard-coding the target JVM_LIB
> directory in the Makefile, but clearly this is not a permanent
> solution. So, something appears to be invalid with my build
> environment. I had JAVA_HOME set to my Java 1.5 directory. Something
> else I should have set?
Any chance your machine reports something other than i386 or i686 for
$host_cpu? If you have something like i586, the makefile in question
will not provide the appropriate JRE_CPU mapping (circa line 55). Echoing
JRE_LIB prior to were you hardcoded things would be informative.
Kris Jurka
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 20:49
parent:
0 siblings, 1 reply; 8+ messages in thread
From: @ 2007-08-31 20:49 UTC (permalink / raw)
Kris Jurka wrote:
>
>
> On Fri, 31 Aug 2007, Eric Faulhaber wrote:
>
>> Actually, it turns out something was wrong with my build: pljava.so was
>> not linking to libjvm.so. The problem area for me was with the setup of
>> the directory in which we look to link to the JVM (in
>> src/C/pljava/Makefile):
>>
>> JVM_LIB := $(firstword $(shell /bin/ls -d \
>> $(JRE_LIB)/client \
>> $(JRE_LIB)/server \
>> $(JRE_LIB)/jrockit \
>> 2> /dev/null))
>>
>> I temporarily worked around this by hard-coding the target JVM_LIB
>> directory in the Makefile, but clearly this is not a permanent
>> solution. So, something appears to be invalid with my build
>> environment. I had JAVA_HOME set to my Java 1.5 directory. Something
>> else I should have set?
>
> Any chance your machine reports something other than i386 or i686 for
> $host_cpu? If you have something like i586, the makefile in question
> will not provide the appropriate JRE_CPU mapping (circa line 55).
> Echoing JRE_LIB prior to were you hardcoded things would be informative.
Sure enough:
/usr/lib/jvm/java-1.5.0-sun/jre/lib/i486
The following change to the Makefile fixes this; however, as I am not a
make guru, there may be a better way to handle this:
RCS file:
/usr/local/cvsroot/pljava/org.postgresql.pljava/src/C/pljava/Makefile,v
retrieving revision 1.37
diff -r1.37 Makefile
57a58,60
> ifeq ($(host_cpu), i486)
> JRE_CPU := i386
> else
63a67
> endif
I am open to a better change, but I'll go with this for my local copy
for now.
The only question I have left: is there a way to partially override the
compiler options divined from pg_config, so I can turn off -g but
inherit the rest?
Thanks,
Eric Faulhaber
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 21:29
parent:
0 siblings, 2 replies; 8+ messages in thread
From: @ 2007-08-31 21:29 UTC (permalink / raw)
On Fri, 31 Aug 2007, Eric Faulhaber wrote:
>> Any chance your machine reports something other than i386 or i686 for
>> $host_cpu? If you have something like i586, the makefile in question
>> will not provide the appropriate JRE_CPU mapping (circa line 55).
>> Echoing JRE_LIB prior to were you hardcoded things would be informative.
> Sure enough:
>
> /usr/lib/jvm/java-1.5.0-sun/jre/lib/i486
>
> The following change to the Makefile fixes this; however, as I am not a
> make guru, there may be a better way to handle this:
>
OK, I'll commit this fix and similar for i586 to CVS later today.
> The only question I have left: is there a way to partially override the
> compiler options divined from pg_config, so I can turn off -g but
> inherit the rest?
>
Putting this after "override CFLAGS += $(PLJAVA_CFLAGS)" approx line 140
might work:
CFLAGS := $(filter-out -g, $(CFLAGS))
Kris Jurka
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 21:35
parent:
1 sibling, 0 replies; 8+ messages in thread
From: @ 2007-08-31 21:35 UTC (permalink / raw)
Kris Jurka wrote:
>
>
> On Fri, 31 Aug 2007, Eric Faulhaber wrote:
>
>>> Any chance your machine reports something other than i386 or i686 for
>>> $host_cpu? If you have something like i586, the makefile in question
>>> will not provide the appropriate JRE_CPU mapping (circa line 55).
>>> Echoing JRE_LIB prior to were you hardcoded things would be
>>> informative.
>> Sure enough:
>>
>> /usr/lib/jvm/java-1.5.0-sun/jre/lib/i486
>>
>> The following change to the Makefile fixes this; however, as I am not a
>> make guru, there may be a better way to handle this:
>>
>
> OK, I'll commit this fix and similar for i586 to CVS later today.
Sounds good!
>
>> The only question I have left: is there a way to partially override the
>> compiler options divined from pg_config, so I can turn off -g but
>> inherit the rest?
>>
>
> Putting this after "override CFLAGS += $(PLJAVA_CFLAGS)" approx line
> 140 might work:
>
> CFLAGS := $(filter-out -g, $(CFLAGS))
>
I'll give it a try. Thanks very much for your help, Kris!
Regards,
Eric Faulhaber
^ permalink raw reply [nested|flat] 8+ messages in thread
* [Pljava-dev] Building from source for PG 8.2.4
@ 2007-08-31 21:36
parent:
1 sibling, 0 replies; 8+ messages in thread
From: @ 2007-08-31 21:36 UTC (permalink / raw)
On Fri, 31 Aug 2007, Kris Jurka wrote:
> OK, I'll commit this fix and similar for i586 to CVS later today.
Done.
>> The only question I have left: is there a way to partially override the
>> compiler options divined from pg_config, so I can turn off -g but
>> inherit the rest?
>>
>
> Putting this after "override CFLAGS += $(PLJAVA_CFLAGS)" approx line 140
> might work:
>
> CFLAGS := $(filter-out -g, $(CFLAGS))
>
A quick test shows you need to say "override CFLAGS := $(filter-out
-g, $(CFLAGS))"
Kris Jurka
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2007-08-31 21:36 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-08-31 04:52 [Pljava-dev] Building from source for PG 8.2.4
2007-08-31 18:45 `
2007-08-31 19:47 `
2007-08-31 20:02 `
2007-08-31 20:49 `
2007-08-31 21:29 `
2007-08-31 21:35 `
2007-08-31 21:36 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox