Building FAQ
Subscribe

From OpenNMS

Revision as of 13:18, 29 April 2010 by Ajb (Talk | contribs)

Jump to: navigation, search

I get an error about "conflicting types for 'unsetenv'" when compiling opennms-iplike

This is the error in more detail:

In file included from /opt/csw/postgresql/include/server/c.h:822,
                 from /opt/csw/postgresql/include/server/postgres.h:48,
                 from /home/dgregor/opennms/trunk/opennms/opennms-iplike/opennms-iplike-solaris/../src/main/native/iplike.c:47:
/opt/csw/postgresql/include/server/port.h:323: error: conflicting types for 'unsetenv'
/usr/include/stdlib.h:188: error: previous declaration of 'unsetenv' was here
/opt/csw/postgresql/include/server/port.h:323: error: conflicting types for 'unsetenv'
/usr/include/stdlib.h:188: error: previous declaration of 'unsetenv' was here

This seems to be due to the PostgreSQL configure script incorrectly determining that the OS does not have an "unsetenv" function. Add "-Dbuild.postgresql.compiler.arg=-DHAVE_UNSETENV" to your build.sh command-line and that should take care of it. E.g.:

JAVA_HOME=/usr/java ./build.sh \
    -Dbuild.postgresql.compiler.arg=-DHAVE_UNSETENV \
    -Dopennms.home=/opt/opennms \
    install assembly:directory-inline

I get an error about "'_FILE_OFFSET_BITS' redefined" when compiling opennms-iplike

This is the error:

In file included from /opt/csw/postgresql/include/server/c.h:53,
                 from /opt/csw/postgresql/include/server/postgres.h:48,
                 from /home/dgregor/opennms/trunk/opennms/opennms-iplike/opennms-iplike-solaris/../src/main/native/iplike.c:46:
/opt/csw/postgresql/include/server/pg_config.h:663:1: "_FILE_OFFSET_BITS" redefined
In file included from /usr/include/iso/ctype_iso.h:30,
                 from /usr/include/ctype.h:18,
                 from /home/dgregor/opennms/trunk/opennms/opennms-iplike/opennms-iplike-solaris/../src/main/native/iplike.c:41:
/usr/include/sys/feature_tests.h:188:1: this is the location of the previous definition

This seems to be due to the PostgreSQL configure script incorrectly determining that the OS does not set _FILE_OFFSET_BITS. Add "-Dbuild.postgresql.compiler.arg=-DUNDEF_FILE_OFFSET_BITS" to your build.sh command-line and that should take care of it. You will most likely also need to set the -DHAVE_UNSETENV compiler option mentioned above, as well. E.g.:

JAVA_HOME=/usr/java ./build.sh \
    -Dbuild.postgresql.compiler.arg="-DHAVE_UNSETENV -DUNDEF_FILE_OFFSET_BITS" \
    -Dopennms.home=/opt/opennms \
    install assembly:directory-inline

Weird errors when building opennms-icmp or related packages like 'Unable to copy dependency to staging area' or 'Error searching for native class in dependencies'

The build does not currently work well in a few areas when doing "./build.sh compile" instead of "./build.sh install", and this is one of them. You are most likely doing a "./build.sh compile" from the top-level when you get this error. Switch to "./build.sh install", and it should go away.

There is an open bug for this, but it's a pretty low-priority. It's bug 1542. You can do "build.sh compile" for most sub-projects, it just doesn't work for some sub-projects and it doesn't work reliably (or at all?) from the top-level. In cases where you have problems, try an "install" instead and see if that fixes the problem.

javah fails with "The major.minor version '49.0' is too recent ..."

Here's an example of the full error:

[INFO] javah -d /opt/opennms/opennms-icmp/opennms-icmp-jni/opennms-icmp-jni-linux/target/
native/javah -classpath /opt/opennms/opennms-icmp/opennms-icmp-jni/opennms-icmp-jni-linux/
target/classes:/opt/opennms/opennms-icmp/opennms-icmp-api/target/opennms-icmp-api-1.3.3-
SNAPSHOT.jar:/root/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar 
org.opennms.protocols.icmp.IcmpSocket
Exception in thread "main" java.lang.ClassFormatError: The major.minor version '49.0' is too recent for 
this tool to understand.
        at sun.tools.java.BinaryClass.load(BinaryClass.java:105)
        at sun.tools.java.BinaryClass.load(BinaryClass.java:85)
        at com.sun.tools.javah.oldjavah.JavahEnvironment.getClass(JavahEnvironment.java:172)
        at com.sun.tools.javah.oldjavah.JavahEnvironment.getAllFields(JavahEnvironment.java:89)
        at com.sun.tools.javah.oldjavah.JNI.write(JNI.java:38)
        at com.sun.tools.javah.oldjavah.Gen.run(Gen.java:149)
        at com.sun.tools.javah.oldjavah.Main.run(Main.java:174)
        at com.sun.tools.javah.oldjavah.Main.main(Main.java:41)
        at com.sun.tools.javah.Main.main(Main.java:40)

See bug #1873 for details and a workaround. The short answer is to make sure that a Java 1.5 version of "javah" is first in your path. Use "javah -version" to check versions.

I get weird dependency errors, hanging downloads or jar files in .m2 which aren't JAR files

This could well be an issue with the version of Maven you are running. The build script will honour the MVN environment variable and use your system Maven if you have told it to. Older version can have weird issues and it's not required as there is a known good copy of Maven bundled in the source tree.