This project has moved and is read-only. For the latest updates, please go here.

How to build?

Topics: Technical Issues, Users Discussion
Oct 16, 2014 at 7:14 PM
After downloading the source, how do I build VeraCrypt? While I know I could download the pre-built binary, I want build from scratch.
Oct 16, 2014 at 8:14 PM
In the "src" directory, the file Readme.txt contains instructions on how to build VeraCrypt for Windows, Linux and MacOSX.
For Windows, you will need Microsoft Visual C++ 2008 (later version should work) and also Microsoft Visual C++ 1.52 (this is a legacy compiler needed for the bootloader build. it is available for MSDN subscribers).
Moreover, the device driver of VeraCrypt must be signed by a valid code signing certificate in order for it to be loaded by Windows. If you don't have such certificate, then you will need to run Windows on testing mode.
Lastly, the creation of the installer is done by calling the script "sign.bat" that is present in the "Signing" directory : it is responsible for packaging all the components and invoking the code signing tool in order to sign all the component and the final setup.
Oct 17, 2014 at 5:56 AM
Thanks. I tried installing and received "ld: symbol(s) not found for architecture i386" and "error: linker command failed with exit code 1 (use -v to see invocation)". How do I identify the source of the problem?
Oct 17, 2014 at 8:20 AM
What version of Xcode are you using and on which system are you building? You must check that you have MacOSX SDK and not only iOS SDK.
Did you install command line tools of Xcode?

If your build environment is setup correctly and all dependencies are present (nasm, pkg-config, OSXFUSE), then identify the version of MacOSX SDK present with your Xcode (for example 10.8) and then issue the following commands (/usr/src/wxWidgets should contain the wxWidgets 3 latest sources):
  • export VC_OSX_TARGET=10.8
  • make WXSTATIC=1 WX_ROOT=/usr/src/wxWidgets wxbuild
  • make WXSTATIC=1
Oct 19, 2014 at 7:30 AM
Tried that. Still didn't work.
Oct 19, 2014 at 11:49 PM
Can you give us details about your build environment?
Can you post the errors your are getting?

We need these information in order to help you. The build instructions have been tested on different OSX machines (10.7, 10.8, 10.9) and they having been validated as correct.
Oct 21, 2014 at 6:17 AM
Mac OS 10.9, Xcode installed, Xcode tools installed. make WXSTATIC=1 output can be found at
Oct 21, 2014 at 1:39 PM
Actually the build is successful! There are only some warnings and the VeraCrypt binary is created at the end.
The last error you are seeing is due to the fact that the Makefile performs the code signing of the VeraCrypt bundle using my Developer ID certificate which you don't have of course.

