Cross-wrapping for 32-bit Linux


I upgraded. Why is 32-bit Linux no longer listed as a target for cross-wrapping?


In order to build a wrapped file for 32-bit Linux, there must be an available 32-bit Linux version of the Perl you have installed on your build system.

Community Edition/Business Edition ActivePerls 5.20 and higher do not provide versions for 32-bit Linux.

As of 2016, all of the ActivePerls which support cross-wrapping for 32-bit Linux require a Business Edition license.

Compatibility when wrapping or cross-wrapping for Linux


When I test my wrapped or cross-wrapped application on Linux, it crashes and reports "version `GLIBC_2.14' not found..."


This is an expected error message if you are wrapping for 64-bit Linux with 5.20 and 5.22 Perls, and run the resulting file on a Linux kernel that is too old (RHEL 5 and 6 are most frequent).

Wrapped files have the same system requirements as the native ActivePerl version. ActivePerl 5.20 and 5.22 require glibc 2.15 or higher.

To built a wrapped file that will run on an older version of Linux, you must wrap with an ActivePerl where the requirements for 64-bit Linux are only glibc 2.5 or higher. As of 2016, all of these Perls require Business Edition licenses.

Corrupted Files when running the ActivePerl Linux installer


When I run the installer, it reports that several files are corrupted. I see this error:
This installer package does not have the expected content. Please try to download a fresh copy of ActivePerl from ActiveState's website at If you still have problems please contact us at SupportEmail.

How do I fix this?


---Updated 10/18:
This FAQ applies to ALL ActivePerl Linux tarball installers.
A link to a current version has been specified solely for convenience
There are two possible causes.

1) If you used the command line "tar" to extract the archive, and tar reported this:
"tar: Removing leading / from member names"
the version of tar you have installed is removing leading slashes by default as a security measure. This will break the ActivePerl installer. Delete the extracted folder and run tar with different options.
"tar -zxPf (filename for the ActivePerl installer tarball with extensions.)"

2) If you allowed your browser to extract the tarball, it will have use the Linux Archive Manager. Trash the ActivePerl folder you extracted. Download a fresh copy, and do not open the Download with the Linux Archive Manager.
Go to a Terminal Window, and extract the file on the command line, using GNUtar instead:
You may still hit the leading slash issue if your tar has that default behaviour.

When the Ruby debugger bails out with an obscure error message (Linux 64-bit)


When I try to use the Ruby debugger, on a 64-bit Linux machine, stops after giving this error message:

Error: cannot load such file --

What should I do?


So is a Ruby C-extension that is used by the debugger, and
normally can be completely ignored. It was a bit puzzling why Ruby wasn't
loading this file, as it was clearly present and on Ruby's library load

I got the customer who reported this problem to fire up irb, cd'ed to
the directory containing, and run `require 'trace_nums19'`.
He reported this error message:

irb(main):002:0> require './trace_nums19'
LoadError: cannot open shared object file: No such file or
directory -
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from (irb):2
        from /usr/bin/irb:12:in `<main>'

The customer had /usr/lib/ installed, but not libruby-so.1.9
I see that rvm installs in each directory, and then
creates symbolic links and pointing to it, so the
libruby-so.M-N form looks correct. But this naming is inconsistent -- Python
puts the version numbers before the ".so" extension, while Perl and Ruby
typically put them after.

Anyway, the simple fix was to run

cd /usr/lib
sudo ln -s

Komodo IDE and Right-to-Left (RTL) Languages


Will Komodo work with Farsi, Hebrew or some Asian languages that are read right to left?


Komodo unfortunately does not work with right-to-left languages, as mentioned in our Komodo IDE release notes, due to a limitation in the text editor component.

Komodo Edit 4.2.1 upgrade to 4.3 (Linux libcpp5)


Why won't Komodo Edit 4.2.1 upgrade to version 4.3?


We are no longer publishing updates for the Komodo Edit libstdc++5 builds. If you find Komodo Edit is not updating, check under "Help|About Komodo" for the following build information:

Komodo Edit, version 4.2.1, build 283000, platform linux-libcpp5-x86.
Built on Tue Nov 13 14:03:05 2007.

Check this FAQ to see if you can run the libcpp6 build instead:

If you are unable to use this build, and would still like to upgrade to get the newest features, consider building Komodo Edit from the Open Komodo repository:

Why doesn't Ctrl-Shift-U lower-case a selection on Linux


The Code menu gives a keybinding of "Ctrl+Shift+U" for "Make Lowercase", but when I try this, the selection is replaced by the letter "u" and the cursor no longer moves. What's going on?


Some Linux platforms use the Shift-Ctrl-U as an signal to move into an in-place Unicode Input Method Editor (IME), and Komodo can't override that to implement the lowercase-selection command. However this isn't the case on all Linux platforms, and we can't have Komodo determine it at runtime either.

If you're on Unix, you can use the Preferences|Editor|Key Bindings to assign this command to a new key binding; I found [Ctrl K + L] is as memorable as the default key sequence, and it isn't being used.

If you do end up in this IME mode, you can press the Escape key to get out of it.

Komodo 4 on Ubuntu/x86_64


How to install and run Komodo 4 on Ubuntu Linux x86_64


The complete solution for installing and running Komodo4 with the 64-bit Ubuntu build is this:

sudo apt-get install libc6-i386 ia32-libs ia32-libs-gtk

Works fine after that.

NOTE: Installing just libc6-i386 lets the install script perform the installation. But running the program generates this error message:

error while loading shared libraries:

Installing the other two packages (ia32-libs and ia32-libs-gtk) fixes that part.

[from bug 67932]

CGI Debugging: 'No Input File specified'


When I try to debug PHP using CGI Emulation, I get this error:

No input file specified.


This is because your PHP CGI interpreter has been compiled with cgi.force_redirect set to on for security reasons. We can fix this in Komodo by changing this setting in the copy of php.ini that Komodo uses:

- open the php.ini copy that Komodo is using:


- change the setting:

; cgi.force_redirect = 1


cgi.force_redirect = 0

Save the php.ini, then try debugging using CGI Emulation again.