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]> 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-23 02:14 Chapman Flack <[email protected]> parent: 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-23 17:26 Eugenie V. Lyzenko <[email protected]> parent: 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-26 21:12 Chapman Flack <[email protected]> parent: 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-26 22:17 Eugenie V. Lyzenko <[email protected]> parent: 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-26 22:32 Chapman Flack <[email protected]> parent: 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-26 22:54 Eugenie V. Lyzenko <[email protected]> parent: Chapman Flack <[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