You can use the VeraCrypt bundle that is compiled on your machine if the signature verification feature of MacOSX is disabled (called Gatekeeper, here is a link that explains it :

If you have your own Apple Developer ID certificate, then you can modify the file src/Main/Main.make at line 167 and 169 in order to specify the label of your Developer ID.

Finally, in order to create the pkg file, you will need to install Packages (

Voila voila.
Oct 22, 2014 at 2:43 AM
Ah, yes. Thank You. However, there is a new issue. When attempting to create a VeraCrypt volume, I receive about fuse and "" being an invalid mount point. Do You have any idea what would be causing this? The volume creation does not appear to be successful apart from reserving the space.
Oct 22, 2014 at 1:35 PM
What version of OSXFuse did you install?
Did you select "MacFUSE compatibility layer" during OSXFuse installation?
Oct 23, 2014 at 4:10 AM
I don't recall which version I had installed (it was a while ago) but I just installed 2.7.2. I did choose the compatibility layer, yes.
Oct 29, 2014 at 5:55 AM
So, any additional suggestions?
Oct 29, 2014 at 9:25 AM
I was able to reproduce your issue only when the SDK used for build is set to 10.9. If you set the SDK to 10.8, the error doesn't appear.
Thus, the issue appears to be linked to OSXFUSE library that behaves incorrectly if called from a program built using 10.9 SDK.

Honestly, I don't understand why the same C code triggers different behaviors depending on the SDK used. A possibility is that the 10.9 SDK changed binary alignment for kernel calls and the OSXFUSE kernel extension is compiled using 10.8 SDK or less.

Anyway, this is something that has to be investigated on the side of OSXFUSE. As for VeraCrypt, you can solve the issue by setting the SDK to 10.8 :
export VC_OSX_TARGET=10.8
I have put a script in src/Build called that simplifies the build process. The only requirement is to put the wxWidgets 3.0.2 sources at the same place as your checkout: for example, if the path to the src directory is "/Users/xxx/Projects/VeraCrypt/src", then wxWidgets sources should be in "/Users/xxx/Projects/wxWidgets-3.0.2"
In this script, you can modify the value of the SDK used for the build.

For the record, we use SDK 10.6 for the official VeraCrypt MacOSX build in order to ensure the maximum compatibility across all version of MacOSX. That's why the issue you reported doesn't appear with the official VeraCrypt binary.
Marked as answer by idrassi on 10/30/2014 at 1:36 PM
Oct 29, 2014 at 1:46 PM
Edited Oct 29, 2014 at 1:48 PM
I gotta admit at the level of support you provided one user while still enhancing this product is world class.
I made the switch to VeraCrypt from TC a week ago. No issues installing it on Yosemite. Works pretty much like TC.
Well done, looking forward to future builds!
Oct 30, 2014 at 9:38 PM
We are doing our best to provide the best possible software to the community.
Oct 30, 2014 at 11:39 PM
I agree with cyberfed's comment, thanks. I receive a different error when I use the 10.8 SDK. (I was using 10.9 because I am on 10.9 and thought it was the logical choice.) Searching the web for this new error message leads to, suggesting OSXFuse is not the best choice for the situation. I will try the new script in a moment and see what happens.
Oct 31, 2014 at 12:02 AM
Yeah, no. Here's the output:
Oct 31, 2014 at 9:05 AM
First, the script uses the SDK 10.6 which you don't have. You should modify it to put the 10.8 version instead.

Second, it seems you are not using the standard shell the comes with Apple OSX Terminal application. I suspect that you have installed some software like Homebrew, MacPorts or other nix-like tools on your machine and this generates errors in the scripts. As you can see in the error log you posted, the paths seem truncated for some weird reason. Also check that the line ending the script file was not modified during it transfer.

The script is confirmed to work on standard OSX machines with Xcode. As a matter of policy, we only use native development environment on every platform in order to ensure the maximum reliability and reproducibility of the build process and its outputs.

Concerning OSXFuse, for now we have no other choices other than using it. Let's hope that the upcoming 3.0 version will bring more stability and reliability.
Oct 31, 2014 at 1:36 PM
The script was in DOS format.

Given the issues with OSXFuse, I guess I'll have to wait until the update comes out to try again.
Oct 31, 2014 at 3:16 PM
In your case, what's the best alternative to OSXFuse?

We can imagine to bundle two version of VeraCrypt, one targetting OSFuse and the other one targetting the other alternative.

Thank you for sharing your experience.
Nov 8, 2014 at 11:22 PM
While I don't know for certain, I am told MacFuse might be a suitable alternative.
Nov 8, 2014 at 11:39 PM
Well, MacFUSE project has stopped many years ago and is no longer maintained. OSXFuse started as a fork of MacFUSE. On some forums, people distribute some modified versions of MacFUSE that apparently solve some issues but this can't be considered as official releases. Maybe OSXFuse developer can incorporate some ideas from what others have modified in MacFUSE.
Jan 24, 2015 at 3:51 AM
idrassi wrote:
In the "src" directory, the file Readme.txt contains instructions on how to build VeraCrypt for Windows, Linux and MacOSX.
Hey there,

I just wanted to say thank you for all your work! I just successfully compiled Veracrypt on my ARM based Chromebook (via crouton chroot) using the instructions taken from the Readme.txt. I haven't compiled any bigger piece of software in years, but now I had to - and it worked flawlessly! There were no Truecrypt binaries for current ARM based Linux systems anywhere, which is why I was searching, came across Veracrypt and gave it a try.

One hint for everbody who might want to use Veracrypt on a similar setup: In order for it to work you need to ensure that in the Veracrypt GUI you select "Settings -> Preferences -> System Integraion -> Do not use kernel cryptographic services", as otherwise mounting a device will not work (probably an incompatibility with the Chrome OS Linux kernel or something). However, once that setting has been changed, everything works like a charm!

Thank you very much and please keep up the good work! From now on I will try to find the time and periodically compile upcoming veracrypt versions on my ARM Chromebook and report in case anything breaks the toolchain. So far everything works exactly like explained in the guide for Linux.

Jan 24, 2015 at 5:36 AM
haggster wrote:
In order for it to work you need to ensure that in the Veracrypt GUI you select "Settings -> Preferences -> System Integraion -> Do not use kernel cryptographic services", as otherwise mounting a device will not work (probably an incompatibility with the Chrome OS Linux kernel or something). However, once that setting has been changed, everything works like a charm!
Just a word of caution: Crypto stuff is different than any other program. "Everything works" is a necessary but insufficient condition to declare the program "ready to go". You just selected different crypto primitives in your execution path which, contrary to major OS kernel/framework services, have not been security-audited to the same assurance level. Since Truecrypt's (and VeraCrypt's) crypto routines have never been audited by external experts in the field, I would be cautious.
Jan 24, 2015 at 8:28 AM
Edited Jan 24, 2015 at 8:32 AM
Thank you haggster for sharing your experience on ARM Chromebook.

Are you willing to publish the binaries resulting from your build? I think it could be interesting for other users of ARM Linux and I can link to them or host them on the contrib part of VeraCrypt on Sourceforge.

Concerning the failure to work with kernel cryptographic service, it could come from the lack the dm-crypt kernel support in Chrome OS. When this option is checked (this is the default), VeraCrypt uses Device Mapper kernel module (dm-crypt through a call to dmsetup) to load volumes. If dm-crypt module is missing, you'll have an error (we try in the code to load it manually through modprobe but it won't help if it doesn't exist).

Can you please check if the dm-crypt is available or not on Chrome OS? I found some resources indicating that it is not present but I didn't find any official statement with this regard.

Concerning ninveh statement, I agree that one must be cautious before using unreliable cryptographic libraries. Nevertheless, the cryptographic primitives present on TrueCrypt and VeraCrypt have been checked by many experts and professionals and they are based on renowned public domain implementations. As one may expect, I personally spent a great deal of time checking those primitives and the overall implementations that uses them and I didn't find anything suspicious or non-conformant (apart from a bug that I corrected in the Serpent implementation of TrueCrypt that luckily had no effect on real world situations).

An audit is always welcomed and I'm open to any initiative on this side for VeraCrypt. On practice, little encryption products are really independently audited and even if they are audited there are always clouds about who has performed the audit, what context and the people behind such initiatives. Open source brings more transparency to any audit process of encryption solutions but sometimes this transparency can be hijacked by a certain elite who wants to impose itself as the custodians of cryptography or security. On these uncertain days, it is important to build a real community of security aware users and developers in order to bring a more democratic approach to encryption adoption and development.
Jan 24, 2015 at 12:05 PM
Edited Jan 24, 2015 at 12:07 PM
Idrassi, responding to your response to my statement, please note the following
  1. Common security issues in software are not with the encryption algorithms/primitives but with their implementation.
    I beg to differ on the actual "checking by many experts" - I researched this in the past and could not find any reference to a crypto audit (there were 2 bodies in the far past (one German and one French) that reviewed the general code, but as far as the crypto, they only looked at the volume headers. They did not delve into the crypto implementation). There was a fair amount on discussion on the Schneier blog in 2013 on this, and Kenn White and Matt Green et al, together with Schneier on the advisory board, established some kind of a foundation to contract out the audit of the TC code, but only got as far as the general code flow review (what they called Phase A). Nobody looked at the crypto part because right about the time they set up the crypto audit process, the TC foundation announced its demise, and the audit process died with it.
  2. Although open source is almost mandatory for having trust in crypto code, it does not guarantee that many eyes will look it it to find bugs. The most talked about crypto fail last year was related to openSSL, which certainly had many more followers and major corporations interests than in TC, but even there evidently nobody looked at the code. Another example from 6 years ago - the weak Debian keys due to removing 2 lines in the code by Debian developers who thought to optimize a specific section. No malice there - they just could not comprehend the danger in messing with crypto code.
Jan 24, 2015 at 2:21 PM
I agree with all what you said, ninveh. But, what is the point?
We have to stop using TrueCrypt/VeraCrypt/DiskCryptor and soon CipherShed?

We all on these projects do our best to provide state of the art encryption solutions. Obviously, mistakes can be made but we are all very careful about every single line we write since our work can have a large impact on many people working on dangerous situations or protecting sensitive information.

Should we just stop using encryption and wait for "approved" solutions?

Anyway, I don't want this thread to deviate from its original purpose although the subject of implementation trust is very important. Maybe we should open a new discussion.

I re-iterate here my request for sharing the Chrome OS binary and my question about the availability of dm-crypt in this OS.
Jan 24, 2015 at 2:45 PM
I just wanted to point out to the original poster that he/she now goes through a different code path, outside the tried-and-true WIN/MAC/Linux core crypto primitives that everybody else have been using for some years in TC/VC, and he/she should be cautious. Not necessarily to stop using VC on his/her unique system, but just to be aware of the possible implication. I myself would be confident with running VC on a Win machine, for example, but not on an ARM-based system.

And I totally agree that this thread is not the right place to continue with my comments.
Jan 24, 2015 at 8:27 PM
Edited Jan 24, 2015 at 8:31 PM
idrassi wrote:
I re-iterate here my request for sharing the Chrome OS binary and my question about the availability of dm-crypt in this OS.
Hi again,

Interesting discussion. First of all, I would to like to say that my main objective was to be able to open some of my old TrueCrypt containers that I have created years ago via my Chromebook and not depend on anybody else's Windows PC or similar. Therefore, rock solid security is not what I had in mind, at least not right now. However, I understand that many people take this very seriously, and since some people depend on real, uncompromisable security, they want to be sure they can trust in the implementation of the program they are using. In this case it was just out of technical interest and basically due to practical reasons.

I have uploaded the whole build directory after tar'zipping it. As I don't use Dropbox, I just used the first random share hoster I could find. Just let me know in case this one doesn't work or there are any other issues with it. The binaries can be found in the "Main" directory after unzipping the tarball.


The build environment and setup was:
  • ARM-based Samsung Series 3 Chromebook:
Version 39.0.2171.96
Platform 6310.68.0 (Official Build) stable-channel daisy
Firmware Google_Snow.2695.117.0

Latest crouton release as of January 23, 2015.

chroot: Xubuntu Trusty
uname -a
Linux localhost 3.8.11 #1 SMP Wed Dec 10 14:43:27 PST 2014 armv7l armv7l armv7l GNU/Linux

file veracrypt
veracrypt: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=bc4e6abe69e8b1fba8345126f48ca70c69175bea, stripped

GCC version:
gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)

