Module | PhusionPassenger::PlatformInfo

In:

lib/phusion_passenger/platform_info.rb
lib/phusion_passenger/platform_info/ruby.rb
lib/phusion_passenger/platform_info/curl.rb
lib/phusion_passenger/platform_info/binary_compatibility.rb
lib/phusion_passenger/platform_info/compiler.rb
lib/phusion_passenger/platform_info/linux.rb
lib/phusion_passenger/platform_info/zlib.rb
lib/phusion_passenger/platform_info/apache.rb
lib/phusion_passenger/platform_info/operating_system.rb

Users can change the detection behavior by setting the environment variable `APXS2` to the correct ‘apxs’ (or ‘apxs2’) binary, as provided by Apache.

### Methods

apache2_bindir apache2_module_cflags apache2_module_ldflags apache2_sbindir apache2ctl apr_config apr_config_needed_for_building_apache_modules? apr_flags apr_libs apu_config apu_flags apu_libs apxs2 cc compiler_supports_architecture? compiler_supports_no_tls_direct_seg_refs_option? compiler_supports_visibility_flag? compiler_supports_wno_attributes_flag? compiler_supports_wno_missing_field_initializers_flag? compiler_visibility_flag_generates_warnings? cpu_architectures curl_flags curl_libs curl_supports_ssl? cxx debugging_cflags env_defined? export_dynamic_flags find_command gem_command gnu_make has_alloca_h? has_math_library? httpd httpd_version in_rvm? library_extension linux_distro linux_distro_tags locate_ruby_tool os_name passenger_binary_compatibility_id portability_cflags portability_ldflags rake rake_command requires_no_tls_direct_seg_refs? rspec ruby_command ruby_executable ruby_extension_binary_compatibility_ids ruby_sudo_command ruby_supports_fork? rvm_path rvm_ruby_string supports_lfence_instruction? supports_sfence_instruction? tmpdir tmpexedir zlib_flags zlib_libs

### Classes and Modules

Class PhusionPassenger::PlatformInfo::RuntimeError

### Constants

GEM_HOME | = | gem_home
RUBY_ENGINE | = | ::RUBY_ENGINE
RUBY_ENGINE | = | "ruby"

### Public Class methods

apache2_bindir()

The absolute path to the Apache 2 ‘bin’ directory, or nil if unknown.

apache2_module_cflags(with_apr_flags = true)

The C compiler flags that are necessary to compile an Apache module. Also includes APR and APU compiler flags if with_apr_flags is true.

apache2_module_ldflags()

Linker flags that are necessary for linking an Apache module. Already includes APR and APU linker flags.

apache2_sbindir()

The absolute path to the Apache 2 ‘sbin’ directory, or nil if unknown.

apache2ctl()

The absolute path to the ‘apachectl’ or ‘apache2ctl’ binary, or nil if not found.

apr_config()

The absolute path to the ‘apr-config’ or ‘apr-1-config’ executable, or nil if not found.

apr_config_needed_for_building_apache_modules?()

Returns whether it is necessary to use information outputted by ‘apr-config’ and ‘apu-config’ in order to compile an Apache module. When Apache is installed with —with-included-apr, the APR/APU headers are placed into the same directory as the Apache headers, and so ‘apr-config’ and ‘apu-config’ won‘t be necessary in that case.

apr_flags()

The C compiler flags that are necessary for programs that use APR.

apr_libs()

The linker flags that are necessary for linking programs that use APR.

apu_config()

The absolute path to the ‘apu-config’ or ‘apu-1-config’ executable, or nil if not found.

apu_flags()

The C compiler flags that are necessary for programs that use APR-Util.

apu_libs()

The linker flags that are necessary for linking programs that use APR-Util.

apxs2()

The absolute path to the ‘apxs’ or ‘apxs2’ executable, or nil if not found.

cc()
compiler_supports_architecture?(arch)

Checks whether the compiler supports "-arch #{arch}".

