I am compiling a program through clang+llvm (version 3.1) and trying to run it on a computer which also has the same clang+llvm version. I'm compiling on Ubuntu 10, but the other computer where I'm trying to run has CentOS 5. There (in CentOS), I also encounter problems compiling through LLVM (a compiler pass is implemented in LLVM). That is why I thought about compiling on Ubuntu, take the exe from there and just run it on the CentOS machine.
However, when I try to do that, I get the following error.
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./main)
./main: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./main)
How can I solve this. Please note that I do not have root accesses on that machine.
One solution would be to copy the library from your working Ubuntu machine to your CentOS machine. Put in your Home/Workdir/whereever(TM) and set your LD_PRELOAD variable to that library. But that can be quite tedious as it is possible that this is not the only library that is missing (and maybe libraries depend on other libraries, that you also need...).
This also only works, if both machines have the same architecture (e.g. it wont work if your ubuntu machine is 32 bit and your CentOS 64).
Centos 5 uses an older version of libstdc++ than Ubuntu 11.04 or 11.10, so can't use binaries from there.
Either compile on Centos 5, or find a older compile environment that does work. If you were using gcc, you could also investigate the LSB compiler environment.
Cross compilation is always a difficult issue. In your case you have different c++ library versions on the two machines. In case you do not need to do this often, I suggest you try and solve your compilation issue on CentOS. It's probably the easier way round.
Related
I would like to experiment with intel's Cilk extension for C/C++ parallel programming but I am having a hard time figuring out how to install it on Windows. I tried consulting the official site but I couldn't find any Windows oriented guide. Switching to Linux is not convenient right now and I would prefer to leave it as a last resort.
I also tried to get a free trial version of Parallel Studio, but apparently it does not support CILK anymore.
If someone could guide me step-by-step, I would be very grateful.
I use Code Blocks, which includes the gnu gcc compiler.
(To start with, excuse me, I've never used Cilk personally).
First of all, it's deprecated:
https://en.wikipedia.org/wiki/Cilk#Obsolescence
https://software.intel.com/en-us/forums/intel-cilk-plus/topic/745556
If you want to try it with GCC, you need to get GCC (perhaps, versions from 4.9 to 8.0; support deprecated in 7.1 and removed in 8.1) compiled with Cilk support.
And then it should work in a very simple way, e.g.:
$ gcc -fcilkplus -lcilkrts <OTHER_FLAGS> mycode1.c
$ g++ -fcilkplus -lcilkrts <OTHER_FLAGS> mycode2.cpp
(I've tried to add these flags when compiling a non-Cilk C source on my Debian 9 GNU/Linux (amd64) system, and it seems to work; libcilkrts5 package seems to get installed there along with GCC 6.3.0, by default).
Here is a list of popular binary GCC builds:
https://gcc.gnu.org/install/binaries.html
Unfortunately, most GCC binaries for MS Windows I can find come without Cilk enabled;
e.g., I didn't find it in the following packages:
http://codeblocks.org/downloads/binaries
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
At least, it can be found in Cygwin (it has gcc-cilkplus & libcilkrts5 in its package list):
https://cygwin.com/packages/package_list.html
Alternatively, you can probably try Intel C++ Compiler (no experience with that, sorry).
https://en.wikipedia.org/wiki/Cilk#Intel_Cilk_Plus
https://www.cilkplus.org/build-gcc-cilkplus
Cilk is alive and kicking at MIT as OpenCilk
You can either build it or even download a binary, but only linux, Mac or source is offered
I have been using gcc version 5.3.0. It says that it comes with openmp support. But every time when I compile a program using either gcc [by terminal] or via xCode 7, I get same error, "file omp.h not found". I have searched too much on this issue and tried almost everything I found.
First I tried to locate omp.h on my mac. I found some files; then in header file, I used that specific location of omp.h but no help [it gave me linker error].
I installed gcc version 6.0 (pre-release) but no help. I tried changing C_INCLUDE_PATH [which is now, and previously set to none] but that didn't helped me as well.
I reinstalled clang-omp but no help.
I am using llvm compiler version 7.0. Although i have installed clang-omp, there is no omp.h in my /usr/include/*
I changed the compiler and now I am able to run it. [It was issue of clang, which I couldn't solve].
I am a student and Intel is giving Intel Parallel Studio 1 year licence for free to students.
So I downloaded, and installed it.
In xCode, under build settings, I set my compiler to 'Intel C/C++ compiler' and in parallalization, I turned it to 'yes'. That was it. Then it compiled successfully. But, note that you won't be using header file 'omp.h' anymore.
By the way, I am still looking for answers, just to know what I was doing wrong.
You can install 'clang-omp' or 'gcc' (corresponds to GCC 5.3 right now) packages via Homebrew, both of which support OpenMP.
The built in GCC is based upon GCC 4.2.1 abs uses LLVM back end via Dragonegg, which is why it doesn't support OpenMP.
As noted already, Intel compilers support OpenMP on Mac.
I don't use Xcode editor so I don't know how to use any of these from there, but all will work from terminal just as they do on Linux.
the compiler on the mac is clang (based on llvm 3.5) which does not support openmp.
you can try install llvm/clang/openmp from source or using prebuild binaries, but I must admit it does not work as advertised for me…
edit unless you use the -fopenmp=libomp flag.
I've this project called librsync.
Installed ubuntu package called mingw-w64. Looked at automake manpage.
What I want to do is to build executable that runs on windows or dll, whichever I could get working.
./configure --host "what do i put here?"
By looking at ubuntu packages I can't figure it out. From automake manpage - If I had mingw32 it should be i586-mingw32msvc. But how do I figure that out on my own in the first place? At least, what should I put in hosts param if I have mingw-w64?
For building something with a cross compiler, you will use configuration-gcc as the C compiler with configuration being what you would pass to --host to build a library or executable.
ls /usr/bin/*mingw*gcc should give you the C compiler to use, allowing you to know what the configuration is.
MinGW (aka mingw32): iX86-pc-mingw32 or iX86-mingw32msvc (X is a 4, 5, or 6 depending on how it was configured)
mingw-w64: ARCH-w64-mingw32 (ARCH is one of i686 or x86_64)
I've honestly not seen anything else for mingw-w64, except in its earlier days when it used ARCH-pc-mingw64, but that shouldn't be used anymore.
I am trying to compile a small utility called tcpslice. It's the typical GNU C application. When I run ./configure, here is the output:
checking build system type... Invalid configuration `x86_64-pc-linux-gnuoldld': machine `x86_64-pc' not recognized
configure: error: /bin/sh ./config.sub x86_64-pc-linux-gnuoldld failed
It appears to not support compilation as a 64-bit Linux application. So I have a few questions:
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
I noticed a 64-bit RHEL6 machine on my network has this utility installed and running with an identical version number (1.2a3). Could I somehow download the source that was used to build it? I can get access the to RHN if necessary.
Is it possible to set some flags to compile the application as 32-bit AND be able to run it on my 64-bit operating system?
Yes. -m32 is the option.
Is it possible to update the configure script to support 64-bit Linux? If so, will I be making some serious code changes in the .c files as well?
You will have to make some code changes to make a purely 32 bit application work on 64 bit. Here's a link that talks about porting code from 32 bit to 64 bit.
I am sorry, I do not know the answer for your 3rd question.
Hope the little information provided by me helps in some way.
You've misinterpreted what the configure script is telling you. The solution has nothing to do with CPU bitness.
The error comes down to a too-old version of config.guess, which the package creator generated with libtoolize. To fix it, you will need to have libtool installed, then say:
$ libtoolize --force
You'll find that configure now runs, because libtoolize overwrote the tarball version of config.guess with one appropriate to your system.
You may run into another problem, a "missing" bpf.h file. Just edit tcpslice.c and change this line:
#include <net/bpf.h>
to:
#include <pcap-bpf.h>
With those two changes, I got tcpslice to build on my 64-bit CentOS 5 box.
install following packages :
$apt-get install ia32-libs.
for rhel its different :
look at the answer to this question :
CentOS 64 bit bad ELF interpreter
I have some old hardware with an old version of say SuSE linux running on it. Now I have this fancy development machine running Ubuntu 9.10. Some of the tools I use to compile my C app (written in Python 2.6.x) are not available on the old SuSe box. So... is it possible to compile for that old machine on my dev box?
I have the following steps in mind, but would like to cross-check before venturing off into this quest:
1. Find out which static/shared libs my app needs and find/build target version of them
2. Also find the corresponding header files
3. Feed the correct flags to gcc to use the target headers and libraries
4. Feed the correct flags to gcc to use the correct architecture (i386/i686), or do I need a cross-compilation toolchain.
5. Compile, upload and enjoy ;-)
I regularly use avr-gcc and cc65, both are cross compiling. I know that you set up a coss compiler for developing something like a gumstix, so it should be possible to do the same for old/other Linux distros, not?
C
The way I would approach this is grab your oldmachine:/usr/lib and oldmachine:/usr/include so you have e.g. newmachine:/oldmachinecompiler/usr/{lib|include} then build a cross compiler setting --sysroot to newmachine:/oldmachinecompiler/
This is really the only way to ensure that any library requirements (including libc) in your program are compatible with oldmachine.