I installed the packages of required libraries and header files via Synaptic before starting to build.

Screenshot of the Veracrypt GUI in the chroot Xfce desktop:



PS: I will try to find out whether dm-crypt is available on Chrome OS (or on this Chrome OS setup in particular) and let you know within this thread
Jan 25, 2015 at 1:47 AM
Edited Jan 25, 2015 at 2:03 AM
Thank you Haggster!
I have created an "ARM Linux" section in the folder Contributions on Sourceforge and I uploaded the setup script you built (after some renaming):

I'll communicate about this on Twitter to ask other users for feedback.
Jan 25, 2015 at 4:24 AM
Very cool. I just checked out the tweet as well. There might be quite some people who might find this useful, as there've been some more ARM based Chromebooks coming out over the last couple of months by several manufacturers. There's also some people who run pure Linux on these systems as dual boot options. In any case, a working implementation of Veracrypt is filling a gap here.

I tried to find out whether the Chrome OS kernel supports dm-crypt and it seems it does, however it seems it cannot be accessed properly from a chroot environment. I came across one older posting mentioning this on the crouton discussing board.

A couple of hours ago I was finally accessing an external USB drive with full drive encryption that I had encrypted using TrueCrypt over a year ago - from my Chromebook. Very happy. Hint for people who want to do the same: as the drive is encrypted, it won't appear in the list of mounted (accessible) drives in ChromeOS or any file explorer - therefore you'll have to check via "dmesg" what /dev device the drive was assigned. In my case it was /dev/sda1. Just enter that device directly into "Volume" field in the Veracrypt UI and it can be mounted.

