Can't get JRuby to work on AIX machine - jruby

I looked everywhere and I can't find any help on how to get JRuby to work on AIX. I tried unpacking the binary package, tried using the jruby-complete.jar but I stumble on the same problems.
All errors seem to occur because JRuby is looking in the wrong directories for lib files.
For instance, I set my GEM_PATH=/home/dev999/install_tmp/gem and then I try to require activerecord-jdbc-adapter, which is installed under ./gem/gems/activerecord-jdbc-adapter-1.3.12, but for some reason JRuby keeps looking for the gem under ./gem/gems/activemodel-4.1.8/lib as shown below.
dev-host:/home/dev999/install_tmp$ jruby -e "require 'activerecord-jdbc-adapter'"
Errno::ENOENT: ENOENT - /home/dev999/install_tmp/gem/gems/activemodel-4.1.8/lib/activerecord-jdbc-adapter
file? at org/jruby/RubyFileTest.java:131
contains_requirable_file? at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/basic_specification.rb:46
any? at org/jruby/RubyEnumerable.java:1473
contains_requirable_file? at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/basic_specification.rb:46
any? at org/jruby/RubyEnumerable.java:1473
contains_requirable_file? at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/basic_specification.rb:44
find_inactive_by_path at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/specification.rb:898
find at org/jruby/RubyEnumerable.java:592
find_inactive_by_path at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/specification.rb:897
try_activate at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems.rb:183
require at /usr/local/jruby-1.7.16.1/lib/ruby/shared/rubygems/core_ext/kernel_require.rb:132
(root) at -e:1
Any insights on what may be causing this are greatly appreciated.
EDIT: The server is an AIX 64 bits; we tried Java 1.6 and 1.7 both 64 and 32 bits (IBM custom build for AIX) but we ended up sticking with 1.7 64 bits in the final solution, although the version doesn't seem to affect the issues found in the Ruby 1.7.9 installation, but since we couldn't get JRuby 1.7.16 to work, I can't be sure if the Java builds we used could have played part in the problem.

OK, so the server admin and I spent two days trying to figure these things out and I can finally summarize the solution we ended up with to get JRuby working on AIX_64.
1 . First and most important of all, I had to install JRuby 1.7.9 since the 1.7.16 stable version from the main download page in jruby.org has many (seemingly AIX specific) bugs that we could not figure out; for instance, the wrong gem path resolution shown in my original question. Version 1.7.9 sorts out most of the issues automatically;
2) For some weird reason that I'm still unable to figure out, jirb won't work with the jline-2.11.jar lib that comes with the downloaded JRuby package. At some point I got it to work but then I could not retrace my steps so I gave up. To sort this issue out I downloaded jline-1.0.jar and replaced the jline jar located under <jruby_path>/lib/ruby/shared/readline/jline-2.11.jar; please note that even if we are replacing this with jline-1.0, the jar file name must still be the same i.e. jline-2.11.jar otherwise jirb will complain about a missing lib;
3) Some common steps: add jruby/bin to $PATH; make sure which java shows the correct Java version you want to use; set $JAVA_HOME;
4) (Optional, but very useful) in order to avoid having to grant my user write access to the /usr/<jruby>/<gem_paths> directories but still allow me to install gems without having to ask the admin I added export GEM_PATH=~/.gem to my .profile, then mkdir ~/.gem. To install gems to my home directory I do jgem install <gem_name> -i $GEM_PATH.
Hopefully this helps other users struggling with the same problems.

My main suggestion is to join the jruby mailing list and ask there. I've used jruby just once and managed to get it working. Here is a bit of magic that I don't really understand that I have at the top of one of the first files I require:
# We need the db2j.jar loaded
require 'db2j.jar'
# Some feaking magic Java needs
Java::JavaClass.for_name 'com.ibm.db2j.jdbc.DB2jDriver'
# The connection string is jdbc:db2j:the/path/to/the/file where the
# file is actually a directory.
CloudscapeDriver = 'jdbc:db2j'
You can see the email thread here: http://comments.gmane.org/gmane.comp.lang.jruby.user/17856
good luck

