The build is failing for the following subject :
"FAILED: bin/Linux_x64_Debug/grpc_ruby_plugin"
with the following error :
15:55:25 : && /opt/rh/devtoolset-7/root/usr/bin/c++ -g -O2 -fvisibility=hidden -I/hbb_exe/include -std=c++14 -Wno-unknown-pragmas -Werror=return-type -std=c++11 -g -D_DEBUG -L/hbb_shlib/lib -static-libstdc++ -rdynamic common/third_party/grpc/CMakeFiles/grpc_ruby_plugin.dir/src/compiler/ruby_plugin.cc.o -o bin/Linux_x64_Debug/grpc_ruby_plugin lib/Linux_x64_Debug/libprotocd.a lib/Linux_x64_Debug/libprotobufd.a -ldl -lrt -lm -lpthread lib/Linux_x64_Debug/libgrpc_plugin_support.a lib/Linux_x64_Debug/libprotocd.a lib/Linux_x64_Debug/libprotobufd.a -lpthread -ldl -lrt -lm -lpthread && :
15:55:25 lib/Linux_x64_Debug/libprotobufd.a(common.cc.o): In function void std::call_once<void (*&)()>(std::once_flag&, void (*&)())': 15:55:25 /opt/rh/devtoolset-7/root/usr/include/c++/7/mutex:676: undefined reference to std::__once_callable'
15:55:25 /opt/rh/devtoolset-7/root/usr/include/c++/7/mutex:677: undefined reference to `std::__once_call'

attaching the ENV output for reference
[root@5f731cfd1ed0 lib]# env
CPLUS_INCLUDE_PATH=/hbb_exe/include
LDFLAGS=-L/hbb_exe/lib -static-libstdc++
MANPATH=/opt/rh/devtoolset-7/root/usr/share/man:
HOSTNAME=5f731cfd1ed0
TERM=xterm
CPPFLAGS=-I/hbb_exe/include
PERL5LIB=/opt/rh/devtoolset-7/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-7/root/usr/lib/perl5:/opt/rh/devtoolset-7/root//usr/share/perl5/vendor_perl
LIBRARY_PATH=/hbb_exe/lib
LDPATHFLAGS=-L/hbb_exe/lib
STATICLIB_CFLAGS=-g -O2 -fvisibility=hidden -I/hbb_exe/include
OLDPWD=/hbb_exe
SHLIB_CXXFLAGS=-g -O2 -fvisibility=hidden -I/hbb_exe/include
PCP_DIR=/opt/rh/devtoolset-7/root
LD_LIBRARY_PATH=/hbb/lib:/hbb_exe/lib
O3_ALLOWED=true
CXXFLAGS=-g -O2 -fvisibility=hidden -I/hbb_exe/include
PATH=/hbb_exe/bin:/hbb/bin:/opt/rh/devtoolset-7/root/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/go/bin
C_INCLUDE_PATH=/hbb_exe/include
PWD=/hbb_exe/lib
STATICLIB_CXXFLAGS=-g -O2 -fvisibility=hidden -I/hbb_exe/include
LANG=en_US.UTF-8
SHLIB_LDFLAGS=-L/hbb_exe/lib -static-libstdc++
HOME=/root
SHLVL=1
SHLIB_CFLAGS=-g -O2 -fvisibility=hidden -I/hbb_exe/include
GOROOT=/usr/local/go
CFLAGS=-g -O2 -fvisibility=hidden -I/hbb_exe/include
PYTHONPATH=/opt/rh/devtoolset-7/root/usr/lib64/python2.6/site-packages:/opt/rh/devtoolset-7/root/usr/lib/python2.6/site-packages
LESSOPEN=||/usr/bin/lesspipe.sh %s
PKG_CONFIG_PATH=/hbb_exe/lib/pkgconfig:/usr/lib/pkgconfig
INFOPATH=/opt/rh/devtoolset-7/root/usr/share/info
G_BROKEN_FILENAMES=1
_=/usr/bin/env

note that If I delete the " LDFLAGS " the build is successful but then it is using the standard OS libstdc++ file and not the holy build box so it king of misses the point ....

The system OpenSSL and system curl were only installed because CentOS 5's OpenSSL and curl didn't support SNI, which prevented the build script from downloading source code.

According to https://stackoverflow.com/a/12942331/20816, SNI requires:

• curl >= 7.18.1. CentOS 6 has 7.19.7.
• OpenSSL >= 0.9.8j. CentOS 6 has 1.0.1e.

When running the basic command presented in the tutorials:

$ docker run -t -i --rm phusion/holy-build-box-64:latest bash

absolutely nothing happens, the command quits in about ~10 seconds with exit code 139 and docker ps -a displays nothing.

When trying the most simple command:

$ docker run phusion/holy-build-box-64:latest
$ docker ps -a
CONTAINER ID        IMAGE                                          COMMAND                  CREATED             STATUS                        PORTS               NAMES
6657c56132f3        phusion/holy-build-box-64:latest               "/bin/bash"              10 seconds ago      Exited (139) 7 seconds ago                        affectionate_bell

Any idea how to solve this? I'm not a docker expert (;

Hi,
I am unable to compile librdkafka (https://github.com/edenhill/librdkafka).
Steps:
I have logged into the container and activated hbb_exe
Configure of librdkafka throws out C++ not found

While working through Tutorial 1, I received the following error:

> docker run -t -i --rm foobarwidget/holy-build-box-x64 bash

Unable to find image 'foobarwidget/holy-build-box-x64:latest' locally
docker: Error response from daemon: pull access denied for foobarwidget/holy-build-box-x64, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.

I was able to resolve the error by prepending the URL to the Github container repository to the image parameter, like so:

> docker run -t -i --rm ghcr.io/foobarwidget/holy-build-box-x64 bash
Unable to find image 'ghcr.io/foobarwidget/holy-build-box-x64:latest' locally                             
latest: Pulling from foobarwidget/holy-build-box-x64                                                      
2d473b07cdd5: Pull complete                          
35bed6fba959: Pull complete                          
7f8911f81a08: Pull complete                          
Digest: sha256:a51f858721fe5d520f5eaa86979fa61ef7206561164103b8447dfcc2297ad57d                           
Status: Downloaded newer image for ghcr.io/foobarwidget/holy-build-box-x64:latest                         
[root@1337a209ab06 /]#

New users (particularly users new to Docker) might not realize that the container registry URL is needed, and so a documentation update might be in order. I'd be glad to submit a PR but wanted to file an issue first to make sure there wasn't something else I was missing.

Thanks for providing such a nifty utility!

i'm building from your phusion/holy-build-box-64:latest and it has been amazing. I appreciate the efforts. Recently I changed my requirements for cmake to version 3.21+. I see in the merge log you updated it to 3.22 a year ago but the latest docker image is still at 3.19.

The FAQ states that binaries should be ok on Debian >6, Ubuntu >10, which would be great.

The question is if binaries were really tested on very new distributions, like ARCH, which is probably the most advanced one. And even Ubuntu 16/17.

There were bug fixes recently in git, the version installed in hbb images should be updated.

The link on the right side should be https://phusion.github.io/holy-build-box/

For the test, I use an example from their documentation https://github.com/phusion/holy-build-box/blob/master/TUTORIAL-1-BASICS.md Compilation is performed on the Ubuntu + Docker virtual machine. After compilation, launch on Ubuntu goes fine, everything works. When migrating to another Linux host (CentOS), when starting the binary, I get an error: segmentation fault. What needs to be done to make this binary work normally?

Wow, this project is really something we have been looking for and much simpler than our current collection of outdated centos virtualbox images. It even has up to date cmake 👍

But, we do require at least GCC 4.9, because GCC 4.8 is broken for really many C++11 features. Do you have any plans on updating? I actually think quite a few projects require GCC>=4.9 now...

Thank you very much!

Hi! First off, thanks! This docker container is awesome, basically exactly what we needed to automate building some binaries for releases that work on a wider range of Linux systems (there were some minor issues like a bug in gcc 7.3.1 that were easy to work around).

I noticed the readme has a maintainers wanted badge -- what do you need help with? It looks like having a CentOS 6 container will be needed for the foreseeable future and I'd rather help keep an existing project up to date than create and maintain a fork.

We compile libstdc++ 8.3.0, but it should be 8.3.1 in order to match the version provided by devtoolset-8.

Latest holy-build-box upgraded to devtoolset 9, however, still ships libstdc++ 8.3.0. This causes all sorts of link errors are library and the includes (system!) do not match.

Compiling:

#include <string>                                                                                                                                                                                                     #include <iostream>
#include <sstream>

int main(void) {
  std::stringstream s;
  s << "Foo";
  std::cout << "Hello world!\n" << s.str() << std::endl;
  return 0;
}

With g++ test.cpp -static-libstdc++ -static-libgcc -O2 -fvisibility=hidden -I/hbb_exe/include -L/hbb_exe/lib

Yields:

/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: /tmp/cciMQUab.o: in function `main':
1.cpp:(.text.startup+0xe): undefined reference to `std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream()'

The symbol (ctor of basic_stringstream) moved from being inlined to library.

I think we should add a micro-init system, such as tini, in order to avoid the PID 1 zombie reaping problem. What do you think @nightlark?

Hello,

This isn't so much an issue as a cry for help.

I'm trying to compile htslib from samtools http://www.htslib.org/download/, and I'm getting an error on htslib. In general I'm hoping to use holy-build-box to build bioinformaitcs software.

if test -n "/io/binary/libexec/htslib"; then mkdir -p -m 755 /io/binary/libexec/htslib; fi
gcc -shared -Wl,-soname,libhts.so.1 -pthread -L/hbb_exe -static-libstdc++ -rdynamic -o libhts.so kfunc.pico knetfile.pico kstring.pico bgzf.pico faidx.pico hfile.pico hfile_net.pico hts.pico md5.pico regidx.pico sam.pico synced_bcf_reader.pico vcf_sweep.pico tbx.pico vcf.pico vcfutils.pico cram/cram_codecs.pico cram/cram_decode.pico cram/cram_encode.pico cram/cram_external.pico cram/cram_index.pico cram/cram_io.pico cram/cram_samtools.pico cram/cram_stats.pico cram/files.pico cram/mFILE.pico cram/open_trace_file.pico cram/pooled_alloc.pico cram/rANS_static.pico cram/sam_header.pico cram/string_alloc.pico cram/thread_pool.pico cram/vlen.pico cram/zfio.pico plugin.pico -lz -lm -ldl
/opt/rh/devtoolset-2/root/usr/libexec/gcc/x86_64-CentOS-linux/4.8.2/ld: /hbb_exe/lib/libz.a(crc32.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/hbb_exe/lib/libz.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status

Any insight would be very appreciated!

Best,
Jillian

Hello! The yum install/update commands stopped working for us recently. I suspect that this may be related to the EOL of the Centos 6 base image but I'm not sure.

The error is:

# yum update
Loaded plugins: fastestmirror, ovl
Setting up Update Process
Loading mirror speeds from cached hostfile
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base

Is there any plan of upgrading the base image? Or maybe setting the vault by default?

Noticed today that yum updates/installs aren't working in the 32-bit HBB image. Perhaps the packagecloud subscription wasn't paid?

Error encountered

bash-4.1# yum update
Loaded plugins: fastestmirror
Setting up Update Process
Determining fastest mirrors
epel/metalink                                                                                    | 4.7 kB     00:00
 * epel: mirror.math.princeton.edu
CentOS-base                                                                                      | 3.7 kB     00:00
CentOS-base/primary_db                                                                           | 4.7 MB     00:03
CentOS-centosplus                                                                                | 3.4 kB     00:00
CentOS-centosplus/primary_db                                                                     | 5.7 MB     00:03
CentOS-contrib                                                                                   | 2.9 kB     00:00
CentOS-contrib/primary_db                                                                        | 7.4 kB     00:00
CentOS-extras                                                                                    | 3.4 kB     00:00
CentOS-extras/primary_db                                                                         |  29 kB     00:00
CentOS-fasttrack                                                                                 | 2.9 kB     00:00
CentOS-fasttrack/primary_db                                                                      | 9.9 kB     00:00
CentOS-updates                                                                                   | 3.4 kB     00:00
CentOS-updates/primary_db                                                                        |  12 MB     00:07
epel                                                                                             | 4.7 kB     00:00
epel/primary_db                                                                                  | 6.1 MB     00:00
https://packagecloud.io/phusion/centos-6-scl-i386/el/6/i386/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 402 Payment Required"
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: phusion_centos-6-scl-i386. Please verify its path and try again

Workarounds:

rm -f /etc/yum.repos.d/phusion_centos-6-scl-i386.repo
to remove the repo before issuing any yum commands

Alternatively, issue yum commands with the --disablerepo flag:
yum --disablerepo=phusion_centos-6-scl-i386,phusion_centos-6-scl-i386-source install <package>

The GitHub actions have been failing for a year now.

I also don't know where to find the old logs of past successful CI runs. If those were available, one might have a better chance to find and fix the issue...

Hi,

We use holy build box to build distributable linux executables for our software salmon. Recently, we have been trying to update to a more recent version of the threading building blocks library (TBB), since some parts of the API have been deprecated in newer versions. Unfortunately, after making this update, essentially all TBB-related symbols now fail to resolve when building under holy build box.

I recently posted a full rundown of the issue in the TBB repo here. While I am not sure the ultimate cause of the problem, I can only replicate this issue reliably within holy build box. On our server locally (ubuntu 16.04), on my Mac laptop, and on the GitHub CI images we use (ubuntu latest and OSX latest), everything builds cleanly. Yet, in holy build box, we simply cannot get this library to link. Interestingly, this was not a problem with the older versions of TBB, but those are now deprecated and maintenance & development is only done on the new versions, so we cannot stick with the old library in perpetuity.

Any insight you might have into this would be greatly appreciated.

Thanks!
Rob

The project currently does not have a license, and as a result I am not sure what limitations there are (if any) for using the software.

The build script references https://packagecloud.io/install/repositories/phusion/centos-6-scl-i386/script.rpm.sh, but this repository will go away in less than a year.

I think we should either drop x86 support altogether, or find an alternative. I think dropping x86 isn't so crazy nowadays: even years ago, I've observed that nearly nobody uses the x86 binaries for Passenger. I think that going forward, we're more likely to want to support arm64 instead.

to
https://phusion.github.io/holy-build-box/

Hello, are there any plans to add an arm64 version of the tool?

+ /hbb_exe/activate-exec /hbb/activate_func.sh: line 38: /opt/rh/devtoolset-8/enable: No such file or directory

reason is due to
function activate_holy_build_box_deps_installation_environment() { if [ "$(uname -m)" != x86_64 ]; then DEVTOOLSET_VER=7 else DEVTOOLSET_VER=8 fi
in /hbb/activate_func.sh
devtoolset 8 isn't readily available or in the container for x86, should always be set to 7 for the x86 container.

As in CVE-2018-25032 decribed there is a security issue in zlib version 1.2.11 and below.
A few days ago a new zlib version 1.2.12 was released that fixes this issue.
Can you please update zlib to version 1.2.12 for the next release.

Hi,
I am trying to follow the get started guide on my windows 10's Ubuntu WSL 2
And The get started Guide didn't Worked.

But I also tried it on a ubuntu server it worked just fine.
This problem is occurring on Docker on Windows (WSL2)

Not too sure about this one, but I have a C++ application that I'm building with holy-build-box. I'm having an issue when trying to link code that uses std::call_once:
...
/opt/rh/devtoolset-8/root/usr/include/c++/8/mutex:677: undefined reference to `std::__once_call'
...

