Building ds-ctcdecoder on RaspberryPi?

Hmm, I’m not quite convinced that this would be easier :see_no_evil:
There is no problem renaming the layers of my network, but my input and output shapes of the intermediate layers are completely different because I did change network architecture. So I’m assuming that I have to change more than a few lines in the above files.

Sorry, I really have no time to dig into the specifics, but TFLite shapes should not be very complicated to adapt, and likely much less headaches than making ds_ctcdecoder cross-build, or having to build it on your hardware directly. Which eventually, never solves the fact that you end up exercising the tensorflow runtime, and not the TFLite one.

I did make some progress, my network now requires tflite-runtime only, but the ds-ctcdecoder is not yet working. I was able to cross-build it and install a copy of it on my raspbian container image, but when I try to import it I get following error:

ImportError: cannot import name '_swigwrapper' from 'ds_ctcdecoder'

I did follow the steps from, built swig on the raspi and replaced the original ds-swig directory with it.

In the build process it seems the wrapper is added, but was built with the wrong architecture:

creating temp_build/temp_build/ds_ctcdecoder-0.10.0a3.dist-info/WHEEL
creating 'dist/ds_ctcdecoder-0.10.0a3-cp37-cp37m-linux_armv7l.whl' and adding 'temp_build/temp_build' to it
adding 'ds_ctcdecoder/'
adding 'ds_ctcdecoder/'
adding 'ds_ctcdecoder/'

I did start the build with make TARGET=rpi3 NUM_PROCESSES=$(nproc) bindings and I think the error is related to this build step:

/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf-c++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--no-as-needed -march=armv7-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -D_GLIBCXX_USE_CXX11_ABI=0 --sysroot /DeepSpeech/multistrap-raspbian-buster -march=armv7-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -D_GLIBCXX_USE_CXX11_ABI=0 --sysroot /DeepSpeech/multistrap-raspbian-buster -Wdate-time -D_FORTIFY_SOURCE=2 temp_build/temp_build/swigwrapper_wrap.o -o temp_build/temp_build/ds_ctcdecoder/ first_party.a third_party.a

Do you know if there is some flag I did miss? Or something other I can change?

You are doing something wrong, see the x86-64 here. We have some hack in place in to fix that

It’s related to this:

But you will likely have to read more of the makefiles and hack around, sorry.

What exactly do I need to change in the line you linked? And shouldn’t it be that line:

The wrong .so file is created somewhere in here:

This is called from here:

The logged cmd is
DISTUTILS_USE_SDK=1 PATH=/DeepSpeech/native_client/ds-swig/bin:/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf-:$PATH SWIG_LIB="/DeepSpeech/native_client/ds-swig/share/swig/4.0.2/" AS=/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf-as CC=/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf-gcc CXX=/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf-c++ LD=/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf-ld LIBEXE=/DeepSpeech/tensorflow/bazel-tensorflow/external/LinaroArmGcc72/bin/arm-linux-gnueabihf- CFLAGS="-march=armv7-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -D_GLIBCXX_USE_CXX11_ABI=0 --sysroot /DeepSpeech/multistrap-raspbian-buster -march=armv7-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -D_GLIBCXX_USE_CXX11_ABI=0 --sysroot /DeepSpeech/multistrap-raspbian-buster " LDFLAGS="-Wl,--no-as-needed" PYTHONPATH=/DeepSpeech/multistrap-raspbian-buster/usr/lib/python3.7/:/DeepSpeech/multistrap-raspbian-buster/usr/lib/python3/dist-packages/ NUMPY_INCLUDE=/DeepSpeech/multistrap-raspbian-buster/usr/include/python3.7m/ python ./ build_ext --num_processes 16 --plat-name linux_armv7l

For me the paths and architecture seem to be correct.


There is no sysconfig info passed, see the calling code on the python binding:

As you can see, no $(PYTHON_SYSCONFIGDATA) on the ctcdecode part (which is not surprising, since we don’t support this).

I guess adding that should be enough, but I can’t guarantee anything since I have no time to actually check.

Thanks. If I add the flag to the Makefile line, it tries to build ds_ctcdecoder/, but now it doesn’t find swig anymore.

swig -python -c++ -extranative -o swigwrapper_wrap.cpp swigwrapper.i
unable to execute 'swig': No such file or directory

A few log lines before calling the changed line, swig was working:

swig -version
SWIG Version 4.0.2
Compiled with g++ [armv7l-unknown-linux-gnueabihf]

Do you have an idea for that too?

Found the solution. Had to link the files from ds-swig to /usr/bin/ that I can use swig system wide.

The created ds_ctcdecoder.whl is now working in my raspbian container:)

Will do some cleanup and then share all the build steps…

That’s likely an oversight, it should not be required if you have it under ds-swig or there’s something else messing with your PATH

Nice. Overall, I guess it was not “that” complicated, just a bit of stuff spreads here and there?

Hmm, as someone who had no idea what he was doing, and one solved error resulted in another error, I’m sorry, but I have to disagree with you here :smile:. Thank you very much for your help:)
I was glad that I did the building from inside a container, because that way I could just restart the container everytime I messed up the system :laughing:

The build steps and output files can be found here:
Use at your own risk, this is not officially supported from me or the DeepSpeech team.

While this is nice of you and it probably serves as notes for you, I’d really like we warn people this is not something the project supports. It’s not unusual people come here to complain about “this” and we discover later that “this” is not made by us (and is wrong) and cover unsupported things.

Did update the text. Totally understand that, the full code is in my project’s unsupported experiments section, too.

See I was not wrong, I believe this is leading to that kind of noise on Gitub :confused:

Although if you properly state this is handled by you, i’m not sure what can be done more …

Nice job. I know my feeling, when I tried to get it run on our ppc64le. :slight_smile:

I took a look into your Containerfile_DecoderCrossbuild1.
You ran
RUN wget

According to @lissyx comments on my ppc64le build one should use or is this not an issue here?
However, I also did not have any problems with official swig. :grin:
Just as a remark for your next build.

1 Like

As far as I did understand, lissyx fork is only required for NodeJs

Technically, yes, but 4.x branch also fixes some Java and Python leaking and upgrades the code, so it’s better to avoid mixing versions here to limit the risks of support / bugs.