![]() |
![]() |
|
APLXTM for Linux Technical Support |
|
APLX for LinuxThe latest release of APLX for Linux Personal Edition available free of charge is Version 1.1.9, released 21 June 2004. The latest paid version is Version 4.1.12, released 3rd March 2009. If you are running an earlier release, we recommend that you download the appropriate Upgrade Pack from the APLX Download page. Supported Linux distributionsAPLX for Linux runs on most x86 and x86_64 Linux distributions. It has been tested by MicroAPL (or on behalf of MicroAPL) on the following (all are x86 unless otherwise specified); however some distributions need minor changes to the 'startaplx' script as described below:
Users of APLX on a wide variety of other Linux distributions have reported no problems. Problems installing APLX for Linuxa. The installer exits with the message: "Your system does not meet the minimum system requirements" APLX for Linux requires recent versions of certain system components, such as the GLIBC shared library. The installer attempts to determine which versions are installed before continuing. For complete information of these requirements, please see the document "pre_install.txt" in the APLX file set. If you are satisfied that your system meets the installation prerequisites and that the installer is incorrectly detecting older versions etc., you can force the installation to proceed by setting an environment variable before running the installer: FORCE_APLX_INSTALL=1 sh setup.sh b. Installing under Linux distributions for AMD 64-bit CPUs (or Intel EM64T): You CAN install and run the standard 32-bit version of APLX as a 32-bit application on x86_64 versions of Linux (for example, Fedora Core 5 x86_64). However, when you try to install, you may get a message "This installation does not support glibc-2.1 on x86_64". To work around this, you need to create a symbolic link in one of the subdirectories of the installer. Start by bringing up a command-line prompt (as root user) and 'cd' to the directory where the main 'setup.sh' install script is located. Now navigate to one of the subdirectories: cd setup.data/bin Now put in a symbolic link: ln -s x86 x86_64 Finally, go back to the main directory and try the install again. Note: If you want to take full advantage of the 64-bit processor and the huge memory addressing it provides, you will need to purchase the 64-bit version of APLX. Problems starting APLX for Linux:c. "startaplx: command not found" The APLX installer creates a symbolic link to the APLX launcher "startaplx" using the "Link Path" you specify during installation. Normally, this link should be created somewhere in the normal executable search path, so that the "startaplx" command can be used from any directory. If you see the error message above, either the link is not in your normal executable search path, or a more serious problem has occurred during installation. First check that the "startaplx" program exists in the APLX install directory. e.g. if you installed to "/opt/aplx/", there should be an executable file "/opt/aplx/bin/startaplx". If this does not exist, the installation has failed. Please repeat the installation and look for any messages in the shell window. If "startaplx" does exist in the APLX installation directory, it is simply a problem with your search path. The easiest solution is to create a new symbolic link manually somewhere in your search path. Display your search path: echo $PATH The result should look something like this: .:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/tom/bin Create a new link ln -s /opt/aplx/bin/startaplx /usr/local/bin/startaplx "/opt/aplx/bin/startaplx" is the real file you are linking to, and will depend on where APLX is installed. "/usr/local/bin/startaplx" is the link you are creating, and should be in a directory that is listed in your $PATH. d. "Error in loading shared libraries: XXX.so.YYY: cannot open shared object file" Most distributions of Linux have all the shared libraries needed to run APLX. Some versions have the correct libraries, but do not use the naming conventions APLX is expecting. This normally occurs when version numbers are included in the name where APLX is not expecting version numbers. If you see the error message above, check for files in "/lib" and "/usr/lib" which have similar names to the missing file. If the library is present, you can easily fix the problem by creating a symbolic link to the existing library using the name under which APLX is looking for the library. As an example, if APLX is missing "libFOO.so.8", but you find "libFOO.so.8.2.0" in "/usr/lib", you can fix the problem by creating a link ln -s /usr/lib/libFOO.so.8.2.0 /usr/lib/libFOO.so.8 e. The operating system reports "Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed." Make sure you are running APLX for Linux Version 1.1.9 or later. f. The operating system reports something like: "Error while loading shared libraries: /usr/local/aplxpe/bin/libborqt-6.9.0-qt2.3.so: cannot restore segment prot after reloc: Permission denied" This is a problem with SELinux, a feature in Linux designed to make the operating system more secure. Unfortunately it causes incompatibilities with many applications, including APLX. The problem shows up particularly in RedHat distributions. You can work around the problem by adding: setenforce 0 to the startaplx script, before APLX is invoked Problems using APLX for Linux:g. The APLX font is not displaying correctly. APL symbols do not appear in the APLX session window or editor windows. h. The APLX font does not print correctly. APL symbols do not appear in the printed output. If APLX starts up correctly, but APL symbols do not display and/or print, the APLX fonts have not installed correctly. Before continuing, try to restart your system as indicated in installation step 8. If the problem occurs after a restart, please see the file "fonts/README.txt" in the APLX installation directory. i. Typing in APLX produces unexpected letters, digits or symbols. i. Unknown or unsupported keyboard layout In order to produce the special APL symbols, APLX modifies the behaviour of the keyboard. APLX uses the $LANG environment variable to determine your normal keyboard layout. Although $LANG should normally always be set, some Linux configurations do not seem to do so. To check your current $LANG environment setting: echo $LANG If this shows no $LANG value, or prints 'C' you should modify your log-in script or the startaplx script to set $LANG to one of the supported options. (See below). ii. NUM-LOCK In some X-windows keyboard configurations, having NUM-LOCK set interferes with the APLX key mapping process. The easiest solution is to turn off NUM-LOCK when using APLX. For more information, please see the man page for "xmodmap". j. When you bring up the keyboard layout window, APLX displays up a warning: "Keyboard layout from the LANG environment variable not recognized. Key positions on the APL keyboard map may not be correct." This means that the $LANG environment variable is not set to one of the standard strings which APLX recognizes. These are listed in the 'README.txt' file in the APLX 'keymaps' directory. If $LANG is not set to one of these, you can set it for APLX alone by modifying the 'startaplx' script in the APLX 'bin' directory. For example, if you are using a US keyboard, $LANG should be set to 'en_US'. (Some versions of Linux including RedHat 9.0 might set it to something different, such as 'en_US.utf-8'). You can fix the problem by adding the following line to your startaplx script (before aplxlinux is invoked): LANG=en_US;export LANG If you are using a non-US keyboard, substitute one of the other language strings described in 'keymaps/README.txt'. For example, if you are using a Swiss German keyboard you would enter: LANG=de_CH;export LANG k. APLX starts to run, but apparently crashes randomly with the message: "Fatal IO error: client killed" This arises because of an incompatibility introduced in the Linux kernel version 2.4 and later. In fact, APLX has not crashed but the X-Windows subsystem has terminated the X session. This occurs in RedHat 9.0 and Mandrake 9.1 (and probably in other distributions issued later than around May 2003), if you are running APLX version 1.1.7 or earlier. APLX versions 1.1.8 and later include a fix for this problem. l. APLX fails to start, with a message like " ../../../util-common/delphiuw.c:580: Assertion `!SavedRegs|| (ProcRelOffs > PushRegsOffs)' failed." This is probably caused by the 'exec-shield' security feature in some Linux distributions. See comp.lang.apl for a description and workaround. m. APL symbols do not display properly in the Help window. This problem may arise where the system libraries are attempting to translate APL text to UTF-8 Unicode. You can fix the problem by adding the following lines to your startaplx script (before aplxlinux is invoked): LANG=en_US;export LANG If you are using a non-US keyboard, substitute one of the other language strings described in 'keymaps/README.txt'. For example, if you are using a Swiss German keyboard you would enter: LANG=de_CH;export LANG n. APL symbols display correctly, but do not print correctly. Each printed symbol is preceded by a garbage character. The fix m. above should fix this.
|
Copyright © 1996-2010 MicroAPL Ltd