It appears the /hbb_exe/lib/libstdc++.a may not have thread support, compare:

nm -C /hbb_exe/lib/libstdc++.a | grep std::thread
and
nm -C /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8/libstdc++.a | grep std::thread
nm: compatibility-debug_list-2.o: no symbols

It would be great if holy buildbox could be integrated with visual studio to generate a portable executable. That would require cmake, vcpkg, openssh-server g++ gdb make ninja-build rsync zip.

I have tried modifying the image to install ssh and run visual studio but somehow the ssh connections are not very stable.

The version of git available in holy-build-box does not support https urls.

$ docker run -it --rm --volume ${PWD}:/data phusion/holy-build-box-64:3.0.2 bash
[root@cd0a66973054 /]# source /hbb_exe/activate
Holy build box activated
Prefix: /hbb_exe
CFLAGS/CXXFLAGS: -g -O2 -fvisibility=hidden -I/hbb_exe/include 
LDFLAGS: -L/hbb_exe/lib -static-libstdc++
STATICLIB_CFLAGS: -g -O2 -fvisibility=hidden -I/hbb_exe/include 
SHLIB_CFLAGS: -g -O2 -fvisibility=hidden -I/hbb_exe/include 
SHLIB_LDFLAGS: -L/hbb_exe/lib -static-libstdc++

[root@cd0a66973054 /]# git clone https://github.com/google/googletest.git
Cloning into 'googletest'...
git: 'remote-https' is not a git command. See 'git --help'.

This probably has something to do with the version of curl being available when git is built. I was able to work around it by installing curl-devel:

diff --git a/image/build.sh b/image/build.sh
index d31e6eb..09c37c2 100755
--- a/image/build.sh
+++ b/image/build.sh
@@ -65,7 +65,7 @@ if ! eval_bool "$SKIP_INITIALIZE"; then
        run yum update -y
        run yum install -y tar curl m4 autoconf automake libtool pkgconfig openssl-devel \
                file patch bzip2 zlib-devel gettext python-setuptools python-devel \
-               epel-release centos-release-scl
+               epel-release centos-release-scl curl-devel
        run yum install -y python2-pip "devtoolset-$DEVTOOLSET_VERSION"
 fi

but not sure if that is an acceptable solution since curl is also built locally.

It took a while for me to find out that this link is wrong, and the correct one in #60 is not merged.

The correct link is ghcr.io/phusion/holy-build-box/hbb-64.

As you may be aware CentOS 5 is no longer supported. I was wondering if its possible to update to a supported OS?