New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling on raspberry pi, t3shared works, but produces unusable binary #10

ulno opened this Issue May 29, 2017 · 5 comments


None yet
2 participants

ulno commented May 29, 2017

I am trying to build tilde for the raspberry pi.
I installed libtranscript and LLnextgen manually successfully and can now run the whole t3shared make process.
However, there is not install option in t3shared and the only possible binary I can find is in tilde/src/.objects: edit

Running this just shows: Debug mode: setting VM limit

Is there anywhere some more information how the actual package build process works (I will probably now try to understand the Arch AUR pkgbuild process and try to apply it for raspbian)?


This comment has been minimized.


gphalkes commented Jun 24, 2017

Sorry for not getting back to you earlier. The process building using makefiles you describe is the development build process, which does indeed only build the tilde/src/.objects/edit binary. Hence the message about Debug mode that you saw.

The release builds are done with Makefiles generated from the files in the dist subdirectories. However, this requires some scripts I have not put up on github yet. What you probably want to try though is to build the latest released version (which can be found on The tarballs released there contain the release Makefiles.

That said, the Debug binary should however still run normally. Does the program exit after showing the message? Or does it just hang?


This comment has been minimized.

ulno commented Jul 5, 2017

Sorry, I was also on the road for a while and had to use a heavily customized mcedit unfortunately... ok, back to tilde.

I just took another look, and got the before-mentioned debug message several times, and resulting in a direct termination after showing it. I started several times more resulting in weird letters on the screen and termination, and started again and tilde came up and seems to work fine (also mouse and and ctrl-keys + selcection works).

Weird letter starts look like this:

133 pi@ulnoiotgw:~/src/tilde/src/.objects$ ./edit

Abortedrtual method called
134 pi@ulnoiotgw:~/src/tilde/src/.objects$ 4R3R2R3R2R2R3R3R3R5R3R2R2R2R

So I assume something weird with the terminal emulation is going on. I am accessing the pi via ssh and running inside byobu (tmux), however, I have also now tried, running in plain bash in ssh - getting about the same results.

Exiting a "working" tilde shows:

*** Error in `./edit': munmap_chunk(): invalid pointer: 0x012565f0 *** 

After this I cannot start tilde anymore and it alway shows the garbled weird letters and Abortedrtual - also when trying different terminals and running outside of tmux/byobu. (It also showed Segmentation fault once).

Strangely, when using strace ./edit 2> log, tilde always starts. It seems also to start most times without 2> log only using strace -> heisenbug?

Using only ./edit now usually shows the before-mentioned garbled error message.

Any other ideas what I should test?


This comment has been minimized.

ulno commented Jul 11, 2017

Using the release packages from dist and compiling and installing them in the right order results in a usable binary on the raspberry pi. I will try to create a script which downloads and compiles them automatically and augment the thread here, when this is done.

@ulno ulno closed this Jul 11, 2017


This comment has been minimized.

ulno commented Jul 12, 2017

If somebody else wants to compile tilde in a debain-like arm environment, you can base your work on this script here:

Or you can read the related blog-post here:


This comment has been minimized.


gphalkes commented Jul 13, 2017

Thanks for figuring this out. The Makefiles in the project are the development makefiles, and may make assumptions on the underlying system that don't hold for Raspberry Pi's :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment