Ubuntu 16 container issues running on Ubuntu 22 host

General
1

I created a docker container about 7 years ago using Ubuntu 16.04 and gcc 5.4 to build an application that requires a very stable build environment. The container is currently hosted from an Ubuntu 16.04 host and has worked flawlessly over the last 7 years.

Recently we started the process of replacing the Ubuntu 16.04 host with a newer Ubuntu 22.04 host. I ran the same build process that works for the U16 host and ran into an issue with gcc.

The error reported for gcc is a syntax error inside the /usr/include/x86_64-linux/gnu/sys/select.h related to the following declaration:

#ifndef __USE_TIME_BITS64
102 extern int select (int __nfds, fd_set *__restrict __readfds,
103                    fd_set *__restrict __writefds,
104                    fd_set *__restrict __exceptfds,
105                    struct timeval *__restrict __timeout);

The syntax error is due to the use of the __restrict qualifier in front of the __readfds, __writefds, and __exceptfds.

The same error is reported by every other system include file that is added which uses the __restrict qualifier.

I looked at the file where this qualifier is defined /usr/include/x86_64-linux/gnu/sys/cdefs.h and found the following definition:

/* __restrict is known in EGCS 1.2 and above, and in clang.
   It works also in C++ mode (outside of arrays), but only when spelled
   as '__restrict', not 'restrict'.  */
#if !(__GNUC_PREREQ (2,92) || __clang_major__ >= 3)
# if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
#  define __restrict    restrict
# else
#  define __restrict    /* Ignore */
# endif
#endif

I used the following command to determine which STDC_VERSION was the compiler using and the result was identical for the container running in both the U16 and U22 hosts.

gcc -dM -E - < /dev/null | grep 'STDC_VERSION'
#define __STDC_VERSION__ 201112L

My question is what gives here? The main reason for containerizing this build environment was to protect it against host environment changes but seems to me that is not true here.

TIA

2

What is the build process? You mentioned a changed host, but we know nothing about the build itself. Since you think it is related to Docker, I assume you had a Dockerfile and ran the docker build command. Was there anything that ran directly on the host? Did the container image change? For example you used a wrong image tag like “latest” or “stable” and the actual base image changed since you built your image last time.

It is also a misconception that when you run something in a container it runs the same way on all hosts. It just makes everything easier usually, but the application can depend on the kernel and sometimes on the version of Docker when it handles system calls and not compatible with the software in the container. It doesn’t happen often though.

3

Akos thanks for your response. I thought I mentioned the build process is using gcc v5.4 so is series of straight compilations using the environment defined in the container.

Now, the reason I wrote this message is because a few weeks ago I ran into a situation where another build container based on a newer version of ubuntu would not run in a host running an earlier version of ubuntu. After doing some research I found the issue to be with the use of the SECCOM or capabilities defined in the kernel of the new OS used to build the container were not compatible with the kernel and settings of the old host.

However, after many hours I found the issue to be caused by an unexpected environment change in the new host. This container mounts an external volume which supports the compilation effort. Turns out the volume mounted by the new host was not the same as for the old host. So at the end the condition had nothing to do with the container environment and everything to do with missing files being replaced by different files in the default system locations.

4

You did, but that is just a small part of the whole picture which might be clear to you, but not to us knowing nothing more than you share. When we look for what changed, knowing the only thing that didn’t is obviously not useful :slight_smile:

I hope you don’t mount system binaries from the host or libraries. Those kind of files should always be installed in the image and not overridden.

If I understand it correctly, you found the reason and you can build your application, right? The best way to learn something is expleriencing and realizing the mistake :slight_smile:

5

Thanks again for the response and you are right I made a mistake on the initial configuration for this container that I intend to remedy when I get back to work next week.

This particular problem is now solved but I have other issues that need addressing related to this container but are very solvable.

Thanks for your insight on this issue.