Prompted by a comment and this rainy day…
Myself, I mostly think of TrueCrypt as Windows software today, so I can’t say I use it much on FreeBSD. However, I haven’t had much trouble getting TrueCrypt 6.1a to build on FreeBSD 7.1, even though I may not use the end result.
So, starting off with a pretty much stock FreeBSD 7.1 system with Gnome 2.24 installed as my test environment, I was able to do something like the following to get TrueCrypt 6.1a to build from source.
I downloaded, verified, and extracted the TrueCrypt 6.1a source.
I took a look at the “Readme.txt” in the root of the extracted TrueCrypt source tree and ensured that I met the requirements listed in the “Requirements for Building TrueCrypt for Linux and Mac OS X” section. I found the bulk of what may be missing (I say “may be missing” because most dependencies were already met in this test setup) readily available in the FreeBSD ports tree (e.g., gmake, fusefs-kmod, fusefs-libs, pkg-config, wxgtk). I had PKCS#11 header files lying around, but I also tried downloading fresh ones (e.g., pkcs11.h, pkcs11f.h, pkcs11t.h) from the RSA ftp site.
One important note here – the FreeBSD ports has split wxWidgets into multiple versions/flavors. After glancing at the root TrueCrypt makefile, I decided to go with “wxgtk28-unicode” from the FreeBSD ports for the TrueCrypt build. This choice has later implications, as the TrueCrypt build defaults to the use of the generic “wx-config”, which will not exist when using one of the wxWidgets from the FreeBSD ports, since “wx-config” is renamed in accordance with the specific version/flavor of the installed FreeBSD port. While I didn’t notice the “Readme.txt” calling out that this can be tweaked, the root TrueCrypt makefile is clear here and the choice of “wx-config” can be conveniently overridden, as noted next.
With the dependencies done, I then followed the build instructions for Linux and Mac OS X in the “Readme.txt”, interpreting them for my environment. For my particular test setup, there were three main tweaks here – use “gmake” (GNU make) rather than “make” (the stock FreeBSD make), set “WX_CONFIG” appropriately (since I was using “wxgtk28-unicode”, I set this to “wxgtk2u-2.8-config” overriding the default “wx-config”), and set “PKCS11_INC” appropriately since the PKCS#11 header files I wanted to use were not in the default include paths used by the TrueCrypt build (I pointed this to the directory where I had the PKCS#11 header files). So, from the root directory of the TrueCrypt source tree, I ran something like “gmake WX_CONFIG=wxgtk2u-2.8-config PKCS11_INC=<path to downloaded header files>”.
After building successfully and prior to running the resulting “truecrypt” executable (found in “./Main” in the source tree), I checked to see if the FUSE kernel module was loaded. It wasn’t, so I loaded it (e.g., “sudo kldload /usr/local/modules/fuse.ko”).
Then I ran “truecrypt”. I ran its crypto tests, created a new TrueCrypt container with a UFS filesystem, and mounted, dismounted, and created/modified/deleted some files on this container. Everything appeared to be working.
And that is about all I can say about TrueCrypt 6.1a on FreeBSD 7.1. 
This really works and will compile truecrypt 6.1a on your freebsd 7.1 whitout any problems.
Also, i downloaded the RSA files from http://www.rsa.com/rsalabs/node.asp?id=2133
Well, maybe if you run into some problem, you can just read the Readme.txt MAC/Linux (inside truecrypt sources dir). Take a look into the WX_ROOT= part. This means, download the latest wxwidgets and set its path here.
So also i disabled the unnecessary GUI stuff, mainly because i never use it. So i used both commands from the Readme.
gmake NOGUI=1 WX_ROOT=/path/to/the/wxwidgetsource
gmake NOGUI=1 “something else i dont remember. see the Readme. its 2 cmds. this is the second”
And after this the executable will be under directory Main.
But now i have one problem, which is how to mount the truecrypt volume in freebsd. (The executable seems working)
/truecrypt-6.1a-source/Main/truecrypt /my/truecrypt.tc Desktop/TcVolume/
Enter password for /my/truecrypt.tc:
Enter keyfile [none]:
Protect hidden volume? (y=Yes/n=No) [No]:
Enter system administrator password:
Error: mount: /dev/md0 : Invalid argument
How can i solve this and mount ?
i think its something with mdconfig, maybe i should create one /dev/md0
but whats the correct way? anyone?
Great point, Joeman – TrueCrypt 6.1a can be built on FreeBSD 7.1 without installing a flavor of wxgtk from the FreeBSD ports, depending on your wants/needs.
As to your issue, I am not sure mdconfig is relevant, as TrueCrypt seems to have made it to the point of attempting to mount the file system on the attached memory disk for the container (“/dev/md0″) and the error coming from mount does not indicate that the device (“/dev/md0″) does not exist but rather may indicate that mount does not recognize the file system on “/dev/md0″. So, my first guess, since TC will automatically attempt to mount the file system on the container unless you tell it to do otherwise, the problem may be due to attempting to mount a container that does not have an fs type of the TC default fat (msdosfs) or the FreeBSD mount default ufs without explicitly telling TC the fs type to use through, say, the “–filesystem” command line option.
If there is an fs on the container but it is not fat or ufs, then you might try specifying the fs type using, say, the “–filesystem” TC command line option (e.g., “–filesystem=ntfs” for ntfs). (I am not sure there is a way to do this through the GUI, but that does not matter in your case.) Alternatively, you can have TC attach the container as a memory disk without attempting to mount its fs using, say, the “–filesystem” command line option set to “none” (i.e., “–filesystem=none”), and then try manually mounting the fs of the attached memory disk and so on as you see fit.
If there is no fs on the container, you might try creating one.
As noted above, you can have TC attached the container as a memory disk without attempting to mount its fs using, say, the “–filesystem=none” command line option, and then create a new fs on the attached memory disk as you see fit. Of course, depending on your needs, it might be easier to just wipe the empty container and use TC to create a new one, but this time with an fs.
(Needless to say, whatever you try, if the container actually contains data you care about, it would be wise to back it up first.)