I had no luck finding precompiled packages of glibc for apple darwin. I could not compile gcc from source, and I'm assuming that compiling glibc will also be very difficult. What I want:
Configuring the darwin system so that it only uses the GNU C runtime libraries, along with gcc.
I can specify more if needed.
I still haven't found a solution to this problem, but that is irrelevant now. The segmentation fault can only be reproduced in the 64 bit darwin libc. Furthermore, running the program with valgrind on the darwin suppresses the fault.
This led me to the conclusion that the problem is in the code, rather than the libraries. The code was not mine at the beginning, hence it's not my problem anymore. The program in some stage tries to access unallocated memory and my guess is that using glibc somehow compensates this error.
Related
I'm running MacOS Big Sur and trying to install valgrind for an assignment.
brew install valgrind doesn't currently work and installing from the tar.bz2 distribution doesn't either.
Running ./configure (according to the readme instructions) returns this at the end:
checking for a supported OS... ok (darwin20.1.0)
checking for the kernel version... unsupported (20.1.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x, 13.x, 14.x, 15.x, 16.x and 17.x (Mac OS X 10.6/7/8/9/10/11 and macOS 10.12/13)
Judging from that, looks like valgrind hasn't worked for the last couple of MacOS releases.
Is there an alternative for current MacOS releases or is this a good time for me to make a partition on my hard drive for Linux? Or am I missing something with installation?
As mentioned in the comments, Louis Brunner's github repo is your best bet at the moment. This should give you at least a minimally functional build.
Other than the usual version number changes, one of the big, breaking, changes in Big Sur is the fact that the system libraries are cached (and hidden) by dyld. So right now Valgrind is not able to read libsystem_malloc.dylib in order to determine the address of functions like malloc so that they can be redirected.
If anyone wants to take a stab at it, then my guess is that you will need to follow these instructions, and change initimg-darwin.c so that dyld_cache_value is "avoid".
For anyone else looking for an answer, you could use valgrind-macos, a fork of Valgrind on macOS, as recommended by PhillipMills. XCode also provides tools for leak checking.
However, if you don’t use XCode and don’t like the first option, you could try Address/Leak Sanitizer. The difference is that you’ll have to compile and link with one of the sanitizers, but that only requires an extra flag, i.e., -fsanitize=address. Note that Apple Clang doesn’t support leak checking, so you’ll have to grab llvm off Brew. Also, you need to prepend ASAN_OPTIONS=detect_leaks=1 before your executable.
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
As mentioned over here and here
So if your program is using math functions and including math.h, then
you need to explicitly link the math library by passing the ‘-lm’ flag
But I just manage to get the linking without using -lm flag with gcc on my benign C code.
and It work perfectly well.
Any clue.
gcc -version
gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
On many systems some parts of what's traditionally in libm are included in the standard C library for various reasons. Other parts may be implemented directly in the math.h header, yet others might be just implemented inline by the compiler.
Whatever code you had, you got away with not linking with libm. You'll often end up in situations where you get away with doing something despite it not being perfectly correct. A good habit is to ignore that luck and still do what the standards/documentation says because it reduces the number of problems in the future.
helloworld.c:
int main(){}
[1] 9845 illegal hardware instruction (core dumped) LD_PRELOAD=./libc.so.6 ./helloworld
This preload libc is an old version of glibc
Can I debug helloworld linking it on my system?
Or is there a fast way to deploy a virtual machine with the specific version of shared libraries?
Can I debug helloworld linking it on my system?
Yes, but you need to do it correctly. This answer provides details, and an explanation for why your LD_PRELOAD didn't work.
From your post I could see POC dumping core. So, better use gdb to analyze the coredump and see the crashing callstack. Make sure you load the right libc in gdb while analyzing coredump.
Else use LD_DEBUG=all before invoking POC and see if any pointers to crash by seeing the details during runtime.
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.