compiler_supports_no_tls_direct_seg_refs_option?()
compiler_supports_visibility_flag?()
compiler_supports_wno_attributes_flag?()
compiler_supports_wno_missing_field_initializers_flag?()
compiler_visibility_flag_generates_warnings?()

Returns whether compiling C++ with -fvisibility=hidden might result in tons of useless warnings, like this: code.google.com/p/phusion-passenger/issues/detail?id=526 This appears to be a bug in older g++ versions: gcc.gnu.org/ml/gcc-patches/2006-07/msg00861.html Warnings should be suppressed with -Wno-attributes.

cpu_architectures()

Returns a list of all CPU architecture names that the current machine CPU supports. If there are multiple such architectures then the first item in the result denotes that OS runtime‘s main/preferred architecture.

This function normalizes some names. For example x86 is always reported as "x86" regardless of whether the OS reports it as "i386" or "i686". x86_64 is always reported as "x86_64" even if the OS reports it as "amd64".

Please note that even if the CPU supports multiple architectures, the operating system might not. For example most x86 CPUs nowadays also support x86_64, but x86_64 Linux systems require various x86 compatibility libraries to be installed before x86 executables can be run. This function does not detect whether these compatibility libraries are installed. The only guarantee that you have is that the OS can run executables in the architecture denoted by the first item in the result.

For example, on x86_64 Linux this function can return ["x86_64", "x86"]. This indicates that the CPU supports both of these architectures, and that the OS‘s main/preferred architecture is x86_64. Most executables on the system are thus be x86_64. It is guaranteed that the OS can run x86_64 executables, but not x86 executables per se.

Another example: on MacOS X this function can return either

"x86_64", "x86"
  or ["x86", "x86_64"]. The former result indicates

OS X 10.6 (Snow Leopard) and beyond because starting from that version everything is 64-bit by default. The latter result indicates an OS X version older than 10.6.

curl_flags()
curl_libs()
curl_supports_ssl?()
cxx()
debugging_cflags()

C compiler flags that should be passed in order to enable debugging information.

env_defined?(name)
export_dynamic_flags()
find_command(name)

Check whether the specified command is in $PATH, and return its absolute filename. Returns nil if the command is not found.

This function exists because system(‘which’) doesn‘t always behave correctly, for some weird reason.

gem_command()

Returns the correct ‘gem’ command for this Ruby interpreter.

gnu_make()
has_alloca_h?()
has_math_library?()
httpd()

The absolute path to the Apache binary (that is, ‘httpd’, ‘httpd2’, ‘apache’ or ‘apache2’), or nil if not found.

httpd_version()

The Apache version, or nil if Apache is not found.

in_rvm?()

Returns whether the current Ruby interpreter is managed by RVM.

library_extension()

The current platform‘s shared library extension (‘so’ on most Unices).

linux_distro()

An identifier for the current Linux distribution. nil if the operating system is not Linux.

linux_distro_tags()

Autodetects the current Linux distribution and return a number of identifier tags. The first tag identifies the distribution while the other tags indicate which distributions it is likely compatible with. Returns nil if the operating system is not Linux.

locate_ruby_tool(name)

Locates a Ruby tool command, e.g. ‘gem’, ‘rake’, ‘bundle’, etc. Instead of naively looking in $PATH, this function uses a variety of search heuristics to find the command that‘s really associated with the current Ruby interpreter. It should never locate a command that‘s actually associated with a different Ruby interpreter. Returns nil when nothing‘s found.

os_name()

Returns the operating system‘s name. This name is in lowercase and contains no spaces, and thus is suitable to be used in some kind of ID. E.g. "linux", "macosx".

passenger_binary_compatibility_id()

Returns an identifier string that describes the current platform‘s binary compatibility with regard to Phusion Passenger binaries, both the Ruby extension and the C++ binaries. Two systems with the same binary compatibility identifiers are able to run the same Phusion Passenger binaries.

The the string depends on the following factors:

