NGINX RTMP Compile Error

I am testing RTMP streaming on NGINX using the nginx-rtmp-module code base. Unfortunately nginx-rtmp-module is not available as a package. Hence I must compile from source. Compiling the module on Ubuntu 20.04 I encountered the error:

make -f objs/Makefile
make[1]: Entering directory '/home/ubuntu/nginx'
cc -c -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g   -I src/core -I src/event -I src/event/modules -I src/os/unix -I ../nginx-rtmp-module -I objs -I src/http -I src/http/modules \
        -o objs/addon/nginx-rtmp-module/ngx_rtmp_eval.o \
        ../nginx-rtmp-module/ngx_rtmp_eval.c
../nginx-rtmp-module/ngx_rtmp_eval.c: In function ‘ngx_rtmp_eval’:
../nginx-rtmp-module/ngx_rtmp_eval.c:160:17: error: this statement may fall through [-Werror=implicit-fallthrough=]
  160 |                 switch (c) {
      |                 ^~~~~~
../nginx-rtmp-module/ngx_rtmp_eval.c:170:13: note: here
  170 |             case ESCAPE:
      |             ^~~~
cc1: all warnings being treated as errors
make[1]: *** [objs/Makefile:1339: objs/addon/nginx-rtmp-module/ngx_rtmp_eval.o] Error 1
make[1]: Leaving directory '/home/ubuntu/nginx'
make: *** [Makefile:8: build] Error 2

The key part of this error is:

_rtmp_eval.c: In function ‘ngx_rtmp_eval’:
../nginx-rtmp-module/ngx_rtmp_eval.c:160:17: error: this statement may fall through [-Werror=implicit-fallthrough=]
  160 |                 switch (c) {

What does this NGINX RTMP compile error mean?

Lets look at the code first. Additionally you can find it on Github here.

            case NORMAL:
                switch (c) {
                    case '$':
                        name.data = p + 1;
                        state = NAME;
                        continue;
                    case '\\':
                        state = ESCAPE;
                        continue;
                }

            case ESCAPE:
                ngx_rtmp_eval_append(&b, &c, 1, log);
                state = NORMAL;
                break;

This error is telling us that on line 160 the case statement may fall through to the next part of the case statement. This could indicate a forgotten break or continue on the part of the author. In this case I believe its intentional. However it only breaks certain versions or configuration of the build tools.

Fixing the NGINX RTMP compile issue

To fix this we must tell the build tools to ignore this potential error. We have two options. Change the code base. Alternatively we can change the build settings.

Option 1 – Change the NGINX code

We can do that by adding a /* fall through */ to the end of case NORMAL.

The new code snippet will look like this:

 case NORMAL:
                switch (c) {
                    case '$':
                        name.data = p + 1;
                        state = NAME;
                        continue;
                    case '\\':
                        state = ESCAPE;
                        continue;
                }

                /* fall through */

            case ESCAPE:
                ngx_rtmp_eval_append(&b, &c, 1, log);
                state = NORMAL;
                break;

Option 2 – Use different build parameters

Option 2 is my preferable fix because it means I don’t need to change the codebase. Changing the code might introduce problems later if I try to sync it with upstream. So instead of opting to change the code I tell the build system to ignore these types of errors. However there are unintended consequence here too. There might be an actual bug or issue with an unintentional fall through. Shrug.

To change the build parameters you need to re-run the configure script with the following option:

--with-cc-opt="-Wimplicit-fallthrough=0"

In my case the complete command I was running from within my nginx directory is:

./auto/configure --add-module=../nginx-rtmp-module --with-cc-opt="-Wimplicit-fallthrough=0"

Fixing the issue upstream?

Looking in the code I see /* fall through */ used in other places. But for some reason the maintainers have not patched this particular code path. Even though there are bugs opened against it. Considering there are options to work around it I can understand. But I feel this particular check does provide value in some cases, turning it off can lead to other undiscovered bugs in new code that comes in.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.