I'm trying to port to Macintosh OSX where clang is provided instead of gcc. When building on Linux with gcc, I pass -static-libgcc to gcc.
What is the nearest equivalent I might replace this option when using clang?
Probably this has already been sorted out, but for the sake of completeness,
-- you cannot not link with system libraries statically on mac, till you do some extra work of compiling crt0.o.
So, simply remove this flag.
Please see
stackoverflow.com/questions/5259249/creating-static-mac-os-x-c-build
https://developer.apple.com/library/mac/qa/qa1118/_index.html
Related
I have a code running on a PowerPC e500v2 embedded Linux and I want to measure its performance since it is running in an infinite loop. I tried gcc's gprof which was simply by adding -pg option to gcc. When I run the binary on the target device I get this:
./main: /lib/libc.so.6: version GLIBC_2.16 not found (required by ./main)
I am using ELDK 5.6 toolchain with the default CFLAGS and LDFLAGS and these flags: -Wall -lrt -pthread -D_GNU_SOURCE nothing else. Some article suggested defining FORTIFY_SOURCE along with an optimization level but it did not work. I searched for some gcc's feature test macros and tried defining some GLIBC 2.16 specific macros but it did not work.
I faced similar issue with GLIBC 2.17 when I used some structures and functions from <sched.h>, adding _GNU_SOURCE resolved it. Any idea on how to resolve it?
When I run the binary on the target device I get this
Your tool chain targets a version of GLIBC that is newer than what is installed on the target.
This doesn't bite you in non-pg compiles only by accident. An "innocent" change to your source can cause the same problem.
You need to upgrade your target to the version of GLIBC which your toolchain actually builds for.
I have Lion 10.7.3 with the Command-line tool installed. I wanted to experiment with C++11, so I used homebrew to install GCC 4.7 as documented here.
How can I now upgrade the /usr/bin/g++ to be the one installed by Homebrew? Is it as simple as symlinking it? I just want to double check and make sure. Thanks!
First, are you sure you need g++ 4.7? As you can see from the C++11 implementation status page, recent versions of clang support most of C++11 too. Of course there are still things that g++ handles and clang doesn't, but there are also still things that clang supports and g++ doesn't. And, more importantly, you already have a recent version of clang, from Apple, configured and ready to go, as your default compiler. Plus, g++ after 4.2 doesn't support Mac extensions like, say, -arch, which means you can't use it to build a whole lot of third-party software (because most configure scripts assume that if you're on a Mac, your compiler supports Mac extensions).
But if you want g++ 4.7, you can do it. Just not by trying to replace /usr/bin/g++ with a different version. Never replace anything in /usr/bin (or /System) with non-Apple stuff except in a few very rare cases (when you have a strong reassurance from someone who knows what they're talking about).
A better thing to do is to just install another compiler in parallel. Just let Homebrew install its favorite way (so it installs into some prefix like /usr/local/Cellar/gcc/4.7, then symlinks all the appropriate stuff into /usr/local/bin, etc.), and use it that way.
When compiling your code, instead of writing g++, write /usr/local/bin/g++, or g++-4.7.
If you get tired of doing that, put /usr/local/bin higher on your PATH that /usr/bin, or create a shell alias, or stick it in the environment variable CXX and write $CXX instead of g++.
If you're using a GUI IDE, you should be able to configure it to use your compiler by setting the path to it somewhere. (Unless you're using Xcode, which you can only configure to work with Apple-tested compilers.)
This is all you need for experimenting with your own code. If you want to compile third-party applications with this compiler, that may be a bit more complicated. You don't often actually compile each source file and link the result together; you just do configure && make and let them do the heavy lifting for you.
Fortunately, most packages will respect the standard environment variables, especially CXX for specifying a default C++ compiler and CC for a default C compiler. (That's why I suggested the name CXX above.)
Just remember that, again, g++ 4.7 doesn't support Mac extensions, so if you're not prepared to debug a bunch of autoconf-based configure scripts complaining that your compiler can't generate code because it assumed it could throw -arch x86_64 at any compiler on a Mac, etc., don't do this.
Is it possible to use the stock (non-apple) version of g++ on Mac OSX 10.7? I want to be able to use the stock g++ without running a virtual linux box on my mac. The reason I want to do this is because apple's version of g++ doesn't warn you when there are unused variables and etc. I'm doing some assessed C++ problems in my numerical methods course and I want to make sure I'm not making any mistakes.
It was suggested I make a symbolic link to a linux version of g++ for compiling the code for the assessments. How do I go about doing that?
Thanks
A linux version of the compiler will not work on what is (essentially) a bsd port.
Are you sure that the current version of g++ cannot warn on the conditions you expect?
Finally, if #2 is true, there is nothing stopping you from getting another version of g++ (compiled for MacOSX) that doesn't have this issue.
A binary for g++ for Linux won't run on MacOSX.
You could compile GCC from its source code; use the latest release i.e. 4.6.2. But that requires some work. Be sure to follow the installation instructions, in particular care about dependencies (like PPL & Cloog) and configure (appropriately) and compile in a build tree outside of the source tree.
my custom built gcc 4.6.0, installed in my home directory, on ubuntu 10.04, links the system libstdc++ instead of the custom built one, most of the time (as evidenced by ldd). to be more puzzling, using this newly built gcc, custom compiled openmpi libraries are linked correctly, and this is the only software i have compiled that behaves ok. does anybody have any explanation for this, or a workaround?
thanks
Isn't there an option to statically link the libstdc into the gcc when you configure it? --disable-shared if I understand how it works correctly. Worst case make another compile of gcc with that switch and see if you run into the issue.
I don't know why this isn't detailed more clearly on the GCC website for end-users. The GCC FAQ clearly states this is a common problem wrt libstdc++. Environment variables are troublesome. Wrapping the linker, nobody knows how to do that. Editing /etc/ld.so.conf isn't an option. Adding -Wl,-rpath everywhere, come on. The easiest solution is the specs file. For a typical 64-bit x86 Linux system, go into your custom gcc installation, in dirname `g++ -print-libgcc-file-name`and then run g++ -dumpspecs > specs. Edit that file, find the *link_command: section. After %(link_libgcc) add -rpath /home/user/bin/gcc-9/lib64 (of course use your own path). Or add the same rpath to end of *link: section. Alternatively, configure gcc with --with-specs='%{!static:%x{-rpath=/home/user/bin/gcc9/lib64} %x{-enable-new-dtags}}' . Enjoy your own C++ compiler that generates binaries that just work.
See also:
GCC specs file: how to get the installation path
Linking g++ 4.8 to libstdc++
How to configure libstdc++ with GCC 4.8?
I have been trying to produce a statically linked "single binary" version of my game for windows. I want to link with sdl, sdl_image and sdl_mixer which in turn pull in a few support libraries. Unfortunately I haven't found a way to get them all to compile and link using cygwin/mingw/gcc. As far as I can tell all existing public versions are only shared libraries / dlls.
Please note that I'm not talking about licencing here. The source will be open thus the GPL/LGPLness of sdl is not relevant.
When compiling your project, you need to make just a couple changes to your makefile.
Instead of sdl-config --libs, use sdl-config --static-libs
Surround the use of the above-mentioned sdl-config --static-libs with -Wl,-Bstatic and -Wl,-Bdynamic. This tells GCC to force static linking, but only for the libraries specified between them.
If your makefile currently looks like:
SDLLIBS=`sdl-config --libs`
Change it to:
SDLLIBS=-Wl,-Bstatic `sdl-config --static-libs` -Wl,-Bdynamic
These are actually the same things you should do on Unix-like systems, but it usually doesn't cause as many errors on Unix-likes if you use the simpler -static flag to GCC, like it does on Windows.
Via this SDL mailing list post it seems that the sdl development tools ship with a sdl-config script that you can use with the --static-libs flag to determine what linker flags you need to use.
Environment: VMWare Virtual Machine with Windows 7 x64 and Equipment we Dev c + + build 7.4.2.569, complilador g+ + (tdm-1) 4.6.1
Once, SDL2-2.0.3 API installed as configuration Dev c ++ is not very clear what I've done as tradition requires command line.
The first problem is that Windows 7 appears to have changed the methodology and they go to his ball. Inventory. Ref. https://stackoverflow.com/users/464581/cheers-and-hth-alf
After the first hurdle, SDL_platform.h is that bad, it's down another, I do not remember where I downloaded, but the next does not work in the indicated version.
We must put SDL2.h ls in the directory of the executable.
D:\prg_desa\zsdl2>g++ bar.cpp main.cpp -o pepe1 -ID:\SDL2-2.0.3\i686-w64-mingw32\include\SDL2 -LD:\SDL2-2.0.3\i686-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2 -mwindow
I've finally compiled and works SDL2 testing.
That's because the SDL libs are under the LGPL-license.
If you want to static link the libs (you can do that if your recompile them. It needs some hacking into the makefiles though) you have to place your game under some compatible open source license as well.
The SDL-libs come as shared libraries because most programs that use them are closed source. The binary distribution comes in a form that most people need.
On my system (Ubuntu) I have to use the following flags:
-Wl,Bstatic -lSDL_image `sdl-config --libs` -lpng12 -lz -ltiff -ljpeg -lasound -laudio -lesd -Wl,-Bdynamic `directfb-config --libs` -lpulse-simple -lcaca -laa -ldl
That links SDL, SDL_image, and many of their dependencies as static. libdl you never want static, so making a fully-static binary that uses SDL_image is a poor idea. pulse,caca,aa, and directfb can probably be made static. I haven't got far enough to figure them out yet.