Related

What exactly needs to be included in a RubyMine custom Ruby configuration, esp. for debugging?

I usually use rvm, but also need to work with a custom Ruby build. I understand that when I go to the RubyMine "Settings", "Languages & Frameworks", "Ruby SDK and Gems" dialog, I need to press "+" and select "New Local with Custom Configurator".
On that dialog, the Ruby interpreter path is self explanatory, but I don't know which environment variables I need to specify in the "Custom Configurator" session. What information needs to go there?
I am using RubyMine 2021.1 on both Mac OS and Linux. I need to be able to debug, which means that when RubyMine installs the debug support gems, they need to go to the right location, and be found from that location.
It turned out that all I needed to specify there was my GEM_HOME:
env GEM_HOME=/opt/my-custom-ruby/gems/2.7.0
I was surprised that I didn't also need to explicitly set the path to the directory containing the Ruby interpreter (for commands other than ruby, such as bundle), but I guess RubyMine does that for me. Or, maybe it doesn't, and I just haven't encountered an error yet.
Edit: It turns out I did have an issue with a gem not being found. I added to that env command and the problem went away, but I'm not really sure yet if that was the issue or if adding both GEM_PATH and PATH were necessary. Here is what I wound up with:
env GEM_HOME=/opt/my-custom-ruby/gems/2.7.0 GEM_PATH=/opt/my-custom-ruby/gems/2.7.0 PATH=/opt/my-custom-ruby/bin/ruby:$PATH
EDIT 2021-12-24
I just tried this again on a new installation and the above did not work. I was getting build errors saying that I needed to install the development tools. It turned out that when specifying the path in the
Custom Configurator field I needed to include the path for the gcc compiler. I just put most of the paths in my login PATH value there, and the gem installation succeeded.

"Fatal error: 'EXTERN.h' file not found" while installing Perl modules

