I installed valgrind on Snow Leopard using the patch at https://bugs.kde.org/show_bug.cgi?id=205241 . However, when I run it with a binary I compiled from C++ code, I'm told that valgrind "cannot execute binary file". What g++ flags should I set to make my program work with valgrind?
Be sure to use the -m32 option to generate a 32-bit executable. The compiler default is 64-bit (assuming you have a 64-bit machine), but valgrind does not yet officially support 64-bit executables on Mac OS X. The file command on your executable should report "Mach-O executable i386".
Related
I have Windows 10 with the Ubuntu userspace based on Windows Linux Subsystem, with the gcc package installed. Using gcc -static, I built a statically linked binary, hello, that the usual utilities describe as follows:
$ ldd hello
not a dynamic executable
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=xxx, not stripped
If I take this executable to a random Windows system that doesn't have the Linux-supporting subsystem installed, will it still run?
No. It requires WSL to map Linux Kernel calls to Windows. Second it needs bash to load it since it's an ELF executable not a Windows one.
I have developed some codes in Linux which use boost::serialization library. Now I want to copy my files into Cygwin and compile them to produce executable for Windows. I know that I should use Mingw-64 g++ compiler. But how about boost library? Should I download the Windows version or the Linux version of this library?
In Cygwin, you install Boost libraries as per Unix/Linux. From the documentation
Getting Started on Windows
A note to Cygwin and MinGW users
If you plan to use your tools from the Windows command prompt, you're in the right place.
If you plan to build from the Cygwin bash shell, you're actually running on a POSIX
platform and should follow the instructions for getting started on Unix variants.
Other command shells, such as MinGW's MSYS, are not supported—they may or may not work.
I am trying to make programs for an old computer running Windows 98 second edition, but they won't run.
The programs are written in c++, and they are compiled with MinGW (g++ version 4.8.1) installed on a Windows Vista computer. For testing I tried this simple Hello World program:
#include <iostream>
using namespace std;
int main(){
cout <<"hello world";
return 0;
}
For compiling I used this command:
g++ hello.cpp -o hello.exe
When trying to run this program on the Windows 98 computer I get the following message:
A required .DLL file, LIBGCC_S_DW2-1.DLL, was not found.
So to make the executable as independent of dll-files as possible, I tried compiling the program with the command:
g++ hello.cpp -static -o hello.exe
But on trying the program on the Windows 98 computer, I now get the message:
The hello.exe file is linked to missing export MSVCRT.DLL:_fstat64
To analyze the problem, I tried a few things. And I noticed that compiling the same code with the same command using g++ version 2.95.2 instead, the program was able to run on the Windows 98 machine. However, I would prefer not to use this old version of g++ as it contains a few problematic bugs.
I also noticed that a similar program made in regular c (compiled with gcc version 4.8.1) also worked fine on the old computer, but I would prefer not to use regular c as this would require rewriting a lot of c++ code.
So the question is: how can I make c++ programs compiled with g++ 4.8.1 (or later) run on a Windows 98 machine?
Late but better than never
found out later versions of MinGW doesn't run on windows 98 giving the error "A required .DLL file, LIBGCC_S_DW2-1.DLL, was not found."
the version of MinGW i tried and gave the error was this one (6.3.0-1)
(i think you are referring to the dev version there, probably the bin version you had was more modern)
oddly, i recalled that time ago i compilled a build using Code::Blocks using MinGW that ran in windows 98, so i downloaded Code::Blocks version 17.12, and compilled the very same exe using the MinGW provided there directly, and worked just fine
and noticed it was a fairly older version ((tdm-1) 5.1.0)
idk which was the latest version MinGW compilations worked on windows 98, i'll write a post about it in their forum soon
for the record, i'll show the pics of the test i did
on MinGW 6.3.0-1:
on MinGW (tdm-1) 5.1.0:
so, to answer the question; yes, you can make programs for windows 98 using MinGW's g++ greater than version 4.8.1 (up to a certain version, i'll ask in the forum for more information)
EDIT: no need to, found this:
"The default mode is C++98 for GCC versions prior to 6.1, and C++14 for GCC 6.1 and above. You can use command-line flag -std to explicitly specify the C++ standard. For example,
-std=c++98, or -std=gnu++98 (C++98 with GNU extensions)
-std=c++11, or -std=gnu++11 (C++11 with GNU extensions)
-std=c++14, or -std=gnu++14 (C++14 with GNU extensions), default mode for GCC 6.1 and above.
-std=c++17, or -std=gnu++17 (C++17 with GNU extensions), experimental.
-std=c++2a, or -std=gnu++2a (C++2a with GNU extensions), experimental."
i added the -std=c++98 -std=gnu++98 flags to the 6.3.0-1 compiler and it worked fine on Windows 98 SE
You can usually find msvcrt.dll by installing IE4
http://gnuwin32.sourceforge.net/packages/gcc.htm
Every time I try to run valgrind on my OS X 10.8 notebook, I get:
bad executable (no stack)
valgrind: ./a.out: cannot execute binary file
What is the problem? How can I fix this? Everything works fine on Linux, so it's not that I'm somehow misusing valgrind. The exact line I'm using is valgrind --tool=memcheck --leak-check=full ./a.out.
I was getting the same error, but I just upgraded valgrind to 3.8.1 (brew upgrade valgrind using HomeBrew for me), and it works, although running Valgrind prints the following warning:
WARNING: Support on MacOS 10.8 is experimental and mostly broken.
WARNING: Expect incorrect results, assertions and crashes.
WARNING: In particular, Memcheck on 32-bit programs will fail to
WARNING: detect any errors associated with heap-allocated data.
I had this problem using valgrind with macports. It turns out I needed to install with
sudo port install valgrind +universal
I was trying to valgrind a 32bit executable and I believe that without +universal, 32bit support was not being compiled in.
Anyone,
I have been unable to compile some packages, like WxWidgets, on Mac OS 10.6.4 using gcc 4.5 (compiled from source, not from MacPorts, Fink, etc. with all default languages and Obj-C++). Typically, when trying to compile against the Foundation framework, I get errors such as the following:
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:123:35:error: expected ‘;’ before ‘__attribute__’
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:138:1:error: stray ‘#’ in program
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:139:1:error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘-’ token In file included from main2.m:2:0:
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:139:63:error: expected ‘;’ before ‘__attribute__’
I'm somewhat somewhat new developing on the Mac (more experience with Linux and Windows). Right now, I don't need to use Objective-C or Objective-C++. It's just getting in the way of being able to compile other packages (though I may want to start using it down the road). If anyone has any thoughts I would appreciate it. Thank you.
You...don't. GNU's GCC is not compatible with Apple's GCC in terms of Objective-C runtime support. You'll get the GNU Objective-C runtime which is the compatibility problem.
My strong suggestion to you is to not use C++0x features until the new standard is...a standard, and not a draft. Don't expect compiler support for draft features on all platforms.
On Lion, I was able to install gcc 4.7 using brew. I don't know if it will work on snow leopard.
You can try to install it from the homebrew-dupes container:
brew install --use-llvm --enable-cxx https://raw.github.com/Homebrew/homebrew-dupes/master/gcc.rb
Compiled gcc 4.7 successfully with c and c++ enabled on Lion.