Subject: [Pljava-dev] Building PLJava on Solaris issues

From: "Eugenie V. Lyzenko" <[email-masked]>
Date: Tue, 22 Mar 2016 19:20:10 +0300

Hello,

Our company is working on the project that requires the usage of the PLJava plug-in with 
Solaris operating system. So we need this module to be compiled with gcc and working with 
Solaris 10. However taking the code from by instructions published on your site does not 
produce the native module required. There are several issues encountered during build:
1. Maven tool does not run after install in Solaris, even with simple "mvn -v" version command
2. The native *.so module building is silently ignoring if C/C++ compilers are gcc/g++
3. The java stack size is not enough for building

So we have performed investigation and found a way to build PLJava in Solaris 10 with gcc. 
Here is the instructions:
1. Replace default Maven start-up script with attached one to start using Maven in Solaris 
10. Based on Maven 3.3.9 version script.
2. Replace default aol.properties in the 
.m2/repository/com/github/maven-nar/nar-maven-plugin/3.2.3/nar-maven-plugin-3.2.3.jar with 
attached one to be able to use gcc in Solaris 10.
3. Set enough Java stack size:
MAVEN_JAVA_RUN_ENV=-Xss2m
export MAVEN_JAVA_RUN_ENV

These steps will give the building PLJava native libraries in Solaris 10 for x86_64 and 
sparc architectures.

Best Regards,
Mr Eugenie Lyzenko.

Software developer,
Golden Code Development Corporation(www.goldencode.com)
_______________________________________________
Pljava-dev mailing list
[email-masked]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

---

From: Chapman Flack <[email-masked]>
Date: Tue, 22 Mar 2016 22:14:59 -0400

On 03/22/16 12:20, Eugenie V. Lyzenko wrote:

> ...
> Solaris 10 with gcc. Here is the instructions:
> 1. Replace default Maven start-up script with attached one to start using
> Maven in Solaris 10. Based on Maven 3.3.9 version script.
> .m2/repository/com/github/maven-nar/nar-maven-plugin/3.2.3/nar-maven-plugin-3.2.3.jar
> with attached one to be able to use gcc in Solaris 10.

Hello! Thank you for your efforts. I will definitely add a Solaris 10
building info page for the final release.

Just to make the suggestions as economical as possible, it looks as if
the changes you made to 'mvn' are these:

@@ -219,7 +219,7 @@
 }

 MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
-MAVEN_OPTS="$(concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config")
$MAVEN_OPTS"
+MAVEN_OPTS=`concat_lines "$MAVEN_PROJECTBASEDIR/.mvn/jvm.config` $MAVEN_OPTS

 # For Cygwin, switch project base directory path to Windows format before
 # executing Maven. Otherwise this will cause Maven not to consider it.
@@ -235,7 +235,7 @@
 MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
 export MAVEN_CMD_LINE_ARGS

-exec "$JAVACMD" \
+exec "$JAVACMD" $MAVEN_JAVA_RUN_ENV \
   $MAVEN_OPTS \
   $MAVEN_DEBUG_OPTS \
   -classpath "${M2_HOME}"/boot/plexus-classworlds-*.jar \

So it looks as if you made two changes: (1) you changed the command
substitution syntax from $() to ``, and (2) you added a new options
variable $MAVEN_JAVA_RUN_ENV that can serve a similar purpose to
$MAVEN_OPTS.

(1) was of course necessary because the top line of the script is #!/bin/sh
and the Solaris 10 /bin/sh does not have the $() syntax. (On Solaris 11,
I read, they have made it default to ksh93 or bash, both of which do
have $() syntax, so there should be no difficulty in 11.)

On Solaris 10, I do believe both bash and ksh are available, but simply
not the default shell, so a lazier solution to (1), with no need to edit
the script, is simply to run it with bash or ksh ... that is, instead of

   mvn  clean  install

use

   bash  path/to/mvn  clean  install

(replacing "path/to/mvn" with the correct path). Or ksh, if for some
reason your Solaris 10 installation is missing bash.

To avoid editing the script to add a new MAVEN_JAVA_RUN_ENV variable,
I would suggest simply setting the existing variable MAVEN_OPTS=-Xss2m
instead, the same technique we currently suggest on the "Building with
a 32-bit JDK" topic page.

Speaking of that topic page, I am not sure from your message whether you
were using a 32-bit or 64-bit JVM.  If it was 64-bit that is somewhat
surprising, I have not seen a report of the default stack being too
small on 64-bit before. Also, did you try -Xss1m first and find it too
small, but 2m works? I may need to increase the suggestion in the docs.

Could you attach the output of 'bash path/to/mvn -v' ?

Turning to the aol.properties file, I think the simpler approach is
to create a file that has only your sparc, sparcv9, amd64 gpp additions,
and instead of inserting it into the plugin jar file, simply specify
the file location using the nar.aolProperties property, as in:

  bash  path/to/mvn  -Dnar.aolProperties=path/to/propfile  clean install

so I think that is how I will suggest it for a Solaris 10 build page.
Would you be willing to try that way and see if it works?

  MAVEN_OPTS=-Xss2m bash path/to/mvn -Dnar.aolProperties=... clean install

Do not feel bad if you did not notice nar.aolProperties in the nar
documentation, it's not there. :)  I only found it by reading the code.

Regards,
-Chap

---

From: "Eugenie V. Lyzenko" <[email-masked]>
Date: Wed, 23 Mar 2016 20:26:24 +0300

