Trying to call "make" on Apache Mesos, after fixing some other javadocs related issues, this is what i'm currently getting.
Anyone ran into the same issues?
Here is the trace:
/Library/Java/JavaVirtualMachines/openjdk-12.0.2.jdk/Contents/Home/bin/javac -h java/jni \
-classpath java/target/mesos-1.10.0.jar:/Users/hanshenriksande/Master/mesos/build/src/java/target/protobuf-java-3.5.0.jar \
../../src/java/src/org/apache/mesos/MesosExecutorDriver.java
Note: ../../src/java/src/org/apache/mesos/MesosExecutorDriver.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
An exception has occurred in the compiler (12.0.2). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for com.google.protobuf.GeneratedMessageV3 not found
make[1]: *** [java/jni/org_apache_mesos_MesosExecutorDriver.h] Error 4
make: *** [all-recursive] Error 1
Do you need java bindings for Mesos? If not then run --disable-java and --disable-python see auto tools options.
If you need this bindings then you need to downgrade your JVM to 7 or 8. Follow these instructions
Related
I was trying to build OpenJDK 9 in Centos 5. I used
sh ./configure --disable-warnings-as-errors
make all
I am getting the following error.
Building target 'all' in configuration 'linux-x86_64-normal-server-release'
/root/jdk9/build/linux-x86_64-normal-server-
release/support/native/java.base/libjava/io_util_md.o: In function
`handleSetLength':
/root/jdk9/jdk/src/java.base/unix/native/libjava/io_util_md.c:228:
undefined reference to `fallocate64'
collect2: ld returned 1 exit status
/usr/bin/objcopy: '/root/jdk9/build/linux-x86_64-normal-server-
release/support/modules_libs/java.base/libjava.so': No such file
gmake[3]: *** [/root/jdk9/build/linux-x86_64-normal-server-
release/support/modules_libs/java.base/libjava.so] Error 1
gmake[2]: *** [java.base-libs] Error 2
ERROR: Build failed for target 'all' in configuration 'linux-x86_64-normal-
server-release' (exit code 2)
=== Output from failing command(s) repeated here ===
* For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
/root/jdk9/build/linux-x86_64-normal-server-
release/support/native/java.base/libjava/io_util_md.o: In function
`handleSetLength':
/root/jdk9/jdk/src/java.base/unix/native/libjava/io_util_md.c:228:
undefined reference to `fallocate64'
collect2: ld returned 1 exit status
* All command lines available in /root/jdk9/build/linux-x86_64-normal-
server-release/make-support/failure-logs.
=== End of repeated output ===
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See common/doc/building.html#troubleshooting for assistance.
make[1]: *** [main] Error 2
make: *** [all] Error 2
I also tried other make targets such as make images and make install. But still getting the same error. My GCC version is gcc (GCC) 4.4.7 which I manually installed because Centos 5 by default has an older version.
Building JDK requires at least GCC 5.0 (see Building the JDK: CC).
This seems to be a problem in the glibc version (see redhat-issue, util-linux). So, updating your glibc to the latest version might solve it.
If you don't want to update your system's glibc, here is another alternative:
By looking at the man page of fallocate, we find that the description mentions that posix_fallocate(3) is a portable, POSIX.1-specified version of it, in case the mode parameter has the default value (0). The same applies to fallocate64.
Since all the occurrences of the aforementioned error already use the default mode value, you can replace them with posix_fallocate64() (instead of commenting them out as you mentioned in another comment).
The denoted man page says that:
This default behavior [of fallocate with mode=0] closely resembles the
behavior of the posix_fallocate(3) library function, and is intended
as a method of optimally implementing that function.
I'm trying to install java jdk 8 onto an ubuntu 16.04 instance using chef-run. Although when it attempts to install I get Failed to converge target, when I open the logs I have the following:
[2018-06-21T20:24:34+01:00] ERROR: Remote chef-client error follows:
[2018-06-21T20:24:34+01:00] ERROR: SyntaxError: /var/chef-workstation/cache/cookbooks/windows/resources/share.rb:275: syntax error, unexpected end-of-input, expecting keyword_end
I have the following structure in my chef-repo:
cookbooks
-- jdk
-- attributes
-- default.rb
-- recipes
-- default.rb
metadata.rb
Within attributes/default.rb:
default['java']['install_flavor'] = 'openjdk'
default['java']['jdk'] = '8'
Within recipes/default.rb:
include_recipe 'java'
Within metadata.rb:
name 'name'
maintainer 'maintainer'
maintainer_email 'maintainer_email#email.com'
license 'MIT'
description 'Installs/Configures java'
long_description 'Installs/Configures java'
version '0.1.0'
chef_version '>= 12.14' if respond_to?(:chef_version)
depends 'java', '~> 2.1.0'
I can't see what the error is being caused by. Any help on this would be appreciated.
Edit:
If it helps the command i'm using with arguments is the following:
chef-run -i ~/.ssh/key jack#host jdk
This issue should be resolved in the latest stable version 0.1.139.
This is a bug in ChefDK 3.0 when using policy tarball exports. It will be fixed in ChefDK 3.1 next week. In the mean time, add this to your knife.rb config file:
require "mixlib/archive/lib_archive"
Mixlib::Archive::LibArchive.define_singleton_method(:new) { raise LoadError }
Just make sure you remove it when you upgrade to 3.1.
Can you please tell me, is this possible to remove Java JDK package with Chef, with windows_package, or I have to execute command to silent uninstall? Much better would be the first option.
I've tried this way:
windows_package node['name']['JDK1.6'] do
action :remove
end
and even added option installer_type :custom, still got this error:
FATAL: Mixlib::ShellOut::ShellCommandFailed: windows_package[Java(TM) SE Development Kit 6 Update 35] (line 4) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0, 42, 127], but received '1603'
---- Begin output of MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn ----
STDOUT:
STDERR:
---- End output of MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn ----
Ran MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn returned 1603
Well, I am out of ideas. On official Opscode site I've found this information:
:remove: remove a package. The remove action is completely hit or miss as many application uninstallers do not support a full silent/quiet mode.
But as far as I know, JDK supports silent uninstall.
So - how should I do this in order to properly uninstall packages? Is this even possible?
Many thanks for every help.
Specification:
Chef 12.4.1
Windows 7
Java JDK in versions: 6u35, 7u79, 8u45
If you need additional information, feel free to ask.
Well, I've ended up with my own implementation. For those, who would need this, too:
# variable 'code' is for JDK version code from registry.
# Uninstall comand: MsiExec.exe /quiet /X[CODE]
# Codes are in regkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Be aware to check key for JDK, not JRE!
remove_command = "MsiExec.exe /quiet /X#{code}"
execute "Remove JDK from system" do
command remove_command
returns [0,1605] # 1605 for non-existing product error
end
For example, for JDK 1.6.35 (mentioned in question) code should be
code = '{32A3A4F4-B792-11D6-A78A-00B0D0160350}'
So it seems like this is different command than used by Chef:
used by Chef
MsiExec.exe /I{32A3A4F4-B792-11D6-A78A-00B0D0160350} /qn
this command
MsiExec.exe /quiet /X{32A3A4F4-B792-11D6-A78A-00B0D0160350}
Maybe somebody will find this useful.
This looks like it might not be a chef problem as such. The uninstaller is hitting an error for some reason. Try googling for "java install error 1603" and you'll see a bunch of posts, including one that's apparently a bug that's currently under investigation https://www.java.com/en/download/help/error_1603.xml - though it sounds like that might be install not uninstall.
Try removing it manually and debug that, then once you understand it you can chef it.
I did something similar to your answer, but it only requires the package name rather than the code from the registry.
execute 'uninstall_jdk8u72' do
command "wmic product where name=\"#{node[:java8u72][:package_name]}\" call uninstall"
end
I got the idea from https://github.com/chef-cookbooks/windows/issues/89
I've got a Tomcat webapp where I'm using AspectJ for logging and metrics, everything seems fine, but it keep creating several files like ajcore.20150310.113255.780.txt in the root folder. There is no exception in this files, so they are completely useless.
I've found this: https://eclipse.org/aspectj/doc/released/pdguide/ajcore.html
That states that using org.aspectj.weaver.Dump.exception="false" should disable this behavior, yet the files are still appearing. Is there any other way to completely disable the creation of this files? The other option mentioned: org.aspectj.dump.directory would also solve the problem, but it doesn't seem to work either.
This is the content of the file in case it helps for anything:
---- AspectJ Properties ---
AspectJ Compiler 1.7.1 built on Thursday Sep 6, 2012 at 16:39:22 GMT
---- Dump Properties ---
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
Dump on exception: true
Dump at exit condition: abort
---- Exception Information ---
---- System Properties ---
... My system properties here
---- Command Line --- Empty
---- Full Classpath --- Empty
---- Compiler Messages --- Empty
Either of the following options may help:
Executing this code before any AspectJ weaving occurs (if possible): org.aspectj.weaver.Dump.setDumpOnExit(org.aspectj.bridge.IMessage.ABORT)
Adding this system property definition to your java command-line: -Dorg.aspectj.weaver.Dump.condition=abort
I think it is good that the AJ core dump happens because something seems to go wrong during LTW compilation:
Dump file: ajcore.20150310.113255.780.txt
Dump reason: org.aspectj.weaver.BCException
So there is an exception and you should investigate and fix it. Maybe some of your classes are woven with the logging code correctly and some are not. Run the weaver in verbose mode and check your console output, maybe you see something strange there. An AJ core file means that the weaver/compiler was shut down completely (abnormal termination).
As for the actual problem, I think that this
---- Command Line --- Empty
looks strange, as if no command line parameters were passed to the weaver. Also that no exception is actually logged is really unusual.
Which Java version are you on? I assume Java 7 because 1.6 is really old and Java 8 needs AspectJ 1.8. Anyway, can you try to use the latest AspectJ version 1.8.5 or at least the latest 1.7.4 from the old release and see if the problem still occurs?
Add this argument to your JVM run: -Dorg.aspectj.weaver.Dump.exception=false
And also see official docs
I want to do something with the HypergraphDB in Java. I'm not very familiar with this language and IDE Netbeans.
I followed steps describing the HGDB installation:Link to tutorial
Now I want to write an example in Java (using NetbeansIDE).
So I created new project, added refferences to the downloaded libraries. OK, now I'm able to import packages with HGDB. The only thing I have in my main method is HyperGraph HG = new HyperGraph(dbLocation);. This code compiles. But get following runtime error:
run:
checkpoint kbytes:0
checkpoint minutes:0
java.lang.IllegalStateException: There is 1 existing transaction opened against the Environment.
Aborting open transactions ...
aborting <Transaction id="28">
at com.sleepycat.je.Environment.close(Environment.java:383)
at org.hypergraphdb.storage.bje.BJEStorageImplementation.shutdown(BJEStorageImplementation.java:178)
at org.hypergraphdb.HGStore.close(HGStore.java:355)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:392)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:213)
at org.hypergraphdb.HyperGraph.<init>(HyperGraph.java:200)
at hgdbtest.HgdbTest.main(HgdbTest.java:16)
Exception in thread "main" org.hypergraphdb.HGException: java.lang.NoSuchMethodError: org.hypergraphdb.storage.bje.LinkBinding.objectToEntry(Ljava/lang/Object;Lcom/sleepycat/je/DatabaseEntry;)V
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:395)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:213)
at org.hypergraphdb.HyperGraph.<init>(HyperGraph.java:200)
at hgdbtest.HgdbTest.main(HgdbTest.java:16)
Caused by: java.lang.NoSuchMethodError: org.hypergraphdb.storage.bje.LinkBinding.objectToEntry(Ljava/lang/Object;Lcom/sleepycat/je/DatabaseEntry;)V
at org.hypergraphdb.storage.bje.BJEStorageImplementation.store(BJEStorageImplementation.java:234)
at org.hypergraphdb.HGStore.store(HGStore.java:119)
at org.hypergraphdb.HGTypeSystem.addPrimitiveTypeToStore(HGTypeSystem.java:185)
at org.hypergraphdb.HGTypeSystem.bootstrap(HGTypeSystem.java:234)
at org.hypergraphdb.HyperGraph.open(HyperGraph.java:355)
... 3 more
Java Result: 1
BUILD SUCCESSFUL (total time: 4 seconds)
I guess it's caused by the native API of the BerkeleyDB.
According to the tutorial, in project options I supply the -Djava.library.path=$HGDB_ROOT/lib/native/$PLATFORM argument on Run card as a VM Option. Instead of the system variables I use full-path to the libraries.
My OS in Windows7. I'm not sure about using slashes or backslashes or double-backslashes as a path-separator.?
So a simply question is: how have I to set up the IDE for using the HypergraphDB?
Thank you for advices!
Judging from the stack trace, you are using the latest version of HyperGraphDB. In that version, the native API is not used. Rather, it's Java only libraries. You have to include the BerkeleyDB Java Edition 5.0.34 jar in your runtime classpath. You can get it either from the Oracle http://www.oracle.com/technetwork/products/berkeleydb/downloads/index.html or from the HyperGraphDB Maven repository: http://hypergraphdb.org/maven/org/hypergraphdb/hgbdbje/1.2/hgbdbje-1.2.jar
I had the same issue. I fixed it (by accident) by fixing the order of the libraries on which you're HyperGraphDB application relies on. The library je-[version].jar has to be ABOVE (and hence to be referenced before) db-[version].jar