Pktgen failed to load Lua script - User State for CLI not set for Lua - lua

Running Pktgen with Lua scripts generates a failure User State for CLI not set for Lua.
The command I'm running is:
sudo -E ./usr/local/bin/pktgen --no-telemetry -l 4,6,8,10 -n 4 -a 0000:03:02.0 -m 1024 -- -T -P -m [6:8].0 -f test/hello-world.lua
Which gives the following result:
I have set the environment variables RTE_SDK=/root/Program/dpdk and
RTE_TARGET=x86_64-native-linux-gcc.
The failure comes from cli.c (link to code):
/**
* Load and execute a command file or Lua script file.
*
*/
int
cli_execute_cmdfile(const char *filename)
{
if (filename == NULL)
return 0;
gb_reset_buf(this_cli->gb);
if (strstr(filename, ".lua") || strstr(filename, ".LUA") ) {
if (!this_cli->user_state) {
cli_printf(">>> User State for CLI not set for Lua\n");
return -1;
}
if (lua_dofile) {
/* Execute the Lua script file. */
if (lua_dofile(this_cli->user_state, filename) != 0)
return -1;
} else
cli_printf(">>> Lua is not enabled in configuration!\n");
} else {
FILE *fd;
char buff[256];
fd = fopen(filename, "r");
if (fd == NULL)
return -1;
/* Read and feed the lines to the cmdline parser. */
while (fgets(buff, sizeof(buff), fd))
cli_input(buff, strlen(buff));
fclose(fd);
}
return 0;
}
So it would seem this_cli->user_state is not set, but how do you set it?
I have looked through the documentation for CLI, but it doesn't mention setting any user state from what I can see.
Update:
After having installed Lua and cmake, I ran meson -Denable_lua=true build which worked fine. But when I run ninja -C build I receive this error:

user_state is set in pktgen-main.c, but within a #ifdef LUA_ENABLED section.
Looking at meson_options.txt, which is at the base directory of a pktgen extraction, it contains:
option('enable_lua', type: 'boolean', value: false, description: 'Enable Lua support')
That means that you must enable Lua support when building (after installing dependencies, as shown below):
meson -Denable_lua=true build
This is going to require a few more dependencies, so you may have to install them, e.g. in Ubuntu:
sudo apt-get install cmake
And then installing Lua - I had to install it from source as per the instructions, because installing it with Ubuntu's package manager apt didn't give me the library that was needed:
curl -R -O http://www.lua.org/ftp/lua-5.4.4.tar.gz
tar zxf lua-5.4.4.tar.gz
cd lua-5.4.4
make all test
sudo make install

Related

What does Jenkins use to capture stdout and stderr of a shell command?

