Error in Pl/Java Backend Native code stage while installating pl/Java 1.5.8 version

[Sivee-hash]

Hello there! We are getting errors while installing PL/Java Backend Native code stage . anyone please help me on this issue since it is blocking my work. we are trying to install PL/Java 1.5.8 for PostgreSQL 13.11 and Java 8 versions. Error seems to be as follows: [ERROR] VarlenaWrapper.obj : error LNK2019: unresolved external symbol _toast_raw_datum_size referenced in function _pljava_VarlenaWrapper_Input

getting same error as above in many .obj files.

Thanks, Siva

[Sivee-hash]

We're following Build,Install as per this link. https://tada.github.io/pljava/build/build.html

[jcflack]

I have just built 1_5_STABLE against PG 13.11 on linux-x86 without any such issue, so I have not managed to reproduce this.

What do you mean by "getting same error as above in many .obj files"? toast_raw_datum_size probably isn't anywhere except VarlenaWrapper.obj. Do you mean that you are getting various other "unresolved external symbol" errors, for various other symbols?

It sounds as if the linker might not be finding the right PostgreSQL binary.

[beargiles]

This isn't an exact match but I've just pushed a docker image containing a 13.11 dev environment: beargiles/postgres-pljava-dev/13.11. The Dockerfile requires the extension to be successfully built. (However it is neither tested nor installed over the default extension.)

This images has two significant differences from what you're describing:

• it uses REL1_6_STABLE branch - you'll want to run git checkout REL1_5_STABLE
• it uses Java 17

The latter is due to the upstream version https://hub.docker.com/_/postgres being built on top of Debian "bookworm" - it only offers Java 17. However this shouldn't be a problem since you can modify the maven pom.xml file to specify that you want the compiler to use <release>11</release>, or explicitly specify the source and target values to the same.

[jcflack]

* it uses REL1_6_STABLE branch - you'll want to run `git checkout REL1_5_STABLE`

Did you mean to say git checkout REL1_6_STABLE?

I really don't recommend working from branch tips. If the latest announced release on the 1.6 branch was 1.6.5, then git checkout V1_6_5 is a better idea.

At the moment, because 1.6.5 was released fairly recently, there is very little different between it and the branch tip, other than the branch tip will build as a version 1.6-SNAPSHOT and PostgreSQL's extension machinery won't be able to tell that from any other 1.6-SNAPSHOT, so ALTER EXTENSION UPDATE will flake out. Later on, it is possible the branch tip will have recent development not yet polished enough for a next release.

* it uses Java 17

The latter is due to the upstream version https://hub.docker.com/_/postgres being built on top of Debian "bookworm" - it only offers Java 17. However this shouldn't be a problem since you can modify the maven pom.xml file to specify that you want the compiler to use <release>11</release>, or explicitly specify the source and target values to the same.

As I also mentioned in #449, I am puzzled at why you are modifying the POM like this. I've definitely built PL/Java 1.6.x on Java 17 (and 16, 15, ..., 9, and 18, and 19) without making any change to the release specification in the POM.

It doesn't work on Java 20 because of a Java 20 regular expressions bug, reportedly fixed in Java 21. While I haven't tried a 21 build yet, I will be surprised if it does not also work, with the POM just as it is.

[beargiles]

The ultimate answer is that I want to automate builds using a CI/CD pipeline triggered by a new PostgreSQL release on docker hub. I can build these images myself but many people can't, and the prebuilt images listed on the wiki can be pretty outdated.

Until the last week or so I've only been concerned with a binary release. That's easy - the official docker image already contains a .deb package containing the pl/java extension. The Dockerfile only needs to know which packages to install - and that's completely determined by the PG_VERSION and PG_MAJOR attributes.

I've been planning on a source release as well and this question prompted me to take another look at it. My focus was ensuring all of the required software was installed... but there wasn't a clean answer on which branch to pull for a test build. That information isn't available at the CI/CD level. (Well... not trivially.) I could write a script that's run in the docker container but decided that using a fixed value is Good Enough for now. Anyone who needs to use this image will start by doing a git checkout anyway.

Also the REL1_5_STABLE was because the original question referred to a 1.5 release. You're right that a more specific version would be better.

[jcflack]

Closed waiting on reporter