I just made a VPN network between my VPS's and wanted them to run some John the Ripper tasks. I followed this manual, but since 1.8.0 version John the Ripper's Makefile does not have the following lines, which it refers to:
CC = mpicc -DHAVE_MPI -DJOHN_MPI_BARRIER -DJOHN_MPI_ABORT`
MPIOBJ = john-mpi.o
There's a legacy Makefile, which has the
CC = mpicc -DHAVE_MPI
part, but, when I tried to compile with this, I see a lot of errors. I assume this legacy Makefile is not longer supported.
How can I enable OpenMPI support when compiling John the Ripper?
In case it matters, I am running Ubuntu.
Don't use that Makefile.
Do this:
./configure --enable-mpi
See if the report gave yes for OpenMPI
Then:
make -s
Related
My question is how can I recompile Crypto++ with GCC-4.8 in FreeBSD 9.2?
I'm having the following error, and I noticed that recompiling CrypTopp would solve the problem.
undefined reference to `CryptoPP::AlignedDeallocate(void*)'
Thanks!
My question is how can I recompile Crypto++ with GCC-4.8 in FreeBSD 9.2?
There's usually 3 or 4 things to be mindful of with later versions of GCC and the BSDs. They are enumerated below. If you have a specific problem, then you should ask.
-----
First, install gmake and use it instead of the BSD's anemic make. So you would compile with something like:
cd cryptopp
gmake GNUmakefile
I think other dependencies include gettext and libiconv.
-----
Second, the Crypto++ makefile sometimes blows away your choice of CXX and maybe LD. Open the GNUmakefile and hard code them to want you want if its occurring.
-----
Third, Crypto++ has some bug fixes for dependent name lookups. This only affects later versions of GCC, like 4.7 or 4.8 and above. See, for example, Unable to make on MingW due to unrecognized option.
So you should be using Crypto++ from SVN, and not the ZIP file from the website. See SVN on the Crypto++ wiki on how to check it out.
-----
Fourth, install Crypto++ into /usr/local, and not /usr. For some reason, one of the BSDs (OpenBSD) treat everything in /usr/include as a C file, and does not honor a C++ file. It will lead to unexplained compile failures. You can read about it on the Crypto++ wiki: Linux and OpenBSD.
So your install would look like:
sudo gmake install PREFIX=/usr/local
-----
There should also be a port available. You should try and use it if its available. For example its available as cryptopp-5.6.3-2 under FreeBSD. OpenBSD has a patch at Fix: net/synergy, so its probably available in their ports tree, too.
-----
Finally, there is a Crypto++ wiki page covering Linux and the BSDs at Linux and BSD. Its basically everything I know about building and running Crypto++ on *nix variants. If you are a die hard BSD guy, then my apologies for lumping Linux and BSD together on one page.
Pantheios INSTALL.TXT says:
Open a command shell in the appropriate directory that matches your compiler: ...
My compiler is Clang:
> gcc --version
Apple LLVM version 5.1 (clang-503.0.40) ...
Target: x86_64-apple-darwin13.3.0
Which of the compiler settings files in Pantheios 1.0.1-beta214 is the most appropriate?
You can use homebrew to install an older version of gcc (e.g., gcc-4.2) and use the matching Pantheios makefile, like this:
brew install gcc42
make CC=gcc-4.2
However, as far as I have been able to tell, Pantheios is not going to be buildable on a recently-updated system. For example, as of today, building on OSX looks like this:
04:29:23 ~/src/pantheios-1.0.1-beta214/build/gcc42.unix$ make CC=gcc-4.2
Ensuring all STLSoft C source files are in UNIX format
sed: RE error: illegal byte sequence
make: *** [/Users/username/src/stlsoft-1.9.118/include/stlsoft/internal/dos2unix.has.been.performed] Error 1
I have also tried building on Windows as recently as 6 months ago and lost a good bit of time on it before giving up.
The library hasn't been updated in a very long time and the author has very little online activity since then. I call that "abandoned software". Building will very likely require a non-trivial amount of work on your part. I'd highly recommend severing the dependency on STLSoft if you do because it also appears to be abandoned.
Has anyone successfully compiled TCC on OS X?
From what I know it should be possible but when I run make I get the following error:
$ make
gcc -o tcc tcc.c -DTCC_TARGET_I386 -O2 -g -Wall -fno-strict-aliasing -mpreferred-stack- boundary=2 -march=i386 -falign-functions=0 -Wno-pointer-sign -Wno-sign-compare -D_FORTIFY_SOURCE=0 -lm -ldl
tcc.c:1: error: CPU you selected does not support x86-64 instruction set
tcc.c:1: error: CPU you selected does not support x86-64 instruction set
tcc.c:1: error: -mpreferred-stack-boundary=2 is not between 4 and 12
make: *** [tcc] Error 1
./configure runs fine and gives the following output:
$ ./configure
Binary directory /usr/local/bin
TinyCC directory /usr/local/lib/tcc
Library directory /usr/local/lib
Include directory /usr/local/include
Manual directory /usr/local/man
Doc directory /usr/local/share/doc/tcc
Target root prefix
Source path /Users/aaron/Downloads/tcc-0.9.25
C compiler gcc
CPU x86
Big Endian no
gprof enabled no
cross compilers no
use libgcc no
Creating config.mak and config.h
I'm pretty sure the issue is something simple, but I haven't compiled enough programs on OS X to be aware of the pratfalls...
The primary purpose for installing TCC was to get libtcc so I could start experimenting with dynamic code generation from Ruby (in case that makes a difference :-p)
Thanks!
I have just spent some serious time trying to make tcc run on osx. I have included several fixes, including the one from the answer above, and now they are all in the development repository at http://repo.or.cz/w/tinycc.git. Building, some tests and all examples should work.
I am not sure if you are aware, but http://bellard.org/tcc/ site that belongs to Fabrice Bellard who started this project, is not being updated very regularly. Mostly because there are not many 'official' tcc releases. tcc is one of those projects that mostly lives off of live sources and updates. So if you want to give this another try, please go to http://repo.or.cz/w/tinycc.git and get the 'mob' branch (not 'master'). Please see http://repo.or.cz/w/tinycc.git for details, and do join the mailing list to get involved.
I'll consolidate my comments now.
There seem to be several issues.
There has been a change in the naming scheme for the x86 register access as of Mac OS 10.5. See Access EIP and EBP via ucontext on OS X. This will require hacking the source until the maintainer can be convinced to support Mac OS X.
The executable formats supported by tcc do not overlap with those that Mac OS X will run natively. However, XBinary may address this. (I didn't find either a fink package or a MacPorts package, however and don't have it installed yet. Not sure that I will--this is deep magic, and could in theory do very bad things indeed.) Ah... this was already on SO too: Possibility of loading/executing ELF files on OSX.
The errors can be fixed by edit configure script of TCC package (ver 0.9.25).
In the configure script, line 36 says
cpu=uname -m
If you run uname -m in the console of Mac OS X, it prints "i386" even if it is a 64-bit system.
A solution is to comment off this line, and replace it with cpu=x86_64,
Then some compiling errors will show up because of the register naming conventions in Mac OS X, as mentioned by dmckee in this thread.
My fix is to add a few lines to libtcc.c around line 1512.
Finally it will look like
#ifdef __DARWIN_UNIX03
*paddr = uc->uc_mcontext->__ss.__rip;
#else
*paddr = uc->uc_mcontext.gregs[REG_RIP];
#endif
return 0;
} else {
#ifdef __DARWIN_UNIX03
fp = uc->uc_mcontext->__ss.__rbp;
#else
fp = uc->uc_mcontext.gregs[REG_RBP];
#endif
It compiles then.
I am using gcc/g++ to compile c/c++ applications - living on OpenSuSe btw.
Is there any way (some option i guess) so that g++ will produce an executable suitable for windows ?
You can search for a mingw32 package in OpenSuSE (I know there is one for Debian) or install it manually. Then if you have a configure script the command line would be something like this in order to have make use the MinGW cross-compilation toolchain:
./configure --prefix=/usr/local --target=i386-mingw32
mingw.org also has a tutorial on building a cross compiler, don't know if that works.
(As an aside: Some websites point to mirzam.it.vu.nl/mingw containing MinGW RPM packages but it seems like that site is down.)
You'll have to be running g++ on Windows to get a Windows executable out of the other end.
Check out mingw or cygwin.
Check out MinGW Cross and related links:
http://www.nongnu.org/mingw-cross-env/#see-also
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package