In Jenkins, you can use the sh step to run Unix shell scripts.
I was experimenting, and I found that the stdout is not a tty, at least on a Docker image.
What does Jenkins use for capturing stdout and stderr of programs running via the sh step? Is the same thing used for running the sh step on a Jenkins node versus on a Docker container?
I ask for my own edification and for some possible practical applications of this knowledge.
To reproduce my experimentation
If you already know an answer, you don't need to read these details for reproducing. I am just adding this here for reproducibility.
I have the following Jenkins/Groovy code:
docker.image('gcc').inside {
sh '''
gcc -O2 -Wall -Wextra -Wunused -Wpedantic \
-Werror write_to_tty.c -o write_to_tty
./write_to_tty
'''
}
The Jenkins log snippet for the sh step code above is
+ gcc -O2 -Wall -Wextra -Wunused -Wpedantic -Werror write_to_tty.c -o write_to_tty
+ ./write_to_tty
stdout is not a tty.
This compiles and runs the following C code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
int stdout_fd = fileno(stdout);
if (!isatty(stdout_fd)) {
fprintf(stderr, "stdout is not a tty.\n");
exit(1);
}
char* stdout_tty_name = ttyname(stdout_fd);
if (stdout_tty_name == NULL) {
fprintf(stderr, "Failed to get tty name of stdout.\n");
exit(1);
}
FILE* tty = fopen(stdout_tty_name, "w");
if (tty == NULL) {
fprintf(stderr, "Failed to open tty %s.\n", stdout_tty_name);
exit(1);
}
fprintf(tty, "Written directly to tty.\n");
fclose(tty);
printf("Written to stdout.\n");
fprintf(stderr, "Written to stderr.\n");
exit(0);
}
I briefly looked at the source here and it seems stdout is written to a file and then read from that, Hence it's not a tty. Also, stderror, if any, will be written to the log.
Here is the Javadoc.
/** * Runs a durable task, such as a shell script, typically on an
agent. * “Durable” in this context means that Jenkins makes an
attempt to keep the external process running * even if either the
Jenkins controller or an agent JVM is restarted. * Process standard
output is directed to a file near the workspace, rather than holding a
file handle open. * Whenever a Remoting connection between the two
can be reëstablished, * Jenkins again looks for any output sent since
the last time it checked. * When the process exits, the status code
is also written to a file and ultimately results in the step passing
or failing. * Tasks can also be run on the built-in node, which
differs only in that there is no possibility of a network failure. */
I found the source for the sh step, which appears to be implemented using the BourneShellScript class.
When not capturing stdout, the command is generated like this:
cmdString = String.format("{ while [ -d '%s' -a \\! -f '%s' ]; do touch '%s'; sleep 3; done } & jsc=%s; %s=$jsc %s '%s' > '%s' 2>&1; echo $? > '%s.tmp'; mv '%s.tmp' '%s'; wait",
controlDir,
resultFile,
logFile,
cookieValue,
cookieVariable,
interpreter,
scriptPath,
logFile,
resultFile, resultFile, resultFile);
If I correctly matched the format specifiers to the variables, then the %s '%s' > '%s' 2>&1 part roughly corresponds to
${interpreter} ${scriptPath} > ${logFile} 2>&1
So it seems that the stdout and stderr of the script is written to a file.
When capturing output, it is slightly different, and is instead
${interpreter} ${scriptPath} > ${c.getOutputFile(ws)} 2> ${logFile}
In this case, stdout and stderr are still written to files, just not to the same file.
Aside
For anyone interested in how I found the source code:
First I used my bookmark for the sh step docs, which can be found with a search engine
I scrolled to the top and clicked on the "View this plugin on the Plugins site" link
On that page, I clicked the GitHub link
On the GitHub repo, I navigated to the ShellStep.java by drilling down from the src directory
I saw that the class was implemented using the BourneShellScript class, and based on the import for this class, I knew it was part of the durable task plugin
I searched the durable task plugin, and followed the same "View this plugin on the Plugins site" link and then GitHub link to view the GitHub repo for the durable task plugin
Next, I used the "Go to file" button and searched for the class name to jump to its .java file
Finally, I inspected this file to find what I was interested in

mkDerivation use cmake in buildPhase

