When I type
$ drillbit.sh start
it shows me this error:
ERROR: Java 1.7 or later is required to run Apache Drill.
although I have the latest version of java
$ java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
also my $JAVA_HOME is set correctly in .profile
What could cause such issue?
Well, after investgating a little bit I have found that the config file drill-config.sh
checks the java version with bad regex:
"$JAVA" -version 2>&1 | grep "version" | egrep -e "1.4|1.5|1.6" > /dev/null
if [ $? -eq 0 ]; then
fatal_error "Java 1.7 or later is required to run Apache Drill."
fi
The regex "1.4" matches 144 which is the update number in java version I have.
So the floating point should be escaped to be "1\.4"
And this finally solved my problem.
There is already a Jira to fix this:
https://issues.apache.org/jira/browse/DRILL-5698 and open PR.
Related
When I run MDART routing protocol tcl script in NS 2.35, it says:
When configured, ns found the right version of tclsh in /usr/bin/tclsh8.6
but it doesn't seem to be there anymore, so ns will fall back on running the first tclsh in your path. The wrong version of tclsh may break the test suites. Reconfigure and rebuild ns if this is a problem.
num_nodes is set 16
INITIALIZE THE LIST xListHead
channel.cc:sendUp - Calc highestAntennaZ_ and distCST_
highestAntennaZ_ = 1.5, distCST_ = 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0
SORTING LISTS ...DONE!
Segmentation fault (core dumped)
And the simulation end time supposely end at 205s but when run the animation, the simulation end at 8s. Why is that? Thanks
ns found the right version of tclsh in /usr/bin/tclsh8.6
but it doesn't seem to be there anymore
tcl8.6 : You are supposed to use the "ns-2.35 tcl8.5.10" : It doesn't change version or location. (Unless you move ns-allinone-2.35). The external tcl8.6 can change with e.g. an update. And later versions tend to be missing some files, e.g. in Debian / Ubuntu.
Example https://drive.google.com/file/d/0B7S255p3kFXNVVlxR0ZNRGVORjQ/view?usp=sharing
$ tar xvf ns-allinone-2.35_gcc5.tar.gz ## 2014 - 2017 update
$ cd ns-allinone-2.35/
$ export CC=gcc-4.8 CXX=g++-4.8 && ./install
Segmentation fault
MDART cannot be used with a contemporary OS. The latest that worked was an Ubuntu 18.04.4 updated 16 months ago. Please see my tests https://drive.google.com/drive/folders/1si2jA3lc-23lubVHb3tFbIAXfnhRfg5O?usp=sharing ..... CentOS 8 fails, Ubuntu 20.04 fails. Etc. "2021 OS" fails.
EDIT : Further tests revealed that an updated Ubuntu 18.04 failed : The latest Ubuntu version for MDART is 16.04 .
NOTE 1: The Ubuntu 16.04 nam package is corrupt. Please use https://drive.google.com/file/d/0B7S255p3kFXNdmxzSmRzaVRWb28/view?usp=sharing → nam_1.15-10-ubuntu14_amd64.deb
NOTE 2: The Ubuntu 16.04 ns command : sudo apt install ns2
NOTE 3: Building ns-allinone-2.35/ → Four cases of random Tk errors after the latest Ubuntu updates. Possible solutions: Use ns-allinone-2.35_2021.tar.xz https://drive.google.com/file/d/167cP7hPnJGiNL3rK4Mxnh_-0t7_S8FTL/view?usp=sharing with Tcl, Tk updated to version 8.5.17 .... And there are three options for extra gcc/g++ compilers to try out https://drive.google.com/drive/folders/1xVEATaYAwqvseBzYxKDzJoZ4-Hc_XOJm?usp=sharing
export CC=gcc447 CXX=g++447 && ./install ## can also be used with ns-allinone-2.35 version 2011
export CC=gcc48 CXX=g++48 && ./install
export CC=gcc54 CXX=g++54 && ./install
Simulation time : The setting is maximum time. Example : The setting set val(end) 1006.0 will run about 6 seconds and end the output text with : 1000 simulation seconds ....... Time is relative. ns2 was developed in the 90th when processors were very slow Pentium 1 / Pentium 2 . ... And different protocols behave different with simulation time.
I am looking for an advisable version of JRuby that supports OpenJDK-8 (Zulu-JDK) to run on a Rails project.
Rails version- 4.0.13.
All versions of JRuby since version 9.2.0.0 will run on JDK 8. Since Zulu 8 is a build of OpenJDK 8 that means any appropriate JRuby version will run on Zulu 8.
Follow up question (using answer section to get better code formatting then commenting on the answer above).
I'm trying to get JRuby > 9.2.0.0 running Zulu 8 for MacOS ARM 64-bit (M1 chip).
I did a reinstall of the JRuby versions after installing that JDK.
$ rvm list
jruby-1.7.27 [ x86_64 ]
=> jruby-9.2.13.0 [ aarch64 ]
Check ruby version and try irb:
$ ruby -v
jruby 9.2.13.0 (2.5.7) 2020-08-03 9a89c94bcc OpenJDK 64-Bit Server VM 25.302-b08 on 1.8.0_302-b08 +jit [darwin-aarch64]
$ irb
NotImplementedError: fstat unimplemented unsupported or native support failed to load; see https://github.com/jruby/jruby/wiki/Native-Libraries
initialize at org/jruby/RubyIO.java:1015
open at org/jruby/RubyIO.java:1156
initialize at /Users/rrickerts/.rvm/rubies/jruby-9.2.13.0/lib/ruby/stdlib/irb/input-method.rb:141
initialize at /Users/rrickerts/.rvm/rubies/jruby-9.2.13.0/lib/ruby/stdlib/irb/context.rb:70
initialize at /Users/rrickerts/.rvm/rubies/jruby-9.2.13.0/lib/ruby/stdlib/irb.rb:410
start at /Users/rrickerts/.rvm/rubies/jruby-9.2.13.0/lib/ruby/stdlib/irb.rb:381
<main> at /Users/rrickerts/.rvm/rubies/jruby-9.2.13.0/bin/irb:13
On make I get this error:
libtool: Version mismatch error. This is libtool 2.4.6.42-b88ce, but the
libtool: definition of this LT_INIT comes from libtool 2.4.6.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6.42-b88ce
libtool: and run autoconf again.
I run aclocal && autoconf && ./configure && make -j4.
I make again and I get the same error! Very unexpected...
I started examining generated libtool script.
# Which release of libtool.m4 was used?
macro_version=2.4.6
macro_revision=2.4.6
...
PROGRAM=libtool
PACKAGE=libtool
VERSION=2.4.6.42-b88ce
package_revision=2.4.6.42
So the issue is these .42-b88ce and .42 suffixes. Where do they come from?
I re-installed libtool with apt-get.
I check its version.
dev0#DESKTOP-KK30DO1:~$ apt list --installed | grep libtool
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libtool/stable,now 2.4.6-9 all [installed]
Here we see that it is actually 2.4.6-9, i.e. with -9 suffix.
Okay... What is going on here? Where do these .42-b88ce and .42 suffixes come from? How to solve the error? Please help to understand the issue.
P.S. System info (uname -a):
Linux DESKTOP-KK30DO1 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux
Replying to myself.
These suffixes were in the initial ltmain.sh distributed within the library package that I'm trying to build. The reason of these suffixes is likely that the previous developer have built libtool from the source code (so b88ce and .42 suffixes can be the hash of the last commit and the patch number).
The solution is to re-generate ltmain.sh by executing libtoolize [1]. Please note that OSX users should use glibtoolize (since OSX has its own command with the similar name libtool).
The final build sequence is:
libtoolize && aclocal && autoconf && automake && ./configure && make -j4
References:
https://www.gnu.org/software/automake/manual/html_node/Error-required-file-ltmain_002esh-not-found.html
I compiled ejabberd 15.07 (make install, using a prefix for destination).
I am under Linux Mint 16 (based on Ubuntu 13.10) with the distro's erlang package (version R16B01).
I also tested on Ubuntu 12.04 using Erlang OTP 18.0 (erlang compiled myself and ejabberd compiled using --with-erlang, distro's packages are not installed).
ejabberd works perfectly fine in both environments except that the erlang.log file is not created, basically no erlang SASL logs at all.
I upgraded from distro's ejabberd v2.1.10 where that file used to contain a bunch of supervisor logs or component crash/restarts.
Looking at ejabberdctl script, it actually does set the sasl_error_logger file like it always did in the past (e.g. in versions 2.x).
If I do
gperrot#tristan ~/apps/ejabberd/sbin $ su -c 'erl -sasl sasl_error_logger \{file,\"/home/gperrot/apps/ejabberd/var/log/ejabberd/erlang.log\"\}'
Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false]
Eshell V5.10.2 (abort with ^G)
1> application:start(sasl).
ok
I can get a erlang.log file created with some content.
I used bash -x ejabberdctl start to check the command it uses:
sh -c '/usr/bin/erl -sname ejabberd#localhost -noinput -detached -pa /home/gperrot/apps/ejabberd/lib/ejabberd/ebin -mnesia dir "\"/home/gperrot/apps/ejabberd/var/lib/ejabberd\"" -ejabberd log_rate_limit 100 log_rotate_size 10485760 log_rotate_count 1 log_rotate_date '\''""'\'' -s ejabberd -sasl sasl_error_logger \{file,\"/home/gperrot/apps/ejabberd/var/log/ejabberd/erlang.log\"\} +K true -smp auto +P 250000 start ""'
File path is set properly, same user running, same file permissions.
I don't understand why I get no erlang.log file managed by ejabberd.
SASL is correctly started:
gperrot#tristan ~/apps/ejabberd/sbin $ ejabberdctl debug
(ejabberd#localhost)1> application:start(sasl).
{error,{already_started,sasl}}
And in ejabberd.log I also get
2015-09-04 17:29:51.252 [info] <0.7.0> Application sasl started on node ejabberd#localhost
But not erlang.log file.
Any idea why?
I used a little Jruby script from http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-ruby.html to test invokedynamic:
class ADuck
def quack()
puts "quack A";
end
end
class BDuck
def quack()
puts "quack B";
end
end
def quack_it(duck)
duck.quack
end
a = ADuck.new
b = BDuck.new
quack_it(a)
quack_it(b)
But when I compile in with JRuby to Java classfiles and then try to execute it I get the following exception:
Java HotSpot(TM) 64-Bit Server VM warning: Use -XX:+UnlockDiagnosticVMOptions be
fore EnableInvokeDynamic flag
Exception in thread "main" java.lang.ClassCastException: java.lang.Object cannot
be cast to java.lang.invoke.SwitchPoint
at org.jruby.runtime.invokedynamic.InvokeDynamicSupport.constantFallback
(InvokeDynamicSupport.java:659)
at duck_typing.__file__(duck_typing.rb:22)
at duck_typing.load(duck_typing.rb)
at duck_typing.main(duck_typing.rb)
My system: JDK 1.7.0_09 64bit on Windows 7 64bit, JRuby 1.7.2
Used commandlines:
jruby -Xcompile.invokedynamic=true -S jrubyc duck_typing.rb
java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -cp .;jruby-complete-1.7.2.jar duck_typing
A while ago I tested it on linux machine with same results and on Windows jdk8.
With JDK8 it worked, but gave me problems using the classfiles in another project.
Has anyone a idee how to fix it?
How can I use JRuby with indy on Java 7?
Except for the JRuby convenience parameter --server, all JVM runtime
parameters use the -J option, followed by the specific JVM setting.
For example:
Heap space settings: jruby -J-X
JRuby runtime settings: jruby -J-D
All the settings described in the following sections are JVM settings.
https://github.com/jruby/jruby/wiki/PerformanceTuning
try this instead
jruby -J-Xcompile.invokedynamic=true -S jrubyc duck_typing.rb