I am following
http://www.mingw.org/wiki/hostedcrosscompilerhowto
and issuing
make all-gcc | tee make-c-only.log 2>&1
yields
gcc -c -O2 -pipe -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-p rototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -I . -I. -I../../../../gcc-core-3.4.2-20040916-1-src/gcc-3.4.2-20040916-1/gcc -I../ ../../../gcc-core-3.4.2-20040916-1-src/gcc-3.4.2-20040916-1/gcc/.
-I../../../../ gcc-core-3.4.2-20040916-1-src/gcc-3.4.2-20040916-1/gcc/../include
insn-modes.c
-o insn-modes.o
**cc1.exe: out of memory allocating 2278450599 bytes** make[1]: ***
[insn-modes.o] Error 1 make[1]: Leaving directory
`/e/Lorin/gcc/aufWindows7MingwOrgHowto/build/arm-elf/ gcc/gcc' make:
*** [all-gcc] Error 2
I do have 2GB of free memory.
EDIT: Will try to use 64bit mingw-w64 5.2.0 with the last MSYS-20111123.zip.
As I was using a 32bit distribution of mingw the compiler cannot allocate beyond 2GB of RAM for itsself, regardless of whether this was a bug or not.
A solution to this error was to use a newer version of gcc for windows ie. the one from the "mingw-w64" project.
Note: Don't get yourself confused, the mingw-w64 project also has a 32bit version available even though the project is called mingw-w64
Related
I have inherited a powerpc project that built fine under a SUSE linux environment back around 2008. My goal is to build the same thing in Linux Mint (v 17). The target processor is a powerpc, which is set in the environment variables, I believe. During the build on Mint linux, it produces the following error:
developer#Will-test-Mint-VM ~/temp/linux.apps $ make -f Makefile.runme
make DESTDIR=`pwd`/tmp install
make[1]: Entering directory `/home/developer/temp/linux.apps'
Making install in libStreamerControl
make[2]: Entering directory `/home/developer/temp/linux.apps/libStreamerControl'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c -o streamerControl.lo streamerControl.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -ffixed-r14 -meabi -fno-builtin -std=gnu99 -Wall -g -O2 -MT streamerControl.lo -MD -MP -MF .deps/streamerControl.Tpo -c streamerControl.c -o streamerControl.o
gcc: error: unrecognized command line option '-meabi'
make[2]: *** [streamerControl.lo] Error 1
...
It is complaining about the -meabi option. I have installed/updated some packages that may be relevant (updated versions of eldk-5.6, automake, libtool, and powerpc-linux-gnu-gcc 4.8.2).
Specifically, I would like to know about the -meabi option. I didn't find a lot about it. What could be causing the compiler to not know what it is? I saw the output build from the SUSE setup, and it handled the -meabi option fine. Any suggestions?
Thanks,
Will
From your comment, it sounds like you're cross compiling here (ie., your build architecture is not the same as your host architecture). In this case, your (build) gcc won't recognise -meabi, as it's only valid for the host gcc.
So, you'll need to get your project building with the correct compiler for this to work. The method to do this will depend on the makefiles in your project. You've mentioned ARCH and CROSS_COMPILE, but these variables are specific to the Linux kernel's build system.
At a guess, your makefiles probably use some fairly standard variables to control the choice of compiler & toolchain, like CC, LD, etc. Try something like:
make -f Makefile.runme CC=powerpc-linux-gnu-gcc LD=powerpc-linux-gnu-ld
If your compile still fails, you may need to provide sources (or links to) your Makefiles.
I'm trying to install openssl in cygwin by following these instructions:
I dowloaded the latest tarball from this site http://www.openssl.org/source/, and put it in C:\cygwin64\home, then I run these commands from cygwin
tar zxvf openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config
make
make test
make install
(Instructions from here :http://www.slideshare.net/ganaaturuu/cygwinandopen-sslinstallguide)
Up to the 3rd step ./config it works fine I believe, at least there are no errors reported, and it gives the message "Configured for Cygwin." in the end. When I run make though it gives me this output:
making all in crypto...
make[1]: Entering directory '/home/openssl-1.0.1e/crypto'
( echo "#ifndef MK1MF_BUILD"; \
echo ' /* auto-generated by crypto/Makefile for crypto/cversion.c */'; \
echo ' #define CFLAGS "gcc -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERM IOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_ WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLP OOL_ASM -DGHASH_ASM"'; \
echo ' #define PLATFORM "Cygwin"'; \
echo " #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \
echo '#endif' ) >buildinf.h
gcc -I. -I.. -I../include -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMI OS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_W ORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPO OL_ASM -DGHASH_ASM -c -o cryptlib.o cryptlib.c
cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set
/* crypto/cryptlib.c */
^
cryptlib.c:1:0: error: CPU you selected does not support x86-64 instruction set
<builtin>: recipe for target 'cryptlib.o' failed
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory '/home/openssl-1.0.1e/crypto'
Makefile:278: recipe for target 'build_crypto' failed
make: *** [build_crypto] Error 1
I searched about the "CPU you selected does not support x86-64 instruction set" and I think it has to do with CFLAGS and -march=i486 option, but I'm not at all sure as into what it should be changed.
In this How to compile a C++ program as 64-bit on 64-bit machine? question there are some solutions suggested, but in my case there are nowhere in the makefile options like -m32 and -march=i686 to remove.
If you could please show me the right direction to search this, if not the solution, I would be grateful.
I'm working on Windows 7 64-bit, with cygwin and gcc version 4.8.2.
Here's a "mee too" answer because things have changed a bit. Cygwin-x64 support was cut-in in May 2015 under Issue 3110: Adding support for x86_64 Cygwin.
However, config still selects the i686 version of the library to build. Also see Issue #4326: Failed to configure for Cygwin-x64 in the OpenSSL bug tracker.
To build OpenSSL 1.0.2 on Cygwin-x64, you have to use Configure and select the triplet. Below is the soup-to-nuts recipe.
$ curl https://www.openssl.org/source/openssl-1.0.2f.tar.gz -o openssl-1.0.2f.tar.gz
...
$ tar -xzf openssl-1.0.2f.tar.gz
...
$ cd openssl-1.0.2f
Then:
$ ./Configure Cygwin-x86_64 shared no-ssl2 no-ssl3 --openssldir="$HOME/ssl"
...
$ make depend
...
$ make
...
$ make install_sw
install_sw installs the headers in $OPENSSLDIR/include, and the libraries in $OPENSSLDIR/lib. It does not install the man pages.
You then compile and link with:
$ gcc -I "$HOME/ssl/include" test.c -o test.exe "$HOME/ssl/lib/libcrypto.a" "$HOME/ssl/lib/libssl.a"
Linking against libcrypto.a and libssl.a means you avoid library path problems. Things will "just work" for you.
Also, if you need this for OpenSSL 1.0.1, then you can copy/paste the triplet's settings from 1.0.2's Configure (from line 613):
$ grep "Cygwin-x86_64" Configure
"Cygwin-x86_64", "gcc:-DTERMIOS -DL_ENDIAN -O3 -Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a",
If you want config to "just work" for 1.0.1, then add the following. Be sure the line for Cygwin-x86_64 was added to Configure.
x86_64-*-cygwin) OUT="Cygwin-x86_64" ;; <== Add this in front of the ones below
*-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;;
*-*-cygwin) OUT="Cygwin" ;;
It would seem that 1.0.1 does not have support for Cygwin/x64.
This thread indicates that the necessary patches have been pulled into the 1.0.2 branch.
here is one post you can refer to. the basic idea is that specifying -march=x86-64 and avoid using assembly language. assembly language is not as portable as c language.
I'm trying to install cloog-ppl 0.15-11 in my 64 bit ubuntu 10.10. I get the following error during make. I guess it is wrt linking.
gcc -DHAVE_CONFIG_H -I. -I./include/cloog -I./include -I./include -Wall -fomit-frame-pointer -g -O2 -MT cloog.o -MD -MP -MF .deps/cloog.Tpo -c -o cloog.o `test -f 'source/cloog.c' || echo './'`source/cloog.c
mv -f .deps/cloog.Tpo .deps/cloog.Po
/bin/bash ./libtool --tag=CC --mode=link gcc -Wall -fomit-frame-pointer -g -O2 -o cloog cloog.o libcloog.la -lgmp -lppl_c -lppl -lgmpxx
libtool: link: gcc -Wall -fomit-frame-pointer -g -O2 -o .libs/cloog cloog.o ./.libs/libcloog.so /usr/lib/libgmp.so -lppl_c -lppl /usr/lib/libgmpxx.so
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_unhook()#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::swap(std::__detail::_List_node_base&, std::__detail::_List_node_base&)#GLIBCXX_3.4.15'
//usr/local/lib/libppl_c.so: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
collect2: ld returned 1 exit status
make[1]: *** [cloog] Error 1
make[1]: Leaving directory `/home/praveen/cloog-ppl-0.15.11'
make: *** [all-recursive] Error 1
Can some one help me out on this ?
I have the same problem that I worked for a whole day!! I have a hit, as least this bug disappeared.
When it refers to GLIBCXX_3.4.15 it means that you are using a g++ or gcc with the library not providing the functions or classes you need, very likely 4.4 or 4.5. I changed my g++ and gcc to 4.6 and the problem was solved. For some references, you can check out the following:
How standard lib linked by libstdc++.so.6
Notice: I only get libstdc++.so.5 in /usr/lib when I have g++-4.5 installed. I think libstdc++ is the library that g++ and gcc used.
for changing the compiler version in Linux, see the following link:
Upgrade your compiler
Hope it helps!
I just got my GPU-enabled video card and started playing with CUDA. Just to get my head straight with blocks and threads I wrote a simple kernel that just stores its identifiers to the shared memory that I later copy back to host and print. But then I though, why not simply use printf inside the kernel function? I have tried that even though I believed that it was impossible. Here is what my attempt looked like:
__global__ void
printThreadXInfo (int *data)
{
int i = threadIdx.x;
data[i] = i;
printf ("%d\n", i);
}
.. but all of the sudden I saw the output in console. Then I searched developer's manual and found printf mentioned in the section about device emulation. It was said that device emulation provides a benefit of running a host-specific code in the kernel, like calling printf.
I don't really need to call printf. But now I am a little bit confused. I have two assumption. First is that NVidia developers implemented some specific printf on device that somehow transparently for the developer accesses calling process and executed standard printf function, and takes care of memory copying etc. That sounds a bit crazy. Another assumption is that the code I have compiled somehow runs in emulation rather than on a real device. But that doesn't sound right either because I simply measured a performance of adding two numbers on 1 million elements array and CUDA kernel manages to do it like 200 faster than I can do on a CPU. Or maybe it runs in emulation when it detects some host-specific code? If that is true, why am I not issued a warning then?
Please help me sort it out. I am using NVidia GeForce GTX 560 Ti on Linux (Intel Xeon, 1 CPU with 4 physical cores, 8 GB of RAM, if that matters). Here is my nvcc version:
$ /usr/local/cuda/bin/nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2011 NVIDIA Corporation
Built on Thu_May_12_11:09:45_PDT_2011
Cuda compilation tools, release 4.0, V0.2.1221
And here is how I compile my code:
/usr/local/cuda/bin/nvcc -gencode=arch=compute_20,code=\"sm_21,compute_20\" -m64 --compiler-options -fno-strict-aliasing -isystem /opt/boost_1_46_1/include -isystem /usr/local/cuda/include -I../include --compiler-bindir "/usr/local/cuda/bin" -O3 -DNDEBUG -o build_linux_release/ThreadIdxTest.cu.o -c ThreadIdxTest.cu
/usr/local/cuda/bin/nvcc -gencode=arch=compute_20,code=\"sm_21,compute_20\" -m64 --compiler-options -fno-strict-aliasing -isystem /opt/boost_1_46_1/include -isystem /usr/local/cuda/include -I../include --compiler-bindir "/usr/local/cuda/bin" -O3 -DNDEBUG --generate-dependencies ThreadIdxTest.cu | sed -e "s;ThreadIdxTest.o;build_linux_release/ThreadIdxTest.cu.o;g" > build_linux_release/ThreadIdxTest.d
g++ -pipe -m64 -ftemplate-depth-1024 -fno-strict-aliasing -fPIC -pthread -DNDEBUG -fomit-frame-pointer -momit-leaf-frame-pointer -fno-tree-pre -falign-loops -Wuninitialized -Wstrict-aliasing -ftree-vectorize -ftree-loop-linear -funroll-loops -fsched-interblock -march=native -mtune=native -g0 -O3 -ffor-scope -fuse-cxa-atexit -fvisibility-inlines-hidden -Wall -Wextra -Wreorder -Wcast-align -Winit-self -Wmissing-braces -Wmissing-include-dirs -Wswitch-enum -Wunused-parameter -Wredundant-decls -Wreturn-type -isystem /opt/boost_1_46_1/include -isystem /usr/local/cuda/include -I../include -L/opt/boost_1_46_1/lib -L/usr/local/cuda/lib64 -lcudart -lgtest -lgtest_main build_linux_release/ThreadIdxTest.cu.o ../src/build_linux_release/libspartan.a -o build_linux_release/ThreadIdxTest
... and by the way, both host code and kernel code is mixed in one source file with .cu extension (maybe I am not supposed to do that, but I saw this style in SDK examples).
Your help is highly appreciated. Thank you!
As of CUDA ?3.1?, they no longer do any device emulation. Printf's are now supported in the kernel.
Today I've been working on setting up extra VPS clones and I've run into a strange and frustrating compile time error with the latest nginx development version (0.9.6).
I'm running Ubuntu 10.04.2 LTS x86_64, however, I've upgraded GCC to 4.6.1. ./configure runs without errors, but upon running make -j4 I'm presented with the following error:
gcc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Wunused-function -Wunused-variable -Wunused-value -Werror -g -I src/core -I src/event -I src/event/modules -I src/os/unix -I objs \
-o objs/src/core/ngx_open_file_cache.o \
src/core/ngx_open_file_cache.c
src/core/ngx_resolver.c: In function
'ngx_resolver_process_ptr':
src/core/ngx_resolver.c:1425:43:
error: variable 'qclass' set but not
used [-Werror=unused-but-set-variable]
src/core/ngx_resolver.c:1425:36:
error: variable 'qtype' set but not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as
errors
make[1]: *
[objs/src/core/ngx_resolver.o] Error 1
make[1]: * Waiting for unfinished
jobs.... make[1]: Leaving directory
`/root/nginx-0.9.6' make: *** [build]
Error 2
(Better seen at pastebin: http://pastebin.com/g0bNS2nY)
I've tried adding --with--cc-opt="-W" to the ./configure options but without result. Can anyone please shed some light on this show stopper?
Many, many thanks in advance!
A nicer way to do this is to pass the following to ./configure
--with-cc-opt=-Wno-error
Edit the Makefile, remove -Werror. That options means: quit the compiler immediately if something doesn't seem right. Or run the compile command that went wrong manually, again without the -Werror flag:
gcc -c -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Wunused-function \
-Wunused-variable -Wunused-value -g -Isrc/core -Isrc/event \
-Isrc/event/modules -Isrc/os/unix -Iobjs \
-o objs/src/core/ngx_open_file_cache.o src/core/ngx_open_file_cache.c