Now off to bed, cannot believe it's that late already...

Jan 25, 2015 at 10:56 PM
Thank you for your efforts Haggster, I really appreciate.

If you have time, is it possible to build a console version of VeraCrypt? I think this could make it usable by more users.
Jan 26, 2015 at 1:49 AM
idrassi wrote:
If you have time, is it possible to build a console version of VeraCrypt? I think this could make it usable by more users.

I just tried... however, as I need to compile it with:


the WXSTATIC=1 part is giving me problems (I don't have the required sources). I compiled my working version which I uploaded yesterday with just "make".

I even tried only doing "make NOGUI=1" but that wouldn't work either.

As I don't have the sources (no /usr/src/wxWidgets or /usr/local/src/wxWidgets directory) and there don't seem to be any packages for it, I can also not perform the "make WXSTATIC=1 WX_ROOT=/usr/src/wxWidgets wxbuild" part.

I would need to get the wxWidgets source files in some other way, I think. I checked the wxWidgets website as well, which has a repository for deb packages; I added that one, but trying to view the repository contents ends in an error as they don't have the target ARM in their repo. I could check and see if I could get those packages or the source package in a different way, however I don't know if the sources contain any assembly code that might be Intel-only. There should obviously be some way (especially since the pre-compiled shared libs are available and I was able to install them from the Ubuntu repository), but I suspect that might all lead in dependency-hell and dozens of failed compiling sessions...

Sorry for my apparent imcompetence (I've got no real programming background and was just compiling lots of stuff around 15 years ago as a *BSD/Solaris user but haven't spent much time doing these things after that). If anyone has any hints on how to solve this, I'll give it another try though!

Jan 27, 2015 at 12:07 PM
Hi Haggster,

To my knowledge, wxWidgets code doesn't contain any assembly language so it should be possible to download the source and compile it yourself.
For example, if you extract the source to /home/user, you will get a folder called wxWidgets-3.0.2. From here, you can type:
  • export WX_ROOT=/home/user/wxWidgets-3.0.2
  • export WX_BUILD_DIR=/home/user/wxBuild
  • make WXSTATIC=1 NOGUI=1 wxbuild
  • make WXSTATIC=1 NOGUI=1 clean
  • make WXSTATIC=1 NOGUI=1
This should give you a console only binary that is statically linked to wxWidgets.
Actually, you can do the same for the GUI version of VeraCrypt in order to link also statically against wxWidgets. This will make the generated binary more portable.
Jan 27, 2015 at 7:10 PM
Worked like a charm:

Screenshot of this no-gui/shell-only version:

I also attempted to compile a statically linked build of the GUI-based version, however to my surprise that brought further issues, as make was complaining that I don't have some gtk+ dev files on my machine. I'm sure I could fix that though, in case anyone explicitly requests a statically linked GUI version of this.

The umask of the files inside the uploaded tarball might look a bit messed up since I did a chmod -R 777 on its root directory for reasons not worth mentioning.

I hope somebody will find this useful. Long live the arm architecture!

Thanks a lot for your assistance to get this running, idrassi.
Jan 29, 2015 at 9:33 AM
I have update the ARM archive on Sourceforge with the new binary. Thanks a lot!

Thank you also for your effort on the static build of the GUI version. I agree that it is not very important at this stage. This is the first ARM build of VeraCrypt and I hope there will be more feedback about it.
Feb 9, 2015 at 3:25 PM
The new Raspberry Pi 2 is now armv7 based and therefore should be able to run the precompiled statically linked build on the default Linux distro that comes with it. Anyone who already bought one and can test it? I'm planning on getting one myself and then putting NetBSD on it... I'll attempt another build with that one as well (should otherwise be possible to use the Linux binary compatibility though)

It seems like there've never been any builds for the original Raspberry Pi:
Feb 22, 2015 at 5:09 PM
Okay, I got myself a Raspberry Pi now and so I'm contributing another build: It's compiled as NOGUI, statically linked, compiled under Raspbian on the Raspberry Pi itself:


Download link:

The biggest difference to the other ARM build contributed earlier is that this one does not require armv7 CPUs, as can be seen in the screenshot in the output of the "file" command.

Please let me know in case you have any feedback.
Feb 24, 2015 at 9:56 PM
Edited Feb 25, 2015 at 9:14 AM
I have been unable to build VeraCrypt under OS X 10.7.5. I am trying to build a no gui version. I have sources at the same level for wxWidgets and VeraCrypt. I have pkg-config installed and Xcode and command line tools installed and I am using 10.6 SDK.
Feb 24, 2015 at 9:57 PM
Edited Feb 25, 2015 at 9:15 AM
The build output is viewable here:
Feb 25, 2015 at 8:41 AM

First, it would have been better to put a link towards a file containing the build logs instead of copying everything here (you could use pastbin for example). This kind of verbose output makes the thread unnecessary long and only few lines are really interesting.

Concerning your issue, the error indicates that the compiler can't find the definition of the standard function wcsdup which is not normal. Moreover, wxWidgets have been compiled successfully so this function exists.

What's your version of Xcode?
Do you have custom software like Homebrew or MacPorts?
Can you check that the directory /Developer/SDKs/MacOSX10.6.sdk exists? More generally, what's the content of /Developer/SDKs

I think it is just caused by the fact that we can't find the correct SDK to use.
Feb 25, 2015 at 10:09 AM
Edited Feb 25, 2015 at 10:19 AM

Thanks for your reply I've edited the previous post. I am using Xcode 4.6.3 Build version 4H1503 and I do not use Homebrew or MacPorts. I have '/Developer/SDKs/MacOSX10.6.sdk' and '/Developer/SDKs/MacOSX10.7.sdk' and they are both populated. I have compiled programs with the SDK's in the past and in the present.

Lines that seem strange to me are;
'/usr/bin/ranlib: file: /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a(baselib_extended.o) has no symbols'
'ranlib: file: /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a(baselib_extended.o) has no symbols'

which are prior to 'Cleaning Platform' and of course all of the 'error: <function name> was not declared in this scope' messages.

The final message prior to 'make[1]: *** [Application.o] Error 1'

'lipo: can't figure out the architecture type of: /var/folders/nd/bry7cy2s26qg7hxwhvyw9hkc0000gn/T//ccsW2Pri.out'

could be a hint as I would think that the architecture should be known very early in the make process.
Feb 25, 2015 at 10:44 AM

I tried a build using the 10.7 SDK and it made it through up to trying to link the wxWidgets library. If I'm interpreting the message correctly it appears that a wxWidgets (i386) library was not built or whatever was built or attempted to be built is unrecognizable.

'Linking VeraCrypt'
'ld: warning: ignoring file /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a, file was built for archive which is not the architecture being linked (i386): /Users/jimmy/Temp/VeraCrypt/wxBuild/lib/libwx_baseu-3.0.a'
Feb 25, 2015 at 11:09 AM

I completely missed the fact that you are building a NOGUI version as cited in your first message.
As you can see in the official build script for MacOSX, this is not supported.
This is caused by issues in the build of a console only version of wxWidgets under MacOSX (no problem on this side under Linux) which are due to dependencies issues on MacOSX that makes it impossible to remove GUI libraries from the build.

The objective a the NOGUI build is to have a smaller binary with minimal dependencies. On MacOSX, this is not possible and so the alternative is to use the --text switch on the normal binary. In this case, you can use the VeraCrypt binary outside the MacOSX bundle like a normal console binary.

Feb 25, 2015 at 9:07 PM
Edited Feb 25, 2015 at 9:24 PM

Firstly, thanks to all of you and your efforts in creating and maintaining VeraCrypt. The information you have given is completely missing from the documentation (Readme.txt) and in fact the documentation indicates that it is possible under the 'Instructions for Building VeraCrypt for Linux and Mac OS X:'. In that section it states that the 'NOGUI' parameter can be used to build a console-only executable. The specific make command is sited thereafter.

If you are indeed 100% sure that the developers have not been able to code for the creation of a 'NOGUI' version under OS X then I would suggest you adjust the documentation to indicate this so it does not mislead people and waste time for others in the future. Under the 'Mac OS X specifics:' section would be a good place to add that the 'NOGUI' option is unsupported and that the --text switch can be used as an alternative.
Feb 25, 2015 at 10:00 PM
I agree that the documentation should have warned about this. I apologize for this lack of clarification and for the wast of time it caused to you. I have just updated the Readme.txt file on git:

On the development side, TrueCrypt never provided a NOGUI binary for MacOSX and at the beginning of the VeraCrypt project I tried to build such version but I failed because of the dependencies issues I cited above. That's why I abandoned such effort but any help to make this work is welcomed.
Aug 14, 2015 at 7:48 PM
Good day all,

I've gone ahead and built GUI and Non-GUI versions of the veracrypt clients on my Rpi2. I'm running the latest firmware and have updated to Jessie.
Linux deimos 4.1.5-v7+ #809 SMP PREEMPT Thu Aug 13 00:50:56 BST 2015 armv7l GNU/Linux
Here's the GUI build againt GTK:
ii libgtk2.0-dev 2.24.25-3 armhf development files for the GTK+ library


My build environment consisted of a stock Raspbian Wheezy system on which a dist-upgrade had been performed. All of Haggsters instructions where followed save those that excluded GTK related options. My dev package list is as follows:

ii autotools-dev 20140911.1 all Update infrastructure for config.{guess,sub} files
ii comerr-dev 2.1-1.42.12-1.1 armhf common error description library - headers and static libraries
ii dpkg-dev 1.17.25 all Debian package development tools
ii iptables-dev 1.4.21-2 armhf iptables development files
ii libacl1-dev 2.2.52-2 armhf Access control list static libraries and headers
ii libapt-pkg-dev:armhf armhf development files for APT's libapt-pkg and libapt-inst
ii libasprintf-dev:armhf 0.19.3-2 armhf GNU Internationalization library development files
ii libatk-bridge2.0-dev:armhf 2.14.0-2 armhf Development files for the AT-SPI 2 toolkit bridge
ii libatk1.0-dev 2.14.0-1 armhf Development files for the ATK accessibility toolkit
ii libatspi2.0-dev 2.14.0-1 armhf Development files for the assistive technology service provider
ii libattr1-dev:armhf 1:2.4.47-2 armhf Extended attribute static libraries and headers
ii libblkid-dev:armhf 2.25.2-6 armhf block device id library - headers and static libraries
ii libbsd-dev:armhf 0.7.0-2 armhf utility functions from BSD systems - development files
ii libc-dev-bin 2.19-18 armhf GNU C Library: Development binaries
ii libc6-dev:armhf 2.19-18 armhf GNU C Library: Development Libraries and Header Files
ii libcairo2-dev 1.14.0-2.1 armhf Development files for the Cairo 2D graphics library
ii libdbus-1-dev:armhf 1.8.18-0+deb8u1 armhf simple interprocess messaging system (development headers)
ii libdbus-glib-1-dev 0.102-1 armhf simple interprocess messaging system (GLib interface)
ii libept-dev armhf High-level library for managing Debian package information
ii libexpat1-dev:armhf 2.1.0-6+deb8u1 armhf XML parsing C library - development kit
ii libffi-dev:armhf 3.1-2 armhf Foreign Function Interface library (development files)
ii libfontconfig1-dev:armhf 2.11.0-6.3 armhf generic font configuration library - development
ii libfreetype6-dev 2.5.2-3 armhf FreeType 2 font engine, development files
ii libfuse-dev 2.9.3-15+deb8u1 armhf Filesystem in Userspace (development)
ii libgcc-4.7-dev:armhf 4.7.3-11+rpi1 armhf GCC support library (development files)
ii libgcc-4.9-dev:armhf 4.9.2-10 armhf GCC support library (development files)
ii libgdk-pixbuf2.0-dev 2.31.1-2+b1 armhf GDK Pixbuf library (development files)
ii libgettextpo-dev:armhf 0.19.3-2 armhf GNU Internationalization library development files
ii libghc-terminfo-dev armhf Haskell bindings to the terminfo library
ii libghc6-terminfo-dev 1:8 all transitional dummy package
ii libglib2.0-dev 2.42.1-1 armhf Development files for the GLib library
ii libgmp-dev:armhf 2:6.0.0+dfsg-6+rpi1 armhf Multiprecision arithmetic library developers tools
ii libgtk-3-dev:armhf 3.14.5-1 armhf development files for the GTK+ library
ii libgtk2.0-dev 2.24.25-3 armhf development files for the GTK+ library
ii libharfbuzz-dev 0.9.35-2 armhf Development files for OpenType text shaping engine
ii libice-dev:armhf 2:1.0.9-1 armhf X11 Inter-Client Exchange library (development headers)
ii libkrb5-dev 1.12.1+dfsg-19 armhf Headers and development libraries for MIT Kerberos
ii libldap2-dev:armhf 2.4.40+dfsg-1 armhf OpenLDAP development libraries
ii libncurses5-dev:armhf 5.9+20140913-1 armhf developer's libraries for ncurses
ii libpam0g-dev:armhf 1.1.8-3.1 armhf Development files for PAM
ii libpango1.0-dev 1.36.8-3 armhf Development files for the Pango
ii libpcre3-dev:armhf 2:8.35-3.3 armhf Perl 5 Compatible Regular Expression Library - development files
ii libpixman-1-dev 0.33.1+git20140627-c37ff5-rpi2rpi1 armhf pixel-manipulation library for X and cairo (development files)
ii libpng12-dev:armhf 1.2.50-2 armhf PNG library - development
ii libpopt-dev:armhf 1.16-10 armhf lib for parsing cmdline parameters - development files
ii libpthread-stubs0-dev:armhf 0.3-4 armhf pthread stubs not provided by native libc, development files
ii libpython-dev:armhf 2.7.9-1 armhf header files and a static library for Python (default)
ii libpython2.7-dev:armhf 2.7.9-2 armhf Header files and a static library for Python (v2.7)
ii libraspberrypi-dev 1.20150421-1 armhf EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers)
ii libreadline-dev:armhf 6.3-8 armhf GNU readline and history libraries, development files
ii libreadline6-dev:armhf 6.3-8 armhf GNU readline and history libraries, development files
ii libselinux1-dev:armhf 2.3-2 armhf SELinux development headers
ii libsepol1-dev:armhf 2.3-2 armhf SELinux binary policy manipulation library and development files
ii libsm-dev:armhf 2:1.2.2-1 armhf X11 Session Management library (development headers)
ii libssl-dev:armhf</code>
Aug 14, 2015 at 9:18 PM

Thank you for posting this information but there are no links in your post to download the results of your build and your image link seem to not have been put correctly.

Can you please edit it your post to correct the links and image?
Dec 21, 2016 at 8:48 PM
Hi, I finally got around to compile an updated ARM build, based on the current Veracrypt version (1.19).

I've seen that there are some other people now who seem to have ARM builds now as well (mostly, or all, built on RasPi's), but since they all seem to have been built with NOGUI, I thought I'd contribute this updated build - with GUI - anyway, in order to fill that gap:

It's been built on the same Chromebook as the build from 2yrs ago, within a Ubuntu 14.04 setup