While trying to install Perl modules like JSON::XS or YAML::XS, i receive the same error:
XS.xs:1:10: fatal error: 'EXTERN.h' file not found
I use MacBook, xCode is up to date, everything else that could help is up to date too.
Since OS X El Capitan, Apple introduced System Integrity Protection which restricts writing to /usr/lib /usr/bin and other sensitive directories (even to root or sudo user) that are used by the installation of Perl bundled with the Operating System. This can cause issues when it comes to installing new modules and also if trying to install XS modules ( those linked to external C libraries ).
For this reason you should not consider the default Perl installation as a working development environment, especially if you are installing custom modules.
Check out this thread on PM and others. I had since El-Capitan managed to solve this before by manually building from tarball and adding a few params or environment variables to set the paths believing that it would be best to retain use of the system Perl but this is not the way to go. This makes your environment difficult to build but also brittle and sensitive to OS updates that may either break things in many different ways.
The best practice seems to be starting with a Perl using brew install perl and work in this environment, remembering to setup your bash_profile as directed by the installer.
Also worth remembering to do a brew link perl. If you receive warnings about this clobbering what looks like system Perl libraries don't worry - these are likely modules that were installed by you over the top and it will cause you less trouble to link over these. If you have concerns, make a note of which module installs will be cleared and re-install them once your environment is configured ( ie your module installer approach is configured using cpanm or sticking with the old perl -MCPAN -e shell etc)
This new Perl setup from brew eliminates the need to continuing running sudo which adds another layer of things that can go wrong as environment variables don't follow through and permission conflicts arise etc.
Finally to simplify package/module installation I suggest doing a brew install cpanminus. If you had previously already installed this, you can ensure the paths etc are configured by doing a brew reinstall cpanminus
If you want to take it another step further then you can install perlbrew as well which will give you the ability to run multiple versions of Perl as your user and configure these with their own libs and modules which can be very useful particularly if aligning with your production environment for testing etc.
One problem you may face if moving from system Perl to this kind of approach is needing to deal with any hangovers from installing things with sudo. It wis worth taking a little time to get all this set up right though and your issues going forward will be greatly reduced and you won't be left with that nagging feeling that you don't want to change anything for fear of it all breaking.
I have also come across a Perl Blog Article that suggests a fix for XS issues with perlbrew on Mojave
This Gist described updating your cpan shell install root though this shouldn't be necessary unless your cpan is stuck in an old config after taking steps above.
I've also raised this as a new issue on PerlMonks
After reading https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035624 and installing the Additional headers via
sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
I successfully compiled without the missing 'EXTERN.h' error
In order to follow the common advice I also tried with Perlbrew to install a dedicated development version of Perl. Especially with the advice in mind First, do not use the system Perl on MacOS. The installed version is for Apple, not for you (see the discussion here: https://www.perlmonks.org/?node_id=1224727).
Unfortunately, the following error occurred:
Test Summary Report
-------------------
porting/libperl.t (Wstat: 65280 Tests: 35 Failed: 0)
Non-zero exit status: 255
Parse errors: No plan found in TAP output
Files=2653, Tests=1217766, 708 wallclock secs (52.74 usr 9.40 sys + 395.38 cusr 49.90 csys = 507.42 CPU)
Result: FAIL
make: *** [test_harness] Error 1
##### Brew Failed #####
Therefore, I decided to install it the following way (and not following the advice due to the error).
Even after having the above mentioned macOS SDK headers already installed on Catalina (macOS 10.15.2) it didn't work for me. I faced the issue during the installation of the Perl module Mac-SystemDirectory-0.13. The following steps (by identifying the missing file in hope of having a more generic approach for more or less equivalent issues) did the trick:
Locate the header file (in this case EXTERN.h)
sudo find /Library -type f -name EXTERN.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/EXTERN.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.28/darwin-thread-multi-2level/CORE/EXTERN.h
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/EXTERN.h
Ensure the installed Perl version (here 5.18) match the header file:
perl -v | grep version
This is perl 5, version 18, subversion 4 (v5.18.4) built for darwin-thread-multi-2level
Export the path for the C-Compiler (note MacOSX10.15.sdk for Catalina and Perl Version 5.18)
export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE
Invoke the Makefile.PL with perl
perl Makefile.PL
BTW — For anybody who's still struggling with this, my workaround was:
bash% module="Sub::Util" # For example
bash% cpanm --configure-args="INC=-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE" "$module"
Please try this
CPATH=$(dirname $(find /usr/local/Cellar/ -name EXTERN.h)) cpan JSON::XS
For Big Sur and perl 5.30, EXTERN.h is at /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/System/Library/Perl/5.30/darwin-thread-multi-2level/CORE
I'm trying to upgrade CPAN itself and got that error. But I have /usr/bin/cpan and I can't write there so I have to tweak it to write the updated version to /usr/local/bin/cpan.
No promises, but yum install perl-devel worked for me.
As #huyz has helpfully pointed out, if you hit this error on a Mac, you don't have this option, even though this is probably your issue, and you need to follow one of the above methods of getting a version of Perl that isn't missing important chunks, as per other answers.
But if, dear reader, you hit this error on a linux host, as I did, then this might be an option for you.
Building on what E Lisse suggested, you might also have luck looking in
/System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/
For example:
CPATH=$(dirname $(find /System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/ -name EXTERN.h)) cpan JSON::XS
You could also find where EXTERN.h is located and add that to your shell by default, e.g. in your .bashrc or .zshrc file:
export CPATH=/System/Volumes/Data/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE/

SMW+ installation in MAMP

I'm trying to instal SMW+ on MAMP on top of an existing Semantic Mediawiki (that installation went fine).
First problem: in Step 3 of the official SMW+ installation guide, the WYSIWYG editor doesn't have a link, and the SMWHalo extension locks up my wiki.
So, in Step 6, I've had to comment out # include_once('extensions/SMWHalo/includes/SMW_Initialize.php'); enableSMWHalo(); and require_once("$IP/extensions/WYSIWYG/WYSIWYG.php");
I figured it was related to SMWHalo on both counts. So, I hop over to the Halo Extension installation guide, which leads me to the Wiki Admin Tool installation guide (no link because I'm a noob), which is where I get stuck. I can't get smwadmin to become executable to save my life chmod +x smwadmin.sh returns nothing, and using smwadmin after that gives me "-bash: smwadmin: command not found"
And there, I'm stuck. My wiki still works just fine with those three lines commented out, but I obviously lose SMW+ functionality.
Any suggestions?
Just switch to regular SMW and use the Semantic Bundle to get a jumpstart. I'm afraid the SMW+ project, for all intents and purposes, is now dead :(

Can't get Lazarus to do.....anything?

So I thought I would install Lazarus/Free pascal -latest version from the sourceforge website.
Downloaded the win32 version and install on my XP machine couple of nights ago.
Problem is, it can't seem to find any of its own files.
From the first and every subsequent run it comes up with an error which says it can't find its system.ppu file relating to win32.
I just ignore that error and it seems to still run.
I tried to make a simple calculator application and it couldn't even seem to find the system files or files in the project directory. After battling these problems and setting every single path I could find in all the setups to every directory I could find it eventually compiled and run the program - once, not been able to make it do it again.
I also tried to make a user component library following the instructions on the web and that won't work either because, you guessed it, it can't the files. This time it gives an error saying it can't find a Ttreeview component, despite not even using that component in the library.
Being able to follow search paths is pretty fundamental stuff that they don't seem to have mastered.
Anybody managed to get a working system going, or any tips to sort these problems out?
Did you install in the default directory c:\lazarus? I thought there was an issue with installing to another directory, especially if the path contains spaces.
Nine times out of ten, its the old config of an earlier Lazarus attempt, that still lingers somewhere in the "local app" part of the profile.
If nothing else helps uninstall Lazarus, download Lazarus CodeTyphon edition, and run install as admin.

CLSQL on CentOS installation

I want to connect to MySQL from SBCL using CLSQL. I loaded CLSQL using quicklisp (ql:quickload 'clsql). However, when calling (clsql:connect '(...) :database-type :mysql), it said:
Couldn't load foreign libraries "libmysqlclient", "libmysql". (searched CLSQL-SYS:FOREIGN-LIBRARY-SEARCH-PATHS).
I'm on CentOS, and basically what I want to do is
Install mysql client development headers with yum, so UFFI can find it (which I failed to do)
after installing, be able to connect to local MySQL server (I think after 1. is done, it could be working automatically).
I'm currently using:
CentOS 5.7 Final (32 bit)
SBCL 1.0.55
Quicklisp beta
yum repositories: base, epel, extras, updates
I didn't just ask about how to install MySQL development headers on CentOS, because that would solve only part of my problem, I would still need to know what's missing from my machine. I also didn't try to build libmysqlclient/libmysql from source, because I don't know whether clsql would be able then to find it or not. I think not.
I'm really sorry if my question somehow misses the point, but extensive googling didn't yield any results. If anyone told me they couldn't install mysql client development headers on CentOS, I would laugh at them and tell them to use yum search, but I couldn't find it neither with yum neither online.
I know the solution for ubuntu (and debian), because there is a cl-sql package and I can easily find mysql headers there too, but I need it on CentOS.
Thanks in advance.
Somehow, when you try something long enough, it will get done ;)
Here's what I did if anyone needs an answer and stumbles upon this question:
(ql:quickload 'clsql)
;tell clsql where to search for mysql libs
(push #P"/usr/lib/mysql" CLSQL-SYS:*FOREIGN-LIBRARY-SEARCH-PATHS*)
;add mysql libs to clsql library path [apparent from code :]
(clsql:push-library-path "/usr/lib/mysql/")
;directly tell uffi to load mysqlclient shared library
(uffi:load-foreign-library "/usr/lib/mysql/libmysqlclient.so")
Of course, you can replace "/usr/lib/mysql" with a different path for mysql libraries, if needed.