I'm trying to create a derivation using nix files, and I'm a little stuck. A package I'm trying to install has a sh file in its repo to build it, and this sh file is running CMake with some arguments.
More specifically, this package is vcpkg.
Here's my vcpkg.nix file:
{ gcc11Stdenv, fetchFromGitHub, ninja, cmake, bash }:
gcc11Stdenv.mkDerivation {
name = "vcpkg-2021.05.12";
src = fetchFromGitHub {
owner = "microsoft";
repo = "vcpkg";
rev = "2021.05.12";
sha256 = "0290fp9nvmbqpgr33rnchn5ngsq4fdll2psvh0bqf0324w2qpsjw";
};
buildPhase = ''
./bootstrap-vcpkg.sh -useSystemBinaries
'';
}
When running it with nix-shell -p 'with (import <nixpkgs> {}); callPackage ./vcpkg.nix {}', I get this error:
configuring
no configure script, doing nothing
building
Could not find cmake. Please install it (and other dependencies) with:
sudo apt-get install cmake ninja-build
error: builder for '/nix/store/riq6vjdhv4z3xvzp8g597xjgwf2rvm03-vcpkg-2021.05.12.drv' failed with exit code 1;
last 9 log lines:
> unpacking sources
> unpacking source archive /nix/store/ycfd6vbgh3s1vy11hfb17b8x33rqj7aw-source
> source root is source
> patching sources
> configuring
> no configure script, doing nothing
> building
> Could not find cmake. Please install it (and other dependencies) with:
> sudo apt-get install cmake ninja-build
For full logs, run 'nix log /nix/store/riq6vjdhv4z3xvzp8g597xjgwf2rvm03-vcpkg-2021.05.12.drv'.
Then, I thought of making cmake and ninja available to buildPhase so the script can use those binaries by adding buildInputs = [cmake ninja];, but I then get this error:
configuring
fixing cmake files...
cmake flags: -DCMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_SKIP_BUILD_RPATH=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LOCALEDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/locale -DCMAKE_INSTALL_LIBEXECDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/libexec -DCMAKE_INSTALL_LIBDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/lib -DCMAKE_INSTALL_DOCDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/doc/vcpkg -DCMAKE_INSTALL_INFODIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/info -DCMAKE_INSTALL_MANDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/man -DCMAKE_INSTALL_OLDINCLUDEDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/include -DCMAKE_INSTALL_INCLUDEDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/include -DCMAKE_INSTALL_SBINDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/sbin -DCMAKE_INSTALL_BINDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/bin -DCMAKE_INSTALL_NAME_DIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/lib -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_STRIP=/nix/store/854jyvxrvpdpbfn2zaba1v2qgqkxipyh-cctools-binutils-darwin-949.0.1/bin/strip -DCMAKE_RANLIB=/nix/store/854jyvxrvpdpbfn2zaba1v2qgqkxipyh-cctools-binutils-darwin-949.0.1/bin/ranlib -DCMAKE_AR=/nix/store/854jyvxrvpdpbfn2zaba1v2qgqkxipyh-cctools-binutils-darwin-949.0.1/bin/ar -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_INSTALL_PREFIX=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12
CMake Error: The source directory "/tmp/nix-build-vcpkg-2021.05.12.drv-0/source" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
error: builder for '/nix/store/76djky7f3xy6ym6v3qlmy941z0bjb8xw-vcpkg-2021.05.12.drv' failed with exit code 1;
last 9 log lines:
> unpacking sources
> unpacking source archive /nix/store/ycfd6vbgh3s1vy11hfb17b8x33rqj7aw-source
> source root is source
> patching sources
> configuring
> fixing cmake files...
> cmake flags: -DCMAKE_FIND_USE_SYSTEM_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_SKIP_BUILD_RPATH=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_LOCALEDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/locale -DCMAKE_INSTALL_LIBEXECDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/libexec -DCMAKE_INSTALL_LIBDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/lib -DCMAKE_INSTALL_DOCDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/doc/vcpkg -DCMAKE_INSTALL_INFODIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/info -DCMAKE_INSTALL_MANDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/share/man -DCMAKE_INSTALL_OLDINCLUDEDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/include -DCMAKE_INSTALL_INCLUDEDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/include -DCMAKE_INSTALL_SBINDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/sbin -DCMAKE_INSTALL_BINDIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/bin -DCMAKE_INSTALL_NAME_DIR=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12/lib -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_OSX_SYSROOT= -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_STRIP=/nix/store/854jyvxrvpdpbfn2zaba1v2qgqkxipyh-cctools-binutils-darwin-949.0.1/bin/strip -DCMAKE_RANLIB=/nix/store/854jyvxrvpdpbfn2zaba1v2qgqkxipyh-cctools-binutils-darwin-949.0.1/bin/ranlib -DCMAKE_AR=/nix/store/854jyvxrvpdpbfn2zaba1v2qgqkxipyh-cctools-binutils-darwin-949.0.1/bin/ar -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_INSTALL_PREFIX=/nix/store/mp38jl4fkv0gqnqhz7a3agx4flwda59n-vcpkg-2021.05.12
> CMake Error: The source directory "/tmp/nix-build-vcpkg-2021.05.12.drv-0/source" does not appear to contain CMakeLists.txt.
> Specify --help for usage, or press the help button on the CMake GUI.
For full logs, run 'nix log /nix/store/76djky7f3xy6ym6v3qlmy941z0bjb8xw-vcpkg-2021.05.12.drv'.
It seems that adding cmake to buildInputs makes nix try to configure the project using cmake, but this is not what I'm trying to do since vcpkg don't simply have a CMakeLists.txt file in its repo.
Adding inherit cmake ninja; didn't seem to help.
You can prevent cmake from changing the configure phase by setting dontUseCmakeConfigure=true in your derivation.
From the nixpkgs manual:
6.7.29. cmake
Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to CMAKE_PREFIX_PATH so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting configurePhase to a custom value, or by setting dontUseCmakeConfigure. cmakeFlags controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.

PANIC: unprotected error in call to Lua API (undefined symbol: lua_gettop)