Hello, Chap,
>     bash  path/to/mvn  clean  install
Yes, this works.
> small, but 2m works? I may need to increase the suggestion in the docs.
Interesting but now I can compile with default stack size(is 1024k for 64-bit Solaris). I 
have assigned more memory to the system so may be this is the root. One I can tell for 
sure is I faced this memory issue and it was resolved by stack size change. But may be 
this is temporary OS bug or something else..
> Could you attach the output of 'bash path/to/mvn -v' ?
$ bash mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
Maven home: /usr/share/maven-339
Java version: 1.8.0_74, vendor: Oracle Corporation
Java home: /usr/jdk/instances/jdk1.8.0_74/jre
Default locale: en_US, platform encoding: ISO8859-1
OS name: "sunos", version: "5.10", arch: "amd64", family: "unix"

>    MAVEN_OPTS=-Xss2m bash path/to/mvn -Dnar.aolProperties=... clean install
Yes, this works too, no need to patch *.jar file:

bash path/to/mvn -Dnar.aolProperties=... clean install

and get everything compiled with custom CC=gcc. The setting MAVEN_OPTS=-Xss2mins optional 
in case of not enough stack memory issues.
> documentation, it's not there. :)  I only found it by reading the code.
Regards,
Eugenie.

Software developer,

---

From: Chapman Flack <[email-masked]>
Date: Sat, 26 Mar 2016 17:12:11 -0400

> bash path/to/mvn -Dnar.aolProperties=... clean install

Hi,

I don't know if you will have a chance to try on the weekend, but does
something go wrong if you remove the  -R/usr/postgres/9.4-pgdg/lib/64
from your aol.properties file?

If so, could you describe the exact failure and the message?

The aol.properties file should really be about the compiler tool chain
and not contain references to specific PostgreSQL versions or locations.

If PL/Java has to be built with an RPATH on Solaris for some reason, that
may have to be handled in the pom.xml, but first I am just wondering
whether it is really necessary.

I have another reported issue where an RPATH *is* necessary when using
EnterpriseDB community builds, because in their lib directory they are
supplying substitute versions of standard system libraries. But I do not
see any sign of that in the PGDG downloads for Solaris.

-Chap

---

From: "Eugenie V. Lyzenko" <[email-masked]>
Date: Sun, 27 Mar 2016 01:17:23 +0300

Hi Chap,
> from your aol.properties file?
Consider the following for final so:
$ ldd libpljava-so-1.5.0-BETA2.so
         libecpg.so.6 => /usr/postgres/9.4-pgdg/lib/64/libecpg.so.6
         libpgtypes.so.3 => /usr/postgres/9.4-pgdg/lib/64/libpgtypes.so.3
         libpq.so.5 =>    /usr/postgres/9.4-pgdg/lib/64/libpq.so.5
...
The PLJava needs the library from PostgreSQL. And if we have several PostgreSQL versions 
installed on the system - we need to exactly point what version we want to link with(and 
32 or 64 bit).
> If so, could you describe the exact failure and the message?
Now let's see what we have if to remove explicit declaring -R/usr/postgres/9.4-pgdg/lib/64 
from aol.properties file:
$ ldd libpljava-so-1.5.0-BETA2.so
         libecpg.so.6 =>  (file not found)
         libpgtypes.so.3 =>       /opt/csw/lib/64/libpgtypes.so.3
         libpq.so.5 =>    /opt/csw/lib/64/libpq.so.5

At least we potentially will have one runtime linkage error. The other libraries may work 
and may not properly.

The idea of my approach is to exactly point what I want to be done and expect the things 
will go in a planned way. I understand this may be not the only right way but in case of 
dynamic linkage I prefer to include the library path into SO rather than defining path to 
SO object by system variables. The SO library does not spend a time searching required 
library across the system.

Regards,
Eugenie.

---

From: Chapman Flack <[email-masked]>
Date: Sat, 26 Mar 2016 18:32:34 -0400

On 03/26/16 18:17, Eugenie V. Lyzenko wrote:

> Now let's see what we have if to remove explicit declaring
> -R/usr/postgres/9.4-pgdg/lib/64 from aol.properties file:
> At least we potentially will have one runtime linkage error. The other
> libraries may work and may not properly.

Hi,

I understand this is what you see when you run ldd on libpljava.so
in isolation.

However, in operation, that is not what happens. libpljava.so gets
dlopen'd into an already-running postgres backend process, where
those libraries have already been resolved.

Certainly on linux and other OSes where I have tried it, when you
actually load pljava into postgres, it succeeds with no difficulty.
(The Mac OS X linker even has a nifty option where, at build time,
it actually examines the postgres executable to make sure that it
really will satisfy pljava's unmet dependencies at the time it loads.)

So, if there is an issue here with Solaris, that will mean its
behavior is different from the other tested operating systems in
that respect. That's not impossible, but it would be helpful if
you could report what actually happens when you load that libpljava
in a PostgreSQL session.

Thanks,
-Chap

---

From: "Eugenie V. Lyzenko" <[email-masked]>
Date: Sun, 27 Mar 2016 01:54:53 +0300

Hi,
> you could report what actually happens when you load that libpljava
OK. I have just tested the SO library in Solaris without -R/usr/postgres/9.4-pgdg/lib/64 
in properties file.

And there is not difference, no errors. So it can safely be removed I think from 
aol.properties.
Regards,
Eugenie.

Software developer,