VeraCrypt is a free disk encryption software brought to you by IDRIX (http://www.idrix.fr) and that is based on TrueCrypt. It adds enhanced security to the algorithms used for system and partitions encryption making it immune to new developments in brute-force attacks. For example, when the system partition is encrypted, TrueCrypt uses PBKDF2-RIPEMD160 with 1000 iterations whereas in VeraCrypt we use 327661. And for standard containers and other partitions, TrueCrypt uses at most 2000 iterations but VeraCrypt uses 655331 for RIPEMD160 and 500000 iterations for SHA-2 and Whirlpool. This enhanced security adds some delay only to the opening of encrypted partitions without any performance impact to the application use phase. This is acceptable to the legitimate owner but it makes it much more harder for an attacker to gain access to the encrypted data. VeraCrypt storage format is INCOMPATIBLE with TrueCrypt storage format. VeraCrypt is available in many languages other than English : Get the language file that you need from this link and copy it to the installation directory. Then launch VeraCrypt and go to menu "Settings" -> "Language..." and choose your language from the list. Reproducible: Always
VeraCrypt version 1.0f now available: https://veracrypt.codeplex.com/
it would be nice to get this in portage. truecrapt is not anymore :) thanks
Since VeraCrypt is based on TrueCrypt, I tuned the TrueCrypt ebuild. For the most part it was a search and replace effort. I had to change the patches a bit to work with VeraCrypt's code changes. But it works on my x86 and amd64 systems: I can open TrueCrypt volumes with it, data seems to be intact when diffed to the same volume opened with TrueCrypt 7.1a; and I did a quick successful write test. some remarks: * app-crypt/wxGTK:2.9 is now required -- instead of app-crypt/wxGTK:2.8 * I removed some packaging commands, which were added in VeraCrypt -- one dependency less (on app-arch/makeself) and superfluous when the source is handled with an ebuild * version 1.0f can actually open TrueCrypt containers -- even 6.0, according to https://veracrypt.codeplex.com/releases/view/565079, though I did not test 6.0 containers * I was not able to mount TrueCrypt containers with the GUI (ticking the appropiate checkbox); I usually use the command line interface anyway, which works; caveat: the "--truecrypt" option isn't documented and requires a bogus parameter, like `veracrypt --text --truecrypt "thisisbull" <path-truecrypt-container> <path-mount-directory>`; * I tested the init.d script: works I will attach a patch for the ebuild and an archive containing the new ebuild and all modified patches and files.
Created attachment 396296 [details, diff] patch to the TrueCrypt ebuild
Created attachment 396298 [details] VeraCrypt ebuild and related files
I get this message very often /var/tmp/portage/x11-libs/wxGTK-2.9.4.1-r1/work/wxPython-src-2.9.4.0/src/unix/threadpsx.cpp(1296): assert "m_internal->GetId()" failed in Run(): must call wxThread::Create() first I was also not able to create a new veracrypt-container. Mounting devices works.
Ok, mounting also only works from the command-line with --text. Maybe it’s related to the given error above.
Created attachment 399194 [details, diff] patch to the TrueCrypt ebuild
Created attachment 399196 [details] VeraCrypt ebuilds and related files
(In reply to Matthias Blümel from comment #7) > Ok, mounting also only works from the command-line with --text. Maybe it’s > related to the given error above. It probably is. My mistake: I did not bother to read the README until now -- I just needed the text interface anyway. VeraCrypt is actually based on x11-libs/wxGTK:3.0. I made a new revision "-r1" with a slight change, which seems to fix your issues. At least, I don't get errors or warnings and I can mount TrueCrypt volumes through the GUI.
new version releases and the ebuild dont work anymore, because it only try to download a absolute link path
(In reply to tman from comment #11) > new version releases Thanks for the update. > and the ebuild dont work anymore, because it only try > to download a absolute link path Well, Codeplex is clearly not the best option, when trying to access a release tar-ball in a predictable manner: 1) Codeplex does not have an URL scheme from which URLs for new versions can be derived. You have to determine the URL anew each time. 2) On top of that the old link gets invalidated if a new release is published. No idea, why they don't have permanent URLs. Or, maybe I screwed up somehow. Cdeplex's main purpose seems to be for Windows software anyways. But, I just realized the repository and releases are hosted on GitHub as well. So, here is my latest try, which should be a lot more robust.
Created attachment 400924 [details, diff] patch to the TrueCrypt ebuild
Created attachment 400926 [details] VeraCrypt ebuilds and related files
(In reply to Christian Burger from comment #14) > Created attachment 400926 [details] > VeraCrypt ebuilds and related files Crypt-VeraCrypt_1.0f/src -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src/Crypto -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/temp/pkcs11/ -O2 -fno-strict-aliasing -D TC_ARCH_X64 -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections -Wall -Wno-unused-parameter -march=corei7 -O2 -pipe -DCKR_NEW_PIN_MODE=0x000001B0 -DCKR_NEXT_OTP=0x000001B1 -c Hash.cpp -o Hash.o Compiling Keyfile.cpp Compiling Pkcs5Kdf.cpp x86_64-pc-linux-gnu-g++ -MMD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src/Crypto -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/temp/pkcs11/ -O2 -fno-strict-aliasing -D TC_ARCH_X64 -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections -Wall -Wno-unused-parameter -march=corei7 -O2 -pipe -DCKR_NEW_PIN_MODE=0x000001B0 -DCKR_NEXT_OTP=0x000001B1 -c Keyfile.cpp -o Keyfile.o x86_64-pc-linux-gnu-g++ -MMD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src/Crypto -I/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/temp/pkcs11/ -O2 -fno-strict-aliasing -D TC_ARCH_X64 -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections -Wall -Wno-unused-parameter -march=corei7 -O2 -pipe -DCKR_NEW_PIN_MODE=0x000001B0 -DCKR_NEXT_OTP=0x000001B1 -c Pkcs5Kdf.cpp -o Pkcs5Kdf.o In file included from Keyfile.cpp:10:0: /var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src/Common/SecurityToken.h:43:21: fatal error: pkcs11.h: No such file or directory # include <pkcs11.h> ^ compilation terminated. /var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src/Build/Include/Makefile.inc:20: recipe for target 'Keyfile.o' failed make[1]: *** [Keyfile.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/var/tmp/portage/app-crypt/veracrypt-1.0f-r2/work/VeraCrypt-VeraCrypt_1.0f/src/Volume' Makefile:284: recipe for target 'all' failed make: *** [all] Error 2
Created attachment 401084 [details, diff] patch to the TrueCrypt ebuild
Created attachment 401086 [details] VeraCrypt ebuilds and related files
Whoops, I tested all three ebuilds. But testing on my dev system was not enough -- too much clutter of the dev process kept the ebuilds working. Thanks.
1) compilation runs fine 2) emerge runs fine 3) but creating a container dont work, its dont accept the password u have set for the container after finishing :(( bug?
Created attachment 403630 [details] Veracrypt ebuild fixes for making repoman happy - Include a metadata.xml for now without maintainer or herd tag (feel free to change longdescription) - Replace spaces in line 10/12 by tabs - Remove useless empty line 31
tman, I tested the r2 ebuild, could create a container and mount it properly. The creation wizard in wxGTK did freeze KDE completely until X restart, so I might not recommended it yet. Mounting went well. Did you somehow circumvent the Ascii letter password restriction? Or was the keyboard layout different during creation? (tty vs X11; accidentally switched X11 layout by hitting toggle key shortcut etc.) Besides that, do you have any idea how to create a portable linux version of veracrypt? It might be possible by copying the veracrypt binary accompanied by its library deps and invocating it by a bash script with LD_PRELOAD set accordingly. Not sure about that though.
Just a more important note on the license, which I intended to post also on the previous comment. https://veracrypt.codeplex.com/license According to that site veracrypt seems also to be distributed with Ms-PL. I´m not a lawyer, but truecrypt-3.0 clearly states, that modified versions have to comply to truecrypt-3.0 license and, if they are distributed with a different license, it is not allowed to weaken truecrypt-3.0. Ms-PL does not seem to be as strong as truecrypt-3.0, so this might be a legal issue. Just a layperson point of view.
(In reply to Manuel Ullmann from comment #22) > Just a more important note on the license, which I intended to post also on > the previous comment. > https://veracrypt.codeplex.com/license > According to that site veracrypt seems also to be distributed with Ms-PL. > I´m not a lawyer, but truecrypt-3.0 clearly states, that modified versions > have to comply to truecrypt-3.0 license and, if they are distributed with a > different license, it is not allowed to weaken truecrypt-3.0. Ms-PL does not > seem to be as strong as truecrypt-3.0, so this might be a legal issue. > Just a layperson point of view. However, there is a GPL3 replacement for TrueCrypt/VeraCrypt. See https://bugs.gentoo.org/show_bug.cgi?id=547410
--- Comment #19 from tman --- > 3) but creating a container dont work, its dont accept the password u have > set for the container after finishing :(( Cannot verify the problem at my end, as well. Created a container via GUI, and opened it successfully right away. --- Comment #20 from Manuel Ullmann --- > Veracrypt ebuild fixes for making repoman happy Thanks for fixing my mess. --- Comment #21 from Manuel Ullmann --- > Besides that, do you have any idea how to create a portable linux version of > veracrypt? It might be possible by copying the veracrypt binary accompanied > by its library deps and invocating it by a bash script with LD_PRELOAD set > accordingly. Not sure about that though. Wouldn't the program still fail on start-up if the libraries are not available on the system? As far as I understand, LD_PRELOAD does not override the ELF header, so the program will try to load the libraries required as per ELF header nevertheless. Wouldn't LD_LIBRARY_PATH be more appropiate? This should gather all library files one needs: lddtree /usr/bin/veracrypt | sed -ne '2,$ {s/^[^/]\+//;p}' | xargs readlink -f --- Comment #22 from Manuel Ullmann --- > https://veracrypt.codeplex.com/license > According to that site veracrypt seems also to be distributed with Ms-PL. The project seems to be actually distributed with the VeraCrypt License, which again is governed by the TrueCrypt License: https://veracrypt.codeplex.com/SourceControl/latest#src/License.txt --- Comment #23 from Vincent Hardy --- > However, there is a GPL3 replacement for TrueCrypt/VeraCrypt. See They state they forked from TrueCrypt. I am wondering how they can do that and relicense it under GPL-3? I did a quick comparison between both sources and it's seems to be a fork. And III.1.e. of the TrueCrypt license states amongst other things: | You must include the following items with every copy of Your Product that | You make and distribute: a clear and conspicuous notice stating that Your | Product or portion(s) thereof is/are governed by this version of the | TrueCrypt License, a verbatim copy of this version of the TrueCrypt License Which means in my eyes, that you cannot really relicense any product derived from TrueCrypt as Manuel pointed out before.
(In reply to Christian Burger from comment #24) > Thanks for fixing my mess. You´re welcome. ;-) It was just a matter of typing 'repoman full' and doing as pleased, so no problem. > Wouldn't the program still fail on start-up if the libraries are not > available on the system? As far as I understand, LD_PRELOAD does not > override the ELF header, so the program will try to load the libraries > required as per ELF header nevertheless. Wouldn't LD_LIBRARY_PATH be more > appropiate? > > This should gather all library files one needs: > lddtree /usr/bin/veracrypt | > sed -ne '2,$ {s/^[^/]\+//;p}' | > xargs readlink -f LD_LIBRARY_PATH indeed seems to be more appropriate. Thanks for the hint and command. > > https://veracrypt.codeplex.com/license > > According to that site veracrypt seems also to be distributed with Ms-PL. > > The project seems to be actually distributed with the VeraCrypt License, > which again is governed by the TrueCrypt License: > https://veracrypt.codeplex.com/SourceControl/latest#src/License.txt Ok, that license seems to extend Truecrypt License to Veracrypt trademark protection, but otherwise does not weaken it, since it is completely contained. > Which means in my eyes, that you cannot really relicense any product derived > from TrueCrypt as Manuel pointed out before. Agreed.
Created attachment 408602 [details] Veracrypt ebuild Modified from abadonna-overlay
I've modified the veracrypt ebuild that's on the abadonna-overlay, and upgraded to version 1.12. Works for me on ~amd64. Not sure how the dependencies function, but that code in comment #24 gives the following here: /usr/lib64/libfuse.so.2.9.4 /usr/lib64/libwx_gtk2u_adv-3.0.so.0.2.0 /usr/lib64/libgtk-x11-2.0.so.0.2400.28 /usr/lib64/libXrender.so.1.3.0 /usr/lib64/libXinerama.so.1.0.0 /usr/lib64/libXi.so.6.1.0 /usr/lib64/libXrandr.so.2.2.0 /usr/lib64/libXcursor.so.1.0.2 /usr/lib64/libXext.so.6.4.0 /usr/lib64/libgmodule-2.0.so.0.4200.2 /usr/lib64/libpangocairo-1.0.so.0.3600.8 /usr/lib64/libXcomposite.so.1.0.0 /usr/lib64/libXdamage.so.1.1.0 /usr/lib64/libXfixes.so.3.1.0 /usr/lib64/libatk-1.0.so.0.21409.1 /usr/lib64/libcairo.so.2.11400.2 /usr/lib64/libpixman-1.so.0.32.6 /usr/lib64/opengl/xorg-x11/lib/libEGL.so.1.0.0 /usr/lib64/libX11-xcb.so.1.0.0 /usr/lib64/libxcb-dri2.so.0.0.0 /usr/lib64/libXau.so.6.0.0 /usr/lib64/libXdmcp.so.6.0.0 /usr/lib64/libxcb-xfixes.so.0.0.0 /usr/lib64/libxcb-shape.so.0.0.0 /usr/lib64/libgbm.so.1.0.0 /usr/lib64/libwayland-client.so.0.3.0 /usr/lib64/libffi.so.6.0.1 /usr/lib64/libwayland-server.so.0.1.0 /usr/lib64/libglapi.so.0.0.0 /usr/lib64/libexpat.so.1.6.0 /usr/lib64/libdrm.so.2.4.0 /usr/lib64/libpng16.so.16.16.0 /usr/lib64/libxcb-shm.so.0.0.0 /usr/lib64/libxcb-render.so.0.0.0 /usr/lib64/libxcb.so.1.1.0 /lib64/libz.so.1.2.8 /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2.0 /usr/lib64/libxcb-glx.so.0.0.0 /usr/lib64/libxcb-dri3.so.0.0.0 /usr/lib64/libxcb-present.so.0.0.0 /usr/lib64/libxcb-randr.so.0.1.0 /usr/lib64/libxcb-sync.so.1.0.0 /usr/lib64/libxshmfence.so.1.0.0 /usr/lib64/libXxf86vm.so.1.0.0 /lib64/librt-2.20.so /usr/lib64/libgio-2.0.so.0.4200.2 /lib64/libresolv-2.20.so /usr/lib64/libpangoft2-1.0.so.0.3600.8 /usr/lib64/libharfbuzz.so.0.938.0 /usr/lib64/libgraphite2.so.3.0.1 /usr/lib64/libfontconfig.so.1.8.0 /usr/lib64/libfreetype.so.6.11.4 /lib64/libbz2.so.1.0.6 /usr/lib64/libgdk-x11-2.0.so.0.2400.28 /usr/lib64/libgdk_pixbuf-2.0.so.0.3000.8 /usr/lib64/libpango-1.0.so.0.3600.8 /usr/lib64/libgobject-2.0.so.0.4200.2 /usr/lib64/libglib-2.0.so.0.4200.2 /usr/lib64/libX11.so.6.3.0 /usr/lib64/libnotify.so.4.0.0 /usr/lib64/libSDL-1.2.so.0.11.4 /usr/lib64/libasound.so.2.0.0 /usr/lib64/libpulse-simple.so.0.1.0 /usr/lib64/pulseaudio/libpulsecommon-5.0.so /usr/lib64/libICE.so.6.3.0 /usr/lib64/libSM.so.6.0.1 /lib64/libuuid.so.1.3.0 /usr/lib64/libXtst.so.6.1.0 /usr/lib64/libjson-c.so.2.0.1 /lib64/libwrap.so.0.7.6 /usr/lib64/libsndfile.so.1.0.25 /usr/lib64/libFLAC.so.8.3.0 /usr/lib64/libogg.so.0.8.1 /usr/lib64/libvorbisenc.so.2.0.10 /usr/lib64/libvorbis.so.0.4.7 /usr/lib64/libasyncns.so.0.3.1 /usr/lib64/libdbus-1.so.3.8.11 /usr/lib64/libgdbm.so.4.0.0 /lib64/libcap.so.2.22 /lib64/libattr.so.1.1.0 /usr/lib64/libpulse.so.0.17.3 /usr/lib64/libwx_gtk2u_core-3.0.so.0.2.0 /usr/lib64/libjpeg.so.62.1.0 /usr/lib64/libtiff.so.5.2.0 /usr/lib64/libwx_baseu-3.0.so.0.2.0 /lib64/libdl-2.20.so /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6.0.20 /lib64/libm-2.20.so /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.3/libgcc_s.so.1 /lib64/libpthread-2.20.so /lib64/libc-2.20.so
Created attachment 409014 [details] ebuild Upstream updated to 1.13 - ebuild works for me.
Created attachment 409094 [details] ebuilds and patches for VeraCrypt version 1.13 and 1.0f (In reply to gentoo from comment #27) > I've modified the veracrypt ebuild that's on the abadonna-overlay, and > upgraded to version 1.12. Any particular reason you did not use the provided ebuild? The ebuild you provide installs a few more packages and depends on version 4.9 of GCC which is still ~arch masked. > Works for me on ~amd64. I am not running ~arch and I don't want to take the risk of unmasking gcc-4.9 just for VeraCrypt. So, I upgraded my variant to 1.13, too, which should incorporate the changes for Gentoo QA, that Manuel previously provided in another tar-ball. > Not sure how the dependencies function, but that code in comment #24 gives > the following here: That's just for the possibility to make it portable (running from an USB stick) — not sure how far anyone has gotten. Including the right dependencies in the ebuild is a bit different. You would not need to record all the packages providing the shown library files in DEPEND and friends.
New upstream releases 1.14 and 1.15 https://veracrypt.codeplex.com/wikipage?title=Release%20Notes&version=25 The renamed 1.13 ebuild: https://bugs.gentoo.org/attachment.cgi?id=409094 works for me with version 1.15.
> That's just for the possibility to make it portable (running from an USB > stick) — not sure how far anyone has gotten. > > Including the right dependencies in the ebuild is a bit different. You would > not need to record all the packages providing the shown library files in > DEPEND and friends. About the portability: I’m afraid, that’s quite tricky. It’s been months, since I tested that. Sorry for not reporting back. Was busy keeping systemd booting. So please don’t mind any incorrect remembering. First you need to parse ldd output to find the dynamic libraries, required for starting. I needed that functionality for my custom initramfs generation script, so that would not matter. A main problem are gtk and pango libraries, which set their module path at compile time. So in fact you would need a *fixed* mount point, where the portable memory device is mounted. Since you need root permissions for mounting, that shouldn’t be a problem though. The module paths wouldn’t be an issue, since you have to compile any deps and veracrypt itself with generic (i.e. non optimized) CFLAGS. Otherwise you get SIGILL. I have seen Fluendo using their own gtk library (with non-standard module path) for their players as well as RUNPATH set in binary for portability. The actual problem arrising is, that setting the module path for the gtk/pango ebuilds is currently not possible. Also portage would need to build for portable installations. Most likely this could be implemented by defining a reserved configuration file like /etc/portage/env/portable.conf, which would be used with a special command line option. Another possible issue could be, that ldd finds just dynamically linked libraries, but there might be more files required. You can use strace to look them up. My script does also implement that (parsing strace output and copying files), but I admit, that I did not manage (yet) to get plymouth running in the initrd, mostly because I should trace systemd-udevd in the busybox rescue shell. which currently hangs. Usually the system linker library is used. If I recall correctly this involves always libc, which can be incompatible to Gentoo (i.e. Debian wheezy). Linux Mint showed the pango module issues after manual gtk module installation. A final note on the license: They switched from Ms-Pl (https://veracrypt.codeplex.com/license?LicenseHistoryId=120858) to Apache 2.0 (https://veracrypt.codeplex.com/license?LicenseHistoryId=599567). Not sure, whether that would be compatible (did not read it yet), but actually I’d doubt it and it does not nullify the original violation. I guess they don’t care about that.
1.17 (February 13th, 2016): https://veracrypt.codeplex.com/wikipage?title=Release%20Notes - Cut mount/boot time by half thanks to a clever optimization of key derivation Has someone please a working ebuild for this new version?
Created attachment 425610 [details] ebuild for veracrypt 1.17 Ebuild based on Christian Burger's ebuild for Veracrypt 1.13. Needs updated veracrypt-1.17-remove-packaging-from-makefile.patch
Created attachment 425612 [details, diff] Makefile patch for veracrypt-1.17 This patch is needed for veracrypt-1.17.ebuild
(In reply to Sandino Araico Sanchez from comment #33) > Created attachment 425610 [details] > ebuild for veracrypt 1.17 > > Ebuild based on Christian Burger's ebuild for Veracrypt 1.13. > > Needs updated veracrypt-1.17-remove-packaging-from-makefile.patch Thank you very much!
To mount veracrypt volumes you can use app-crypt/zuluCrypt
Created attachment 451656 [details] veracrypt-1.19 ebuild archive with updated patches Veracrypt 1.19 contains security patches from the code review, which changed a few line numbers of the patched files. Updated the execstack and packaging-removing patches. Root of the archive is your local overlay, because the archive contains the truecrypt-3.0 license. Content list: licenses/truecrypt-3.0 app-crypt/veracrypt/ app-crypt/veracrypt/Manifest app-crypt/veracrypt/metadata.xml app-crypt/veracrypt/files/ app-crypt/veracrypt/files/veracrypt-stop.sh app-crypt/veracrypt/files/veracrypt-1.17-remove-packaging-from-makefile.patch app-crypt/veracrypt/files/veracrypt-1.19-execstack-fix.diff app-crypt/veracrypt/files/makefile-archdetect.diff app-crypt/veracrypt/files/execstack-fix.diff app-crypt/veracrypt/files/veracrypt-1.19-remove-packaging-from-makefile.patch app-crypt/veracrypt/files/veracrypt.init app-crypt/veracrypt/files/veracrypt-1.13-remove-packaging-from-makefile.patch app-crypt/veracrypt/files/veracrypt-1.13-link-with-libdl.patch app-crypt/veracrypt/veracrypt-1.13.ebuild app-crypt/veracrypt/veracrypt-1.17.ebuild app-crypt/veracrypt/veracrypt-1.19.ebuild
https://github.com/gentoo/gentoo/pull/3098
Build fails on one of my machines; Compiling UserPreferences.cpp x86_64-pc-linux-gnu-g++ -MMD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -I/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src -I/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src/Crypto -DTC_NO_GUI -I/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src/PKCS11 -O2 -fno-strict-aliasing -D TC_ARCH_X64 -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections -Wall -Wno-unused-parameter -msse2 -maes -march=core2 -O2 -pipe -fomit-frame-pointer -I/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src/Main -I/usr/lib64/wx/include/base-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -pthread -c UserPreferences.cpp -o UserPreferences.o In file included from /usr/include/wx-3.0/wx/apptrait.h:176:0, from UserInterface.cpp:16: /usr/include/wx-3.0/wx/unix/apptbase.h:15:27: fatal error: wx/evtloopsrc.h: No such file or directory compilation terminated. make[1]: *** [/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src/Build/Include/Makefile.inc:24: UserInterface.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src/Main' make: *** [Makefile:338: all] Error 2 * ERROR: app-crypt/veracrypt-1.19::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=app-crypt/veracrypt-1.19::gentoo'`, * the complete build log and the output of `emerge -pqv '=app-crypt/veracrypt-1.19::gentoo'`. * The complete build log is located at '/var/log/portage/app-crypt:veracrypt-1.19:20170104-105743.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/app-crypt/veracrypt-1.19/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-crypt/veracrypt-1.19/temp/environment'. * Working directory: '/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src' * S: '/var/tmp/portage/app-crypt/veracrypt-1.19/work/VeraCrypt-VeraCrypt_1.19/src' Even though find /usr -name evtloopsrc.h /usr/include/wx-3.0/wx/unix/evtloopsrc.h
Your compiler is looking for /usr/include/wx-3.0/wx/evtloopsrc.h but this file is only available when you compile x11-libs/wxGTK with USE=X I tried compiling wxGTK veracrypt 1.19 with USE=-X but more errors showed up, some of them related to wrong include files and some others about missing class declarations derived from missing include sentences. USE=-X x11-libs/wxGTK will need some patching to fix those wrong include sentences when complied with USE=-X USE=-X app-crypt/veracrypt-1.19 will also need some patching (I think a few includes are enough) to fix compilation errors about wrong class declarations in wxGTK. With USE=X both compile fine on my machine and the errors you report are easy to reproduce with USE=-X.
With USE=-X x11-libs/wxGTK-2.8.12.1-r1 veracrypt compiles fine. The problem is with wxGTK-3.0.
(In reply to Sandino Araico Sanchez from comment #41) > With USE=-X x11-libs/wxGTK-2.8.12.1-r1 veracrypt compiles fine. The problem > is with wxGTK-3.0. Sorry, wrong test. Veracrypt was compiling with wxGTK-3.0 +X installed on another slot. Forget about wxGTK-2.8.
Let's file new bugs for such things since this bug is about getting veracrypt into the tree, which is resolved: commit 4702d718233d2698a409841f9589d9c3ddd1933e Author: soredake <fdsfgs@krutt.org> AuthorDate: Mon Dec 12 13:23:21 2016 +0200 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: Thu Dec 22 04:23:58 2016 -0500 app-crypt/veracrypt: initial commit with version 1.19 Veracrypt is a platform independent filesystem or container encryptor derived from truecrypt.
New bug #605018 contains the fixed ebuilds and their patches for wxGTK and veracrypt in response to comment 39.