- The Ruby extension binary compatibility identifiers.
- The operating system name.
- Operating system runtime identifier. This may include the kernel version, libc version, C++ ABI version, etc. Everything that is of interest for binary compatibility with Phusion Passenger‘s C++ components.
- Operating system default runtime architecture. This is not the same as the CPU architecture; some CPUs support multiple architectures, e.g. Intel Core 2 Duo supports x86 and x86_64. Some operating systems actually support multiple runtime architectures: a lot of x86_64 Linux distributions also include 32-bit runtimes, and OS X Snow Leopard is x86_64 by default but all system libraries also support x86. This component identifies the architecture that is used when compiling a binary with the system‘s C++ compiler with its default options.

portability_cflags()

Compiler flags that should be used for compiling every C/C++ program, for portability reasons. These flags should be specified as last when invoking the compiler.

portability_ldflags()

Linker flags that should be used for linking every C/C++ program, for portability reasons. These flags should be specified as last when invoking the linker.

rake()

Returns the absolute path to the Rake executable that belongs to the current Ruby interpreter. Returns nil if it doesn‘t exist.

The return value may not be the actual correct invocation for Rake. Use rake_command for that.

rake_command()

Returns the correct command string for invoking the Rake executable that belongs to the current Ruby interpreter. Returns nil if Rake is not found.

requires_no_tls_direct_seg_refs?()
rspec()

Returns the absolute path to the RSpec runner program that belongs to the current Ruby interpreter. Returns nil if it doesn‘t exist.

ruby_command()

Returns correct command for invoking the current Ruby interpreter. In case of RVM this function will return the path to the RVM wrapper script that executes the current Ruby interpreter in the currently active gem set.

ruby_executable()

Returns the full path to the current Ruby interpreter‘s executable file. This might not be the actual correct command to use for invoking the Ruby interpreter; use ruby_command instead.

ruby_extension_binary_compatibility_ids()

Returns an array of identifiers that describe the current Ruby interpreter‘s extension binary compatibility. A Ruby extension compiled for a certain Ruby interpreter can also be loaded on a different Ruby interpreter with the same binary compatibility identifiers.

The identifiers depend on the following factors:

- Ruby engine name.
- Ruby extension version. This is not the same as the Ruby language version, which identifies language-level compatibility. This is rather about binary compatibility of extensions. MRI seems to break source compatibility between tiny releases, though patchlevel releases tend to be source and binary compatible.
- Ruby extension architecture. This is not necessarily the same as the operating system runtime architecture or the CPU architecture. For example, in case of JRuby, the extension architecture is just "java" because all extensions target the Java platform; the architecture the JVM was compiled for has no effect on compatibility. On systems with universal binaries support there may be multiple architectures. In this case the architecture is "universal" because extensions must be able to support all of the Ruby executable‘s architectures.
- The operating system for which the Ruby interpreter was compiled.

ruby_sudo_command()

Returns either ‘sudo’ or ‘rvmsudo’ depending on whether the current Ruby interpreter is managed by RVM.

ruby_supports_fork?()

Returns whether the Ruby interpreter supports process forking.

rvm_path()

If the current Ruby interpreter is managed by RVM, returns the directory in which RVM places its working files. Otherwise returns nil.

rvm_ruby_string()

If the current Ruby interpreter is managed by RVM, returns the RVM name which identifies the current Ruby interpreter plus the currently active gemset, e.g. something like this: "ruby-1.9.2-p0@mygemset"

Returns nil otherwise.

supports_lfence_instruction?()

Returns whether the OS‘s main CPU architecture supports the x86/x86_64 lfence instruction.

supports_sfence_instruction?()

Returns whether the OS‘s main CPU architecture supports the x86/x86_64 sfence instruction.

tmpdir()
tmpexedir()

Returns the directory in which test executables should be placed. The returned directory is guaranteed to be writable and guaranteed to not be mounted with the ‘noexec’ option. If no such directory can be found then it will raise a PlatformInfo::RuntimeError with an appropriate error message.

zlib_flags()
zlib_libs()

[Validate]