My environment is Lua-5.4.2 Luasocket-3.0-rc1.
When I run lua script directly, it work success.
When i run it through c language, it tell me error.
Error Msg is :
PANIC: unprotected error in call to Lua API (error running script: error loading module 'socket.core' from file '/usr/local/lib/lua/5.4/socket/core.so': undefined symbol: lua_gettop)
Aborted(core dumped)
Does anyone know why?
lua script code is:(test.lua)
#!/usr/local/bin/lua
local socket = require("socket")
print(socket._VERSION)
c code is:(main.c)
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
int main(void)
{
lua_State *L;
L = luaL_newstate();
luaopen_base(L);
luaL_openlibs(L);
printf("lua enter\n");
if (luaL_dofile(L, "test.lua"))
{
luaL_error(L, "error running script: %s", lua_tostring(L, -1));
}
printf("lua exit\n");
while(1) pause();
lua_close(L);
return 0;
}
tl;dr: Pass -Wl,-E to GCC.
I was able to reproduce your problem with this Dockerfile:
FROM gcc:11.1.0
RUN wget https://www.lua.org/ftp/lua-5.4.2.tar.gz \
&& git clone https://github.com/diegonehab/luasocket.git
RUN tar zxf lua-5.4.2.tar.gz \
&& cd lua-5.4.2 \
&& make linux \
&& make install \
&& cd ../luasocket \
&& git checkout 5b18e475f38fcf28429b1cc4b17baee3b9793a62 \
&& make linux LUAV=5.4 \
&& make install LUAV=5.4
COPY test.lua main.c ./
When I run lua test.lua in the resulting Docker container, it works fine. When I run gcc -o test main.c /usr/local/lib/liblua.a -ldl -lm -Wl,-rpath='/usr/local/lib/lua/5.4/socket' && ./test, I get the same panic that you get.
The reason that the standalone Lua binary works and yours doesn't is that the former is linked with -E:
MYLDFLAGS= $(LOCAL) -Wl,-E
ld's documentation for -E says this about it:
If you use dlopen to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself.
Lua uses dlopen to load C modules that you require, and said modules need to call Lua functions, which are linked into your binary, so it makes sense that you need this option. And indeed, when I add -Wl,-E to the GCC command line, then it works fine for me:
root#077bbb831441:/# gcc -o test main.c /usr/local/lib/liblua.a -ldl -lm -Wl,-rpath='/usr/local/lib/lua/5.4/socket' -Wl,-E && ./test
lua enter
LuaSocket 3.0-rc1
lua exit

How to add a static library to Yocto SDK package

I have a .a and .h file that should be added into the SDK installer. The header file is correctly put in the {includedir} aka /usr/include
However, the static lib file which is set to be added in {libdir} is not copied to usr/lib/ for some reason. I do not get any error or warning messages when building the SDK package.
The recipe used:
#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#
SUMMARY = "HostSw and libraries for abc"
SECTION = "abc-drv"
LICENSE = "CLOSED"
ABC_ROOT = "${HOME}/abc/def"
ABC_HOSTSW_DIR = "${ABC_ROOT}/hostSw"
ABC_UTILS_DIR = "${ABC_ROOT}/cliUtilities"
inherit externalsrc
EXTERNALSRC = "${ABC_ROOT}"
do_compile() {
make clean -C ${ABC_HOSTSW_DIR}
make -C ${ABC_HOSTSW_DIR}
make clean -C ${ABC_UTILS_DIR}
make -C ${ABC_UTILS_DIR}
}
##################################################################################################
APPLI_PATH := "${ABC_ROOT}/hostSw"
APPLI_BIN_PATH := "${APPLI_PATH}/bin/"
APPLI_TARGET_PATH := "${base_prefix}/home/root/"
APPLI_NAME := "example-app"
UTILS_BIN_PATH := "${ABC_UTILS_DIR}/bin"
UTILS_TARGET_PATH := "${APPLI_TARGET_PATH}"
do_install() {
install -d ${D}${APPLI_TARGET_PATH}
install -m 0550 ${APPLI_BIN_PATH}/${APPLI_NAME} ${D}${APPLI_TARGET_PATH}
install -d ${D}${libdir}
install -m 0644 ${APPLI_BIN_PATH}/abc.a ${D}/${libdir}
install -d ${D}${includedir}
install -m 0644 ${APPLI_PATH}/inc/abc.h ${D}/${includedir}
}
FILES_${PN} = "\
${APPLI_TARGET_PATH} \
"
Please don't mind the externalsrc or any other non-problem related peculiarities, the recipe is working fine the way I need it to except for the static lib not being inserted in the SDK.
Why is the .a file not treated the same way as the header file and how would the recipe needed to be changed so the static lib is included in the SDK package?
When listing the package I get:
oe-pkgdata-util list-pkg-files -p def-abc-xyz
def-abc-xyz-dbg:
def-abc-xyz-staticdev:
/usr/lib/libabc.a
def-abc-xyz-dev:
/usr/include/abc.h
def-abc-xyz:
[snip]

