For some reason I can't make valgrind work with my Cocoa apllication on OS X 10.6, compiled with Apple GCC 4.2.1... After googling this error I found out that valgrind doesn't work with 64-bit executables, however my application and all the frameworks it uses is being compiled with the -m32 flag and file commmand says ./MyAppName: Mach-O executable i386, Kernel is also i386.
Can somebody please tell me why won't valgrind work then?
By the way, I got valgrind from MacPorts...
Just a note that I had the same problem, but reinstalling with the +universal port option, as in
sudo port install valgrind +universal
made the MacPorts version work for me.
I am using the Homebrew build of valgrind and it works for me. After downloading valgrind it applies some patches, afaik the one discussed here. Additionally, it uses the flags --enable-only64bit --build=amd64-darwin when compiling on 64-bit darwin.
For me also neither the macports build worked, nor did the build that i created my self from the vanilla tar.gz file from the valgrind page. It seems that the provided autoconf script does not support newer macs running in 64-bit mode.
I downloaded latest valgrind v3.6.1 from valgrind.org and compiled it under OS X and it works without any issue.
Related
I am new to x64_86, but forced to use it because RedHat dropped its 32-bit OS support in RHEL 7.x. I have to complile a lot of code, and am not ready to jump to x64 yet (because I do not need 64-bit addresses and do not want to face all related porting issues). So I have considered using -m32 and -mx32, and decided that -mx32 is the best route for me. However, while -m32 works fine on my build machine, when I use -mx32, I get this error:
In file included from /usr/include/features.h:399:0,
from /usr/include/string.h:25,
from zz.cpp:1:
/usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such file or directory
# include <gnu/stubs-x32.h>
^
compilation terminated.
I searched the web for solutions and some links indicate that I have to install some mysterious "multilib" rpms for g++ and gcc, however, I cannot find these anywhere. Others suggest that I have to install Linux in the x32 mode and build libgcc for x32, which sound extreme. Any ideas or leads? Did someone actually try g++ -mx32? Maybe it is not even supported on the RH platform... Thanks!
P.S. In order to get the "-m32" option to work I had to install:
yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686 ncurses-devel.i686
This one fails (yum cannot find these RPMs) - allegedly these are required for -mx32 to work:
yum install gcc-multilib g++-multilib
:(
Multilib is indeed your answer, but do not know why your repo does not support it. I installed mine via apt-get:
sudo apt-get install gcc-multilib
Although it uses 64-bit instructions, it uses the 32-bit ABI so annoyingly will not run under WSL (Windows Linux subsystem), which only supports the 64-bit one.
I am trying to compile a 32-bit version (MinGW) of a program I wrote using zlib. Until now, I've never has to compile for 32-bit so the version of zlib I compiled from source (libz.a) is 64-bit. I tried to rerun the makefile in the zlib-1.2.5 directory but it only compiles a 64bit version of libz.a.
I can't seem to find an option to build 32-bit.
Does anyone know how to do this?
Thanks!
Jeffrey Kevin Pry
Checking the configure file, you can see some env.
On 64bit debian, following command line will build the 32bit version of libz
CFLAGS=-m32 ./configure
It turns out I had to get the 32bit version of MinGW and compile it with that. I was using MinGW64.
Using CFLAGS=-32 won't do it for me, configure script still shouts out telling me to use win32/Makefile.gcc instead all the time.
The recent version of zlib is 1.2.11, so it should be minimal gap of difference up until today. Without any context on system, the following might be useful for other users facing this similar problem these days.
I cross compile on Linux (Ubuntu 18.04), and target 32-bit version of zlib to be produced. What I did is as follows.
./configure (this is just to let us have required file to building process, we will be using different Makefile though)
Modify win32/Makefile.gcc for its PREFIX=i686-w64-mingw32- (for 64-bit you change it to PREFIX=x86_64-w64-mingw32-.
make -fwin32/Makefile.gcc
Install to your desire location via make install -fwin32/Makefile.gcc SHARED_MODE=1 INCLUDE_PATH=/tmp/zlib-win32/include LIBRARY_PATH=/tmp/zlib-win32/lib BINARY_PATH=/tmp/zlib-win32/bin. Notice that you need to specify INCLUDE_PATH, LIBRARY_PATH, and BINARY_PATH. BINARY_PATH will contains result .dll file.
I want to compile C++ code on MacOS X, using the g++ compiler. How do I install it?
That's the compiler that comes with Apple's XCode tools package. They've hacked on it a little, but basically it's just g++.
You can download XCode for free (well, mostly, you do have to sign up to become an ADC member, but that's free too) here: http://developer.apple.com/technology/xcode.html
Edit 2013-01-25: This answer was correct in 2010. It needs an update.
While XCode tools still has a command-line C++ compiler, In recent versions of OS X (I think 10.7 and later) have switched to clang/llvm (mostly because Apple wants all the benefits of Open Source without having to contribute back and clang is BSD licensed). Secondly, I think all you have to do to install XCode is to download it from the App store. I'm pretty sure it's free there.
So, in order to get g++ you'll have to use something like homebrew (seemingly the current way to install Open Source software on the Mac (though homebrew has a lot of caveats surrounding installing gcc using it)), fink (basically Debian's apt system for OS X/Darwin), or MacPorts (Basically, OpenBSDs ports system for OS X/Darwin) to get it.
Fink definitely has the right packages. On 2016-12-26, it had gcc 5 and gcc 6 packages.
I'm less familiar with how MacPorts works, though some initial cursory investigation indicates they have the relevant packages as well.
Installing XCode requires:
Enrolling on the Apple website (not fun)
Downloading a 4.7G installer
To install g++ *WITHOUT* having to download the MASSIVE 4.7G xCode install, try this package:
https://github.com/kennethreitz/osx-gcc-installer
The DMG files linked on that page are ~270M and much quicker to install. This was perfect for me, getting homebrew up and running with a minimum of hassle.
The github project itself is basically a script that repackages just the critical chunks of xCode for distribution. In order to run that script and build the DMG files, you'd need to already have an XCode install, which would kind of defeat the point, so the pre-built DMG files are hosted on the project page.
Type g++(or make) on terminal.
This will prompt for you to install the developer tools, if they are missing.
Also the size will be very less when compared to xcode
Download Xcode, which is free with an ADC online membership (also free):
http://developer.apple.com/technology/xcode.html
xcode is now available for free from the app store. Just "buy it" (for free) and it will download. To get the command line tools go into preferences/downloads and "install command line compiler tools".
Instead of gcc you are using clang, but it works the same.
Here is how to do it on the newer mac chips and how to switch from clang(default) to g++
Install g++ through home-brew.
Check out the version you just installed, probably 12th or higher
You can make a symbolic link from g++-12 to g++
In order to do it, just type in your terminal:
sudo ln -s $(which g++-12) /usr/local/bin/g++.
Now open a new terminal and check your version again and you should see g++ instead of clang
g++ --version
Has anyone found a fix for this?
I read that it has something to do with new dylib format in Snow Leopard...
(This is the lib I get back from MacPorts.)
Thanks,
rui
What are you trying to use that library with? Chances are you have an old version of some build tool or app. Have you updated all of your MacPorts installation?
sudo port selfupdate
sudo port -u upgrade outdated
EDIT: Based on your additional information, more questions:
You have -I /sw/include and -L /sw/lib which are standard locations for Fink, not MacPorts (/opt/local/{include,lib}). In general, it's not a good idea to mix packages from Fink and MacPorts. Are you actually pulling in anything from Fink? If so, are all the Fink packages up-to-date?
If that doesn't resolve the issue, are you building on 10.5 and, if so, which 10.5? Or are you building on 10.6 an app targeted for 10.5 and 10.6? Make sure you have the latest Xcode in either case.
EDIT: It is very difficult to diagnose problems like this based on sketchy information. You say Leopard in your latest comment but then you say you are using the 10.6 SDK. At this point, all I can suggest is that you make sure you have the latest Xcode updates installed and, if you want more help, update the question with a more complete description of what you are trying to do and exactly how and where you are trying to do it, including versions of tools like gcc, et al. Good luck!
We have this same problem whenever we try to run an executable compiled and linked on Snow Leopard without -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 and then try to run it on Leopard. Note the -isysroot setting is different than in your comment above.
The application was incorrectly built on OS X 10.6 machine for a 10.5 machine. The developer can fix this by considering three things:
Using the correct compiler parameters:
gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk ...
Using the correct linker settings (setting environment variable before link command). This is required, so that the OS X 10.6 linker will not use the loader command 'LC_DYLD_INFO_ONLY' (=0x80000022), because OS X 10.5 does not understand this command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
After this is fixed, one can check if the application was correctly built for OS X 10.5 by running 'otool':
otool -l binary
The correct binary should not contain any 'LC_DYLD_INFO_ONLY' load commands (only 'LC_DYLD_INFO' commands).
(also see my blog article http://grauonline.de/wordpress/?p=71 )
I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.