I am writing an sample app on MAC OSX 10.6 having gcc version 4.2.
I am compiling app using gcc version 4.2 .
It is working fine on the same machine but on MAC OSX 10.5 (gcc 4.0) it is not working.
how can I compile it on 10.6 so it will also work on old machine ?
I am getting these error
dyld: unknown required load command 0x80000022
Trace/BPT trap
command I used to build is
gcc -m32 main.cc
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 )
-arch i386 -Wl,-macosx_version_min,10.5 will help; I don't know for certain if they'll be sufficient, though.
Related
I'm currently compiling sources using --coverage, with GCC. The generated .gcno files (and the instrumented libraries) are to be packed in a RPM and the code coverage evaluated on another, target platform.
Now, I'm having a problem getting the coverage data, because when I run the programs calling the instrumented code, I get messages telling me that I have a version mismatch. They look like:
".gcda:Version mismatch - expected A85R got B12R"
Now, I've seen this question: GCOV Version mismatch - expected 700e got 408R which says I must use the same toolchain when compiling and when executing the code.
I'm compiling using gcc 11.2.1, and gcov --version says the same thing, on the source platform.
On the target platform, gcc --version and gcov --version both give that very same version number.
The compiling and the testing is done on the same "physical" machine, but on different Docker containers. On both of them, the GCC version and gcov version are the same
I've done further testing: even on the Docker container where we compile, we cannot run the coverage, and get the same error. Or, to be more precise, when compiled using gcc 11, it will say "version mismatch". However, when compiled using gcc 8.5, it works.
The setup is that we have the GCC 11 toolset, which requires gcc 8.5 to install. By default, gcc 8.5 is enabled, and you have to use a script (provided by the gcc 11 toolset) to enable the later. That script updates different variables, like the PATH, LIBRARY_PATH, etc., to look at GCC 11 first.
However, I'm pretty sure it doesn't upgrade the libc.so library, and that it's the cause of the problem: I compiled two of our simplest libs (each of them having no dependencies whatsoever, except libc) with gcc 11, in coverage mode. Then I compiled a simple test program, without coverage, calling some functions from the two instrumented libs. I checked (with elfread -d), the program only links to these two libs (and libc).
Calling this test program while on the compilation container results in the Version mismatch error, which would lead me to conclude that our libc.so isn't compatible with gcc 11.
I wonder if there is a way to get a "native" gcc 11, instead of a "toolkit" package which has to be installed over a gcc 8.5 (my colleague in charge of creating the Docker containers tells me that for gcc 9 and above, there are only "toolkit" packages, requiring gcc 8.5 to install).
Our target architecture runs on Rocky Linux, and I think our development architecture is a Redhat, if it has any importance here.
When using clang v8.0.0 on Windows (from llvm prebuilt binaries) with -g or -gline-tables-only source map tables are not being picked up by gdb or lldb debuggers.
Upon including -g flag file grows in size (which is to be expected) yet neither gdb nor lldb pickes the source up
When compiled with gcc though (with -g flag) source files are detected by debugger.
I have tried running the same command (clang -g <codefile>) on macOS High Sierra (clang -v says it is Apple LLVM version 10.0.0 (clang-1000/10.44.4)) where there source files are being picked up by lldb. So I guessed it is localized to my windows instance or llvm for windows build.
P.S. output of clang -v on windows:
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
On Windows, Clang is not self-sufficient (at least not the official binaries). You need to have either GCC or MSVC installed for it to function.
As Target: x86_64-pc-windows-msvc indicates, by default your Clang is operating in some kind of MSVC-compatible mode. From what I gathered, it means using the standard library and other libraries provided by your MSVC installation, and presumably generating debug info in some MSVC-specific format.
Add --target=x86_64-w64-windows-gnu to build in GCC-compatible mode. (If you're building for 32 bits rather than 64, replace x86_64 with i686). This will make Clang use headers & libraries provided by your GCC installation, and debug info should be generated in a GCC-compatible way. I'm able to debug resulting binaries with MSYS2's GDB (and that's also where my GCC installation comes from).
If you only have GCC installed and not MSVC, you still must use this flag.
How do I know this is the right --target? This is what MSYS2's Clang uses, and I assume they know what they're doing. If you don't want to type this flag every time, you can replace the official Clang with MSYS2's one, but I'm not sure if it's the best idea.
(I think they used to provide some patches to increase compatibility with MinGW, but now the official binaries work equally well, except for the need to specify the target. Also, last time I checked their binary distribution was several GB larger, due to their inability to get dynamic linking to work. Also some of the versions they provided were prone to crashing. All those problems come from them building their Clang with MinGW, which Clang doesn't seem to support very well out of the box. In their defence, they're actively maintaining their distribution, and I think they even ship libc++ for Windows, which the official distribution doesn't do.)
I'm using the Bochs emulator and for my class we're using gcc 4.2.1. I believe I've gotten Bochs running, but now I need to compile our programs which are compatible with gcc 4.2/.1.
I understand OSX uses an alias for gcc 4.2.1, but how can I use gcc specifically and not clang?
Edit: GCC 4.6.3 not 4.2.1 sorry
You can install previous version of gcc pretty easily using homebrew.
If you have homebrew installed you can get gcc 4.9 by running
brew install gcc#4.9
After it is installed gcc will still map to the clang that came with your mac. The newly installed gcc will be installed at /usr/local/bin and be called something like gcc-4.
You can find the exact executable name using
ls /usr/local/bin | grep gcc
Hopefully 4.9 is close enough to 4.6 for your purposes.
Since I updated to Mavericks my C app, compiled in my machine with clang, cannot be executed in Lion machines (yep, there are some people who have not updated). It throws
Segmentation fault: 11 error
I've read about stdlib option in this thread but it seems it only applies to clang++ and not to plain clang. Is there a similar option for clang? I've searched for --stdlib=libstdc in google but all results are for --stdlib=libstdc++
To compile an app for OS X 10.8 (Lion), you have to set the "Deployment Target".
The corresponding command line option for clang is
-mmacosx-version-min=10.8
You might also want to set the SDK to 10.8, to avoid that any library functions are used that are available only in 10.9:
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
I'm not sure the intent of the question, but Lion is actually 10.7, Mountain Lion is 10.8. Obviously, you wouldn't want to set the deployment target to 10.8, if you were targeting Lion (10.7). Both the previous comments and answer are conflicting in that regard.
*Note: I can't comment on them, as I don't have enough rep!
I just tried to write a simple C program on OSX Lion
#include <stdio.h>
int main() {
printf("hello world\n");
return 0;
}
Compiling with gcc
$ gcc hello.c
test.c:1:19: error: stdio.h: No such file or directory
test.c: In function ‘main’:
test.c:3: warning: incompatible implicit declaration of built-in function ‘printf’
Ok...fine
$ gcc -I /Developer/SDKs/MacOSX10.6.sdk/usr/include
ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
What? Let's see...
$ gcc -I /Developer/SDKs/MacOSX10.6.sdk/usr/include -L/Developer/SDKs/MacOSX10.6.sdk/usr/lib test.c
$ ./a.out
hello world
Finally!
That seems like a lot of effort just to get a hello world working, how do I make gcc find libraries and header files in the MacOSX10.6.sdk directory by default like it does on linux? On linux I find ldd and ldconfig quite useful, they don't seem to exist on OSX...is there an equivalent? What other useful tools are there for developing C on OSX?
Yes, I know xcode makes this easier, but suppose I wanted to use vim and the command line to work on an opensource c project.
I can think of three possibilities:
You had 10.6 installed and upgraded to 10.7. You need to install the new version of Xcode (4.1, get it from the app store) to get back the developer tools.
you installed Xcode, did a custom install, and unchecked "UNIX development" or something. Rerun the installer and install the missing parts.
You installed a broken third-party version of gcc. Try which gcc and see what you get.
On OS X 10.7, if you have downloaded Xcode 4.1 from the Mac App Store and then run the installer that it downloads (in /Applications), your first attempt should have worked just fine assuming you have not set some environment variables that are looked at and influence Apple's gcc tool chain. The object file that is produced in this case would be using the default 10.7 ABI (include files and libs). If you want to produce something that would be compatible with OS X 10.6, then you need to tell the tool chain to use the 10.6 SDK ABI, which is what you did in the third attempt. A standalone project typically handles this by setting up a Makefile to automate building. But, unless you are trying to build something on a version of OS X (10.7 here) that will also run on earlier versions of OS X (say 10.6), there is generally no need to use an SDK.