So, I'm trying to get into LWJGL, and part of this is loading 3D models, and I thought I'd use JAssimp for this. The readme specifies two steps, building a native component, and a .jar component. The jar was just an ant build, and so it happened without incident. The part that's difficult is the native library. I've been trying to link it, without success. I've included the assimp include directories, included Java's headers, and linked to JAssimp's assimp.lib. However, I still get these errors:
jassimp.obj : error LNK2019: unresolved external symbol _aiImportFile referenced in function _Java_jassimp_Jassimp_aiImportFile#20
jassimp.obj : error LNK2019: unresolved external symbol _aiReleaseImport referenced in function _Java_jassimp_Jassimp_aiImportFile#20
jassimp.obj : error LNK2019: unresolved external symbol _aiGetErrorString referenced in function _Java_jassimp_Jassimp_aiImportFile#20
C:\Users\Kevin\Downloads\assimp-3.1.1-win-binaries\port\jassimp\jassimp-native\src\Release\Jassimp.dll : fatal error LNK1120: 3 unresolved externals
Googling around leads to mostly the same question, but with no answers, and one guy on facepunch that apparently found a solution, but pulled an https://xkcd.com/979/ and never mentioned how. Obviously, I've missed linking to some library, but I'm not sure what else to link to, Assimp only provided me one, and I'm not sure what else I need. Am I installing it wrong?
For anyone else who stumbles across this with the same problem, the answer is to do it the old-fashioned way and compile the C++ Assimp yourself. This will give you, (among other things) a new assimp.lib. Link with this instead of the one provided, and the error will go away.
How To Build
I) buiid the primary shared object libassimp.so: issue these commands in AssImp/assimp-3.2
a. cmake CMakeLists.txt -G 'Unix Makefiles'
b. make
c. results in AssImp/assimp-3.2/lib
II) build the native library by issuing this command in jassimp-native/src:
a. $ gcc jassimp.cpp -I/usr/lib/jvm/java-7-openjdk-amd64/include/ \
-I/usr/lib/jvm/java-7-openjdk-amd64/include/linux \
-I/$HOME/AssImp/assimp-3.2/include \
-L/$HOME/AssImp/assimp-3.2/lib/libassimp.so -shared -fPIC -o libjassimp.so
libjassimp.so is required at runtime and must be located in java.library.path:
b. sudo cp /$HOME/AssImp/assimp-3.2/port/jassimp/jassimp-native/src/libjassimp.so /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/
III) Java binding
The java library is built using ant. Executing "ant" in the port/jassimp
directory should be sufficient to build the library including the docs.
The java build is configured to create java 1.6 classes
The Jassimp.jar file generated by the "ant" call has to be incorporated
in your build.xml file:
<target name="init">
<property name="imports" value="${libs}/jogl-all.jar:${libs}/gluegen-rt.jar:${libs}/jassimp.jar" />
<target name="compile" depends="prepare">
<compilerarg line="-Xlint -cp ${imports}" />
All of the above is the good news; I successfully built my code.
The bad news is that upon execution I received the following error:
java: symbol lookup error: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libjassimp.so: undefined symbol: aiImportFile
Related
I am trying to generate a java API using swagger-codegen (3.0.0)
I am using the swagger-codegen-cli-3.0.24.jar version of codegen jar.
I ran the following command to generate the SDK for the sample petstore project:
java -jar swagger-codegen-cli.jar generate -i code/swagger-codegen/modules/swagger-codegen/src/test/resources/3_0_0/petstore.json -l java -o out/pet-java
When I am compiling the generated sdk project:
cd out/pet-java
mvn clean package
I am getting the below error:
Compilation failure
[ERROR] out/pet-java/src/main/java/io/swagger/client/model/Pet.java:[87,34] cannot find symbol
[ERROR] symbol: method nextObject()
[ERROR] location: variable jsonReader of type com.google.gson.stream.JsonReader
it is using <gson-version>2.8.1</gson-version> as dependency.
Ultimately the real answer is for swagger-codegen to fix their regression. They've admitted that it's a problem. In the mean time I've worked around the issue for my particular situation. To demonstrate the types of changes that are necessary, see below:
In some files instead of nextObject(), there may be a call to next(). The solution is the same, however.
Apologies for any confusion in the diff. Apparently I left the original lines in the file commented out below the working replacement line.
I have developed a linux shared library to communicate with pos terminals. The library has been developed using C language, and the routines are imported in to a java program using JNI interface. I have tested the library with the simple Java class it works perfectly.how ever when I try to develop a front end java application using netbeans it pops up Unsatisfied link error . so i recompiled the library with the package name embedded in ever function call with in the shared library and the issue was resolved. I found the package name causes the specific error. Is there a way to come out from this problem. because I cant ask the client to keep the package name static. it should be able to change as they need. I tried several compiler and linker directive but failed ..The current working library has been compiled using the following command
gcc -shared -o libecr.so -fpic ecr.c -lusb-1.0
This compiles with no errors in Fedora 14.
libecr.so is my shared library
ecr.c is the source code file
lusb is the libusb which is referenced by ecr code
I'm trying to generate the documentation, using javadoc, from one or two downloaded jar files (with the source of course, after having extracted everything).
But using javadoc, even in an Ant file, I'm being prevented from generating this because of silly things, specifically "package XXX does not exist" and "cannot find symbol"... I just want javadoc to put the text of these things (external references) in the html docs, but to document all the .java files it finds...
NB for anyone interested this is the download page with the download files (containing source) from which I'm trying to generate the API documentation: http://logback.qos.ch/download.html
Following Mark Rotteveel's help, my Ant build file now looks like this:
<?xml version="1.0" ?>
<project name="document logback core" default="doc">
<target name="doc">
<mkdir dir="javadoc" />
<property name="excludedPackages"
value="org.codehaus.*,javax.mail.*"/>
<javadoc destdir="javadoc" sourcepath="src" packagenames="main.*"
excludepackagenames="${excludedPackages}"
additionalparam="-Xdoclint:none" />
</target>
</project>
... but it still gives errors 1) about packages not being found, including "org.codehaus.[xxx...]" and "javax.mail.[xxx...]" and 2) about symbols not being found (although this may go away if I can solve the missing packages errors).
NB the build is said to be successful, but I get complaints about no source files being found (where there are indeed commented .java files), and no html at all is generated under \javadoc.
later, following Tony Pierce's success in generating these docs
Installed Ant 1.9.6, changed path accordingly, checked to make sure this was the version being used... tried again. Failed again. This was the end of my output:
[javadoc]
D:\Desktop\Downloads\logback-1.1.7.tar\logback-1.1.7\logback-core\src\test\java\ch\qos\logback\core\appender\ConsoleAppenderTest.java:32:
error: package org.junit does not exist [javadoc] import static
org.junit.Assert.assertEquals; [javadoc]_______________________^
[javadoc] javadoc: error - No public or protected classes found to
document. [javadoc] 1 error [javadoc] 100 warnings
BUILD SUCCESSFUL Total time: 2 seconds
It does create the javadoc folder... but this is empty.
NB about the above "package does not exist" error (there were many others): this one is particularly mystifying as I thought Ant somehow included junit by default (NB I am a complete newbie at Ant, just working through "Ant in Action").
But... with the Ant javac task you can set includeAntRuntime="true" ... according to this book that makes Ant's own junit.jar be included. Unfortunately the javadoc task doesn't support this attribute.
later still
My thinking was a bit muddled on this, to be honest: the simplest way I have found to compile javadocs from third-party source jars is just by extracting and then using the command line, typically:
javadoc -d docs -Xmaxwarns 10 -Xmaxerrs 10 -Xdoclint:none -sourcepath
. -subpackages ch.qos.logback.core
... as for javadoc for one's own code this doesn't seem to be a problem in Gradle (I was only glimpsing at Ant, aware that the future is Gradle... and it's not particularly difficult to get to grips with the basics).
NB If you install the Gradle STS plugin for Eclipse, and then create a new project using Gradle STS wizard your build file contains the line
apply plugin: 'eclipse'
... one of the effects of which is that by default the source as well as the executables for all your third-party dependencies will be downloaded under GRADLE_HOME during the build. Pretty good!
Java 8 introduced doclint which will treat certain problems as an error and not produce the documentation. It is possible to disable this by specifying the commandline option -Xdoclint:none.
See also: Turning off doclint in JDK 8 Javadoc
Eg in Ant you would need to do add a additionalparam="-Xdoclint:none" attribute to the javadoc task. A (slightly modified) example from Jaybird:
<target name="javadocs" depends="init,set-driver-sources">
<mkdir dir="${build.docs}"/>
<javadoc destdir="${build.docs}"
author="true"
version="true"
windowtitle="${Name} API"
doctitle="${Name}"
extdirs="${module.thirdparty}"
additionalparam="-Xdoclint:none"
excludepackagenames="${excludedPackages}"
bottom="Copyright © 2001-2015 Jaybird (Firebird JDBC/JCA) team. All rights reserved.">
<arg line="${java.module.arg}"/>
<classpath refid="javac.driver.classpath"/>
<sourcepath>
<pathelement path="${source.java}"/>
<pathelement path="${source.jna-client}"/>
</sourcepath>
<sourcepath refid="source.java.openoffice"/>
<sourcepath refid="source.java.additional"/>
<link href="http://docs.oracle.com/javase/7/docs/api/"/>
</javadoc>
</target>
Compile Errors With Custom Doclet with Java 9 or later
The -Xdoclint:none is an option of the standard doclet which will not work for custom doclets.
If you have a custom doclet and don't care about compilation errors, you can pass the --ignore-source-errors option either to the javadoc command line tool or to javax.tools.DocumentationTool.getTask(...) if you invoke your doclet programmatically.
The --ignore-source-errors option is not documented. Maybe because it might be removed in future. The clean way is to add all required libraries to the classpath (via the -classpath option to actually resolve the compilation errors).
I simplified your build file a bit and built the javadoc successfully. Here's what I did:
Downloaded the logback zip
Expanded the sources jars inside into a src directory
Ran ant 1.9.6 under java 8 with this:
<?xml version="1.0" ?>
<project name="document logback core" default="doc">
<target name="doc">
<mkdir dir="javadoc" />
<javadoc destdir="javadoc" sourcepath="src"
additionalparam="-Xdoclint:none" />
</target>
</project>
It produced a lot of warnings, but created a javadoc directory filled with html.
I removed excludepackagenames and dropped the packagenames element. In any case, packagenames="main.*" prevents the javadoc generation because the only root packages in the jar are ch and org.
When I attempt to run scons (2.3.0) to build a class from a SWIG interface file, scons fails to pick up all the generated files, either as being in the sourcepath, or to be included in the build (even with classpath set). Instead only two java files are attempted to be compiled, both of which fail because they are derived from other classes.
loc_env = env.Clone()
loc_env['JAVACLASSPATH']= ['build/$TARGET_ARCH/$TARGET_OS/.../java']
swig_j = loc_env.Java(target='.', source=['source_java.i']) #1
#swig_j = loc_env.Jar(target='.', source=['source_java.i']) #2
Both #1, and #2 fail to produce a result. #2 shows an error message that the source has not been accepted, and is a blank string, which I can accept, even with example code suggesting it should work.
For #1 The root cause seems to be in Scons/Tool/swig.py def _find_modules(src):, which has a regex to match all modules generated, but fails to account for any raw enums or other artefacts from wrapping up C code. When I had a hand-rolled makefile the classpath
For reference, The javac build instruction for #1 is:
javac -classpath build/x86_64/linux/.../java -d build/x86_64/linux/.../java/ -sourcepath build/x86_64/linux/.../java build/x86_64/linux/release/.../source.java build/x86_64/linux/release/.../sourceJNI.java
Is this a known bug (As part of SCONS' handling of 1->N mappings)? Is it a flaw in the Scons Parsing of .i files? or is it a more fundamental issue?
This is a bug in SCons. The changes slated for 2.5.0 fix the issue, by improving cross-language scanning. I look forwards to ripping out my hack sometime next year!
I'm new to protobufs and was trying to learn more about using them. I've downloaded the protobuf packaged from here. There is a README.txt file inside the examples folder of the archive which gives instructions on how to build 2 example applications. However when I follow those instructions for building the java application:
make java
I get a lot of errors followed by:
100 errors
make: * [javac_middleman] Error 1
All of the 100 errors seem to be classpath related, as this is a typical example:
com/example/tutorial/AddressBookProtos.java:37: error: package com.google.protobuf does not exist
Any ideas about how to get passed this?
The problem is that for some reason protobuf jar is not added to the classpath during compilation. To fix it you should open examples/Makefile and add -cp protobuf-java-2.4.1.jar at the end of java complilation line javac AddPerson.java ListPeople.java com/example/tutorial/AddressBookProtos.java.
P.S. If you built you protobufs with maven the jar is located at ~/.m2/repository/com/google/protobuf/protobuf-java/2.4.1/protobuf-java-2.4.1.jar (version of the jar might be different)