public inbox for [email protected]
help / color / mirror / Atom feed[Pljava-dev] Building PLJava on Solaris issues
7+ messages / 2 participants
[nested] [flat]
* [Pljava-dev] Building PLJava on Solaris issues
@ 2016-03-22 16:20 Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Eugenie V. Lyzenko @ 2016-03-22 16:20 UTC (permalink / raw)
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 protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
Attachments:
[application/zip] aol.properties_Solaris_10_x86_sparc.zip (4.3K, ../../[email protected]/2-aol.properties_Solaris_10_x86_sparc.zip)
download
[application/zip] mvn.Solaris_10_x86_sparc.zip (2.6K, ../../[email protected]/3-mvn.Solaris_10_x86_sparc.zip)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [Pljava-dev] Building PLJava on Solaris issues
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
@ 2016-03-23 02:14 ` Chapman Flack <[email protected]>
2016-03-23 17:26 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Chapman Flack @ 2016-03-23 02:14 UTC (permalink / raw)
On 03/22/16 12:20, Eugenie V. Lyzenko wrote:
> 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
> ...
> 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
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
_______________________________________________
Pljava-dev mailing list
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [Pljava-dev] Building PLJava on Solaris issues
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
@ 2016-03-23 17:26 ` Eugenie V. Lyzenko <[email protected]>
2016-03-26 21:12 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Eugenie V. Lyzenko @ 2016-03-23 17:26 UTC (permalink / raw)
Hello, Chap,
> On 03/22/16 12:20, Eugenie V. Lyzenko wrote:
>
>>
>
>
> 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
Yes, this works.
> (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.
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"
> 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
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.
>
> 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
Regards,
Eugenie.
Software developer,
Golden Code Development Corporation(www.goldencode.com)
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [Pljava-dev] Building PLJava on Solaris issues
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
2016-03-23 17:26 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
@ 2016-03-26 21:12 ` Chapman Flack <[email protected]>
2016-03-26 22:17 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Chapman Flack @ 2016-03-26 21:12 UTC (permalink / raw)
On 03/23/16 13:26, Eugenie V. Lyzenko wrote:
> Yes, this works too, no need to patch *.jar file:
>
> 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
_______________________________________________
Pljava-dev mailing list
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [Pljava-dev] Building PLJava on Solaris issues
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
2016-03-23 17:26 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-26 21:12 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
@ 2016-03-26 22:17 ` Eugenie V. Lyzenko <[email protected]>
2016-03-26 22:32 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Eugenie V. Lyzenko @ 2016-03-26 22:17 UTC (permalink / raw)
Hi Chap,
> On 03/23/16 13:26, Eugenie V. Lyzenko wrote:
>> Yes, this works too, no need to patch *.jar file:
>>
>> 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?
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.
> 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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [Pljava-dev] Building PLJava on Solaris issues
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
2016-03-23 17:26 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-26 21:12 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
2016-03-26 22:17 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
@ 2016-03-26 22:32 ` Chapman Flack <[email protected]>
2016-03-26 22:54 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Chapman Flack @ 2016-03-26 22:32 UTC (permalink / raw)
On 03/26/16 18:17, Eugenie V. Lyzenko wrote:
>> 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.
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
_______________________________________________
Pljava-dev mailing list
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [Pljava-dev] Building PLJava on Solaris issues
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
2016-03-23 17:26 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-26 21:12 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
2016-03-26 22:17 ` Re: [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-26 22:32 ` Re: [Pljava-dev] Building PLJava on Solaris issues Chapman Flack <[email protected]>
@ 2016-03-26 22:54 ` Eugenie V. Lyzenko <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Eugenie V. Lyzenko @ 2016-03-26 22:54 UTC (permalink / raw)
Hi,
> 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.
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.
> Thanks,
> -Chap
Regards,
Eugenie.
Software developer,
Golden Code Development Corporation(www.goldencode.com)
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2016-03-26 22:54 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-03-22 16:20 [Pljava-dev] Building PLJava on Solaris issues Eugenie V. Lyzenko <[email protected]>
2016-03-23 02:14 ` Chapman Flack <[email protected]>
2016-03-23 17:26 ` Eugenie V. Lyzenko <[email protected]>
2016-03-26 21:12 ` Chapman Flack <[email protected]>
2016-03-26 22:17 ` Eugenie V. Lyzenko <[email protected]>
2016-03-26 22:32 ` Chapman Flack <[email protected]>
2016-03-26 22:54 ` Eugenie V. Lyzenko <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox