I am trying to compile yap on my PC since it seems YAP default installers don't come with the Depth limit flag enabled. I need this to work on an ILP project on Aleph.
The thing is, that I am forced to use a PC with windows 8 without enough memory for a Linux Virtual machine.
I got cygwin to attempt to install it, but once I get to the 'make' stage of the installation ( http://www.dcc.fc.up.pt/~vsc/Yap/Yap4.3/yap.html#SEC2 ) I get this following error
$ make
Makefile:714: warning: overriding recipe for target 'yap.dll'
Makefile:545: warning: ignoring old recipe for target 'yap.dll'
gcc -mno-cygwin -c -O3 -fomit-frame-pointer -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -DCUT_C=1 -DCOROUTINING=1 -DRATIONAL_TREES=1 -DDEPTH_LIMIT=1 -DHAVE_CONFIG_H -D_YAP_NOT_INSTALLED_=1 -I. -I../H -I../OPTYap -I../BEAM -I../MYDDAS ../C/agc.c -o agc.o
gcc: error: unrecognized command line option ‘-mno-cygwin’
Makefile:488: recipe for target 'agc.o' failed
make: *** [agc.o] Error 1
I assume it's due to the latest YAP being outdated right now, does anyone know what to do to work around this?
It seems long time has passed since the question is asked. But I would like to answer since the problem is still relevant (I had this problem lately).
Asking at YAP-users mailing list, I was able to solve this problem. You can check the details here.
In short, using MSYS2 or MinGW-w64 (with toolchain installed) and making few changes in the source code makes it possible.
Changes are:
Adding #include <stdio.h> in blob.c file.
Refactoring H with HEAD (or some other name) in whole project. Which was defined in Regs.h, line 590.
Related
I'm trying to build this: https://github.com/hselasky/hpsat_generate
this is their makefile:
PROG_CXX=hpsat_generate
PREFIX?=/usr/local
MAN=
SRCS= hpsat_generate.cpp
BINDIR?=${PREFIX}/bin
.if defined(HAVE_DEBUG)
CFLAGS+= -g -O0
.endif
CFLAGS+= -I${PREFIX}/include
LDFLAGS+= -L${PREFIX}/lib -lgmp -lgmpxx
.include <bsd.prog.mk>
using just make . results in
Makefile:7: *** missing separator. Stop.
so after some searching I found that I need to use FreeBSD make, so I tried:
bmake . hpsat_generate
which complains that mergesort is not declared, which is a FreeBSD function so I can only assume it doesn't really includes it.
I tried finding a way to make it run but I'm out of ideas..
The Makefile requires some changes for Linux (and NetBSD). The bsd.prog.mk implementation that comes with bmake on Linux is slightly off, and requires a workaround to link the program correctly, also, on Linux you need libbsd:
These issues are fixed by PR #1.
Instead of running the makefile just execute this:
g++ -o sat sat.cpp -lgmp -lgmpxx -l:libbsd.a
you may need to install the gmp and libbsd libraries
I want to install xgboost using anaconda python. In this process, I am trying to install xgboost. While trying to "make" the xgboost i am getting the below error:
C:\GitRepository\xgboost>
g++ -m64 -c -Wall -O3 -msse2 -Wno-unknown-pragmas -funroll-loops -fopenmp -fPIC
-o updater.o src/tree/updater.cpp
src/tree/updater.cpp:1:0: warning: -fPIC ignored for target (all code is positio
n independent)
// Copyright 2014 by Contributors
^
src/tree/updater.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
make: *** [updater.o] Error 1
I understood from the other Stack overflow posts that 32 bit gcc cannot go with the 64bit anaconda that i am using. However when i installed mingw-w64 i could see that it has g++ only for mingw32 and not for mingw-w64. Under the mingw-w64 package, g++ and other applications+folders are present only for mingw32 and not for 64. For mingw-64 only a batch file and a internet short cut is present.
Could you please guide me what is going wrong or guide me to an appropriate place from where i can download for mingw-64.
Thanks in advance.
If you are really using MSYS2, then you should not be downloading separate compilers. You should install 64-bit g++ using MSYS2's package manager, by running pacman -S mingw-w64-x86_64-toolchain. Then make sure that you start the MSYS2 shell using the shortcut that is named something like "MSYS2 Win64 Shell" in your start menu. Type which g++ in Bash and make sure it outputs /mingw64/bin/g++. Then you should be able to compile code for 64-bit Windows.
I'm not sure that this answer is complete. If you need more help with MSYS2, it would be good to post the exact commands you are running to download/extract the source code and build so that others can reproduce the error.
I'm trying to compile the crypto++ library to run for the armhf architecture. I'm following the method provided in this answer. I tweaked the setenv-embed.sh to match my system's configuration. The output of running . ./setenv-embed.sh is
CPP: /usr/bin/arm-linux-gnueabihf-cpp
CXX: /usr/bin/arm-linux-gnueabihf-g++
AR: /usr/bin/arm-linux-gnueabihf-ar
LD: /usr/bin/arm-linux-gnueabihf-ld
RANLIB: /usr/bin/arm-linux-gnueabihf-gcc-ranlib-4.8
ARM_EMBEDDED_TOOLCHAIN: /usr/bin
ARM_EMBEDDED_CXX_HEADERS: /usr/arm-linux-gnueabihf/include/c++/4.8.2
ARM_EMBEDDED_FLAGS: -march=armv7-a mfloat-abi=hard -mfpu=neon -I/usr/arm-linux-gnueabihf/include/c++/4.8.2 -I/usr/arm-linux-gnueabihf/include/c++/4.8.2/arm-linux-gnueabihf
ARM_EMBEDDED_SYSROOT: /usr/arm-linux-gnueabihf
which indicates that the correct compilers have been found. However, when I build the library using make I run into the following error
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/arm-linux-gnueabihf/lib/libc.so.6 inside /usr/arm-linux-gnueabihf
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/arm-linux-gnueabihf/lib/libc_nonshared.a inside /usr/arm-linux-gnueabihf
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 inside /usr/arm-linux-gnueabihf
But when I open the location /usr/arm-linux-gnueabihf/lib I can find all the three error files mentioned above ie libc.so.6, libc_nonshared.a and ld-linux-armhf.so.3
I'm trying to compile the library for Beaglebone, if that helps.
Update 1:
The results of running make -f GNUmakefile-cross system after doing a fresh git pull
hassan#hassan-Inspiron-7537:~/cryptopp-armhf$ make -f GNUmakefile-cross system
CXX: /usr/bin/arm-linux-gnueabihf-g++
CXXFLAGS: -DNDEBUG -g2 -Os -Wall -Wextra -DCRYPTOPP_DISABLE_ASM -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb -I/usr/arm-linux-gnueabihf/include/c++/4.8.2 -I/usr/arm-linux-gnueabihf/include/c++/4.8.2/arm-linux-gnueabihf --sysroot=/usr/arm-linux-gnueabihf -Wno-type-limits -Wno-unknown-pragmas
LDLIBS:
GCC_COMPILER: 1
CLANG_COMPILER: 0
INTEL_COMPILER: 0
UNALIGNED_ACCESS:
UNAME: Linux hassan-Inspiron-7537 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
MACHINE:
SYSTEM:
RELEASE:
make: Nothing to be done for `system'.
The problem is simple. It is in the --sysroot option. The value of this option is /usr/arm-linux-gnueabihf/ and it is used by the linker and the resulting library folder becomes
/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf/lib/
I removed the --sysroot option from line 68 in the file GNUmakefile-cross and everything compiled and linked OK.
However, I couldn't run the example on my BeagleBone Black because of mismatch of some shared libraries versions. But this wasn't a real problem for me, because in my application I link crypto++ statically, not dynamically.
Based on Crosswalking's research I think I can explain what is going on. I don't think I agree with the assessment "The problem is simple. It is in the --sysroot option" since the Crypto++ environment script and makefile are doing things as expected.
I think Crosswalking's answer could be how to work around it; but see open questions below. The following is from Crypto++ Issue 134: setenv-embedded.sh and GNUmakefile-cross:
I think this another distro problem, similar to g++-arm-linux-gnueabi
cannot compile a C++ program with
--sysroot.
It might be a Ubuntu problem or a Debian problem if it is coming from
upstream.
When cross-compiling, we expect the following (using ARMHF):
SYSROOT is /usr/arm-linux-gnueabihf
INCLUDEDIR is /usr/arm-linux-gnueabihf/include
LIBDIR is /usr/arm-linux-gnueabihf/lib
BINDIR is /usr/arm-linux-gnueabihf/bin
How LIBDIR morphed into into
/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf/lib/ (i.e.,
$SYSROOT/$SYSROOT/lib) is a mystery. But in all fairness, building
GCC is not a trivial task.
You should probably file a bug report with Debian or Ubuntu (or
whomever provides the toolchain).
The open question for me is, since $SYSROOT/lib is messed up, then is $SYSROOT/include messed up, too?
If the include directory is also messed up, then the cross compile is using the host's include files, and not the target include files. That will create hard to diagnose problems later.
If both $SYSROOT/include and $SYSROOT/lib are messed up, then its not enough to simply remove --sysroot. Effectively, this is what has to be done:
# Exported by setenv-embedded
export=ARM_EMBEDDED_SYSROOT=/usr/arm-linux-gnueabihf
# Used by the makefile
-I $ARM_EMBEDDED_SYSROOT/$ARM_EMBEDDED_SYSROOT/include
-L $ARM_EMBEDDED_SYSROOT/$ARM_EMBEDDED_SYSROOT/lib
Which means we should be able to do the following:
# Exported by setenv-embedded
export=ARM_EMBEDDED_SYSROOT=/usr/arm-linux-gnueabihf/usr/arm-linux-gnueabihf
# Used by the makefile
--sysroot="$ARM_EMBEDDED_SYSROOT"
Finally, this looks a lot like Ubuntu's Bug 1375071: g++-arm-linux-gnueabi cannot compile a C++ program with --sysroot. The bug report specifically calls out ... the built-in paths use an extra "/usr/arm-linux-gnueabi".
We need the paths:
A) /usr/arm-linux-gnueabi/include/c++/4.7.3 B)
/usr/arm-linux-gnueabi/include/c++/4.7.3/arm-linux-gnueabi
But the built-in paths tries to use:
C) /usr/arm-linux-gnueabi/usr/arm-linux-gnueabi/include/c++/4.7.3
D)
/usr/arm-linux-gnueabi/usr/arm-linux-gnueabi/include/c++/4.7.3/arm-linux-gnueabi/sf
E)
/usr/arm-linux-gnueabi/usr/arm-linux-gnueabi/include/c++/4.7.3/backward
Notice the built-in paths use an extra "/usr/arm-linux-gnueabi"
I am trying to run Eclipse with the Clang compiler without success. First I went here http://clang.llvm.org/get_started.html and followed the instructions 1 through 8 successfully. I also installed the llvm toolchain via Eclipse marketplace.
What do I do next to successfully compile with Clang? From the installation I have two folders, llvm and build, where do I put them? How do I connect this to Eclipse?
I also downloaded lld in case I needed it since the llvm-ld doesn't work anymore. Below is my error message. I'll be so grateful if someone can help me figure this out! I've wasted a lot of hours on this.
20:09:47 **** Incremental Build of configuration Debug for project recursion ****
Info: Internal Builder is used for build
clang -O0 -emit-llvm -g3 -Wall -c -fmessage-length=0 -o recursiveprint.bc ../recursiveprint.c
lld -v -native -o recursion recursiveprint.bc
Cannot run program "lld": Unknown reason
Error: Program "lld" not found in PATH
PATH=[/usr/bin:/bin:/usr/sbin:/sbin]
20:09:47 Build Finished (took 74ms)
Today i got the most generic compile error for Dev-C++ ever
Compiler: Default compiler
Building Makefile: "C:\projects\Makefile.win"
Executing make...
make.exe -f "C:\projects\Makefile.win" all
g++.exe -c test.cpp -o test.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -I"C:/SDL-1.2.15/include"
make.exe: *** [test.o] Error 255
Execution terminated
and that's it. I googled around online but usually you can see some other type of errors follow it within the compile log but no in my case. Anyone help. I am running this on window 8
Please update your IDE to the following version, which fixes an immense list of bugs, ships with GCC 4.6.1 or 4.7.0, and is fully portable: http://sourceforge.net/projects/orwelldevcpp/
That would be the number one fix to try and fix this problem regarding the automatically generated makefile. Chances are the updated version will fix your makefile problems.
You could also open up the auto generated makefile yourself and:
Go to Project >> Project Options >> Makefile and tick "use custom makefile".
Try to fix the makefile manually.
???
Rebuild.
Profit.
If this option was previously left unticked, you are sure either the old Dev-C++ made an error creating the makefile or the bundled compiler got broken for some reason.