RabbitMQ install issue on Centos 5.5

I've been trying to get rabbitmq-server-2.4.0 up and running on Centos
5.5 on an Amazon AWS instance.
My instance uses the following kernel: 2.6.18-xenU-ec2-v1.2
I've tried installation of erlang and rabbitmq-server using:
1) yum repos
2) direct rpm installation
3) compiling from source.
In every case, I get the following message when attempting to start the
RabbitMQ-Server process:
pthread/ethr_event.c:98: Fatal error in wait__(): Function not
implemented (38)
Any help would be appreciated.
The problem
When starting erlang, the message pthread/ethr_event.c:98: Fatal error in wait__(): Function not implemented (38) is, on modern distros, most likely the result of a precompiled Erlang binary interacting with a kernel that doesn't implement FUTEX_WAIT_PRIVATE and FUTEX_WAKE_PRIVATE. The kernels Amazon provides for EC2 do not implement these FUTEX_PRIVATE_ macros.
Attempting to build Erlang from source on an ec2 box may fail in the same way if the distro installs kernel headers into /usr/include/linux as a requirement of other packages. (E.g., Centos requires the kernel-headers package as a prerequisite for gcc, gcc-c++, glibc-devel and glibc-headers, among others). Since the headers installed by the package do not match the kernel installed by the EC2 image creation scripts, Erlang incorrectly assumes FUTEX_WAIT_PRIVATE and FUTEX_WAKE_PRIVATE are available.
The fix
To fix it, the fastest is to manually patch erts/include/internal/pthread/ethr_event.h to use the non-_PRIVATE futex implementation:
#if defined(FUTEX_WAIT_PRIVATE) && defined(FUTEX_WAKE_PRIVATE)
# define ETHR_FUTEX_WAIT__ FUTEX_WAIT_PRIVATE
# define ETHR_FUTEX_WAKE__ FUTEX_WAKE_PRIVATE
#else
# define ETHR_FUTEX_WAIT__ FUTEX_WAIT
# define ETHR_FUTEX_WAKE__ FUTEX_WAKE
#endif
should become
//#if defined(FUTEX_WAIT_PRIVATE) && defined(FUTEX_WAKE_PRIVATE)
//# define ETHR_FUTEX_WAIT__ FUTEX_WAIT_PRIVATE
//# define ETHR_FUTEX_WAKE__ FUTEX_WAKE_PRIVATE
//#else
# define ETHR_FUTEX_WAIT__ FUTEX_WAIT
# define ETHR_FUTEX_WAKE__ FUTEX_WAKE
//#endif
Quick test
If you suspect the private futex issue is your problem, but want to verify it before you recompile all of Erlang, the following program can pin it down:
#include <sys/syscall.h>
#include <unistd.h>
#include <sys/time.h>
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
typedef uint32_t u32; /* required on older kernel headers to fix a bug in futex.h Delete this line if it causes problems. */
#include <linux/futex.h>
int main(int argc, char *argv[])
{
#if defined(FUTEX_WAIT) && defined(FUTEX_WAKE)
uint32_t i = 1;
int res = 0;
res = syscall(__NR_futex, (void *) &i, FUTEX_WAKE, 1,
(void*)0,(void*)0, 0);
if (res != 0)
{
printf("FUTEX_WAKE HAD ERR %i: %s\n", errno, strerror(errno));
} else {
printf("FUTEX_WAKE SUCCESS\n");
}
res = syscall(__NR_futex, (void *) &i, FUTEX_WAIT, 0,
(void*)0,(void*)0, 0);
if (res != 0)
{
printf("FUTEX_WAIT HAD ERR %i: %s\n", errno, strerror(errno));
} else {
printf("FUTEX_WAIT SUCCESS\n");
}
#else
printf("FUTEX_WAKE and FUTEX_WAIT are not defined.\n");
#endif
#if defined(FUTEX_WAIT_PRIVATE) && defined(FUTEX_WAKE_PRIVATE)
uint32_t j = 1;
int res_priv = 0;
res_priv = syscall(__NR_futex, (void *) &j, FUTEX_WAKE_PRIVATE, 1,
(void*)0,(void*)0, 0);
if (res_priv != 0)
{
printf("FUTEX_WAKE_PRIVATE HAD ERR %i: %s\n", errno, strerror(errno));
} else {
printf("FUTEX_WAKE_PRIVATE SUCCESS\n");
}
res_priv = syscall(__NR_futex, (void *) &j, FUTEX_WAIT_PRIVATE, 0,
(void*)0,(void*)0, 0);
if (res_priv != 0)
{
printf("FUTEX_WAIT_PRIVATE HAD ERR %i: %s\n", errno, strerror(errno));
} else {
printf("FUTEX_WAIT_PRIVATE SUCCESS\n");
}
#else
printf("FUTEX_WAKE_PRIVATE and FUTEX_WAIT_PRIVATE are not defined.\n");
#endif
return 0;
}
Paste it into futextest.c, then gcc futextest.c and ./a.out.
If your kernel implements private futexes, you'll see
FUTEX_WAKE SUCCESS
FUTEX_WAIT SUCCESS
FUTEX_WAKE_PRIVATE SUCCESS
FUTEX_WAIT_PRIVATE SUCCESS
If you have a kernel without the _PRIVATE futex functions, you'll see
FUTEX_WAKE SUCCESS
FUTEX WAIT SUCCESS
FUTEX_WAKE_PRIVATE HAD ERR 38: Function not implemented
FUTEX_WAIT_PRIVATE HAD ERR 38: Function not implemented
This fix should allow Erlang to compile, and will yield an environment you can install rabbitmq against using the --nodeps method discussed here.
I installed it by first installing erlang by source:
sudo yum -y install make gcc gcc-c++ kernel-devel m4 ncurses-devel openssl-devel
wget http://www.erlang.org/download/otp_src_R13B04.tar.gz
tar xfvz otp_src_R13B04.tar.gz
cd otp_src_R13B04/
./configure
sudo make install
After that create a symbolic link to also make erl available for root user:
sudo ln -s /usr/local/bin/erl /bin/erl
Install rabbitmq rpm (Maybe outdated check latest release yourself):
wget http://www.rabbitmq.com/releases/rabbitmq-server/v2.4.1/rabbitmq-server-2.4.1-1.noarch.rpm
rpm -Uvh rabbitmq-server-2.4.1-1.noarch.rpm
If erlang is installed from source, rpm install of rabbitmq fails to recognize erlang stating that erlang R12B-3 is required.
Use:
rpm --nodeps -Uvh rabbitmq-server-2.6.1-1.noarch.rpm
I was able to install and use RabbitMQ 2.6.1 successfully on CentOS 5.6 with Erlang R14B04
Seems that this kernel is not compatible with Erlang 14B, 14B01, or 14B02
Compiling Erlang 13B04 led to a successful install of rabbitmq-server
For people in the future finding this answer, the RabbitMQ site itself has a potential answer for you:
Installing on RPM-based Linux (CentOS, Fedora, OpenSuse, RedHat)
Erlang on RHEL 5 (and CentOS 5)
Due to the EPEL package update policy, EPEL 5 contains Erlang version
R12B-5, which is relatively old. rabbitmq-server supports R12B-5, but
performance may be lower than for more recent Erlang versions, and
certain non-core features are not supported (SSL support, HTTP-based
plugins including the management plugin). Therefore, we recommend that
you install the most recent stable version of Erlang. The easiest way
to do this is to use a package repository provided for this purpose by
the owner of the EPEL Erlang package. Enable it by invoking (as root):
wget -O /etc/yum.repos.d/epel-erlang.repo
http://repos.fedorapeople.org/repos/peter/erlang/epel-erlang.repo
and then install or update erlang with yum install erlang.
If you go down the route of building Erlang manually on a minimal OS install, you may also find that you need to install wxGTK & wxGTK-devel in order for all of the tests to build and run correctly.

Resources