Can someone either explain or preferably point me toward some documentation that explains the difference between passing --clang and not passing it to the gcc compiler.
I've had to append this parameter on numerous packages when compiling and I don't know what it does, I have yet to personally encounter code that won't compile without it but other projects seem to require it. I can not find it in the man docs for gcc, so I am trying to find a little bit more about what it is, all I know is that it has to do with the LLVM.
There's no --clang option to anything. clang is another compiler for OS X and is available inside Xcode as "clang". It's another compiler similar to gcc, and is the new default compiler for OS X.
A link from the Apple Developer Website explains more.
Related
In this documentation HP Fortran doc, the OPEN statement accept SHARED and READONLY options.
In this documentation Standard Fortran 2008 doc, the OPEN statement dosn't accept SHARED or READONLY options.
Since I'm using gfortran comes with gcc 4.4.7 to compile a Fortran source file on Linux,I used a ruse to get around half the problem. I used
OPEN(...,ACTION=READ,...) instead of READONLY.
But can't find an other ruse (:)) to replace SHARED Option. (Like Something=Shared).
Anyone have a ruse to get arround that?
Those IO extensions (SHARED, READONLY, etc) as well as other extensions, as would be available with DEC based Fortran should be available in GCC/gFortran via the "-fdec" and related compiler switches.
However, I found some confusion in the online GCC docs. Apparently, some older versions of gFortran (and in particular g77) may require the compiler to have been built with the libf2c element, and there may be differences on Unix (c.f. Win etc).
It is not clear exactly which versions of gFortran accept this. For example, under Windows, with GCC/gFortran 6.x, it would not recognise the "-fdec" switch.
Apparently, GCC/gFortran v7.x have all that working, but v7 is still in "development mode" ... are you feeling lucky :-) ?
Also, some references give dire warnings about reliance on "extensions".
Here are some pages of interest:
https://gcc.gnu.org/wiki/GFortran/News
https://gcc.gnu.org/onlinedocs/gfortran/Extended-I_002fO-specifiers.html
https://gcc.gnu.org/onlinedocs/gfortran/Option-Summary.html
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
The last link seems particularly "dire" on the subject.
I'm trying to get boost fiber up and running on os x, and I'm having quite a few issues. First, fiber won't compile with Apple clang because of the use of thread_local which Apple does not support (according to what I found online, they think they can implement it better than standard llvm and don't want to introduce it only to break ABI later).
So instead, I tried using gcc-5 installed through homebrew. After a bit of screwing around with boost build I managed to get fiber to build, and I can link sample programs successfully, but they seg fault.
Then I figured I'd give current llvm a try, since it has thread_local support, and I can again get boost fiber to build fine, but now I'm getting issues because the os x linker doesn't seem to handle thread local properly either! I would post the exact error, but my power is out. I did actually get it to link though with a couple changes to fiber, but the sample program failed again.
So the question is, how can I make this happen? Is there any way to get another linker working to produce os x executables for me? Llvm comes with another linker called lld, but I don't think it does what I'm after.
I think if I absolutely had to, I could go through fiber and boost context replacing all thread_local with boost::thread_specific_ptr, but I'm not sure how deep that rabbit hole goes. Any suggestions?
I'm getting a segfault in my C program, and I thought I'd use Clangs help in figuring out why, as Valgrind isn't supported (yet).
I try to compile my program with -fsanitize=undefined to activiate runtime checks for undefined behaviour. All I'm getting is an error message which reads something like: "fsanitize doesn't support option 'undefined'". I've also tried using -fsanitize=address with the same result :/
Anyone know why this is?
It seems like -fsanitize is not supported by apple's CLang.
If you go here http://llvm.org/releases/download.html#3.4 you can get the prebuild binaries of clang, that do recognize this option.
However this is harder because then you have to use a Makefile,
IF by chance you use cmake, then you can just easily go to use makefiles.
OR replace the binaries in the Xcode.app/Contents/Developer/Toolchains/.../bin
but I don't know what can happen if you replace Apples binaries, do a backup before to be able to restore.
Honestly, I'm not myself confortable about replacing apple's binaries, because they probably added something in the clang to make it work with Xcode nicely.
Again, the GPL policy of GCC had this advantage that apple could not modify it.
-> another solution is to develop on linux,
The port to windows of CLang is on its way, but not ready yet, maybe in 3.5.
Best
Setup: I installed Cygwin with the GNU programming lineup (gcc, g++, make, and gdb) and successfully compiled an ran a program that I was working on. Then I decided to install boost into Cygwin because I will need to use typical boost stuff as my program develops. So, using the Cywing setup.exe, I installed boost. After this, the program that I had just successfully compiled and ran no longer worked. (And recall that it didn't depend upon boost.)
I found out that when boost installed, it also installed a new compiler, g++-4.exe, whereas previously I had been using r++-3.exe. Boost had also symbolically linked g++.exe to the new compiler. After I changed back the symbolic link my old program compiled correctly.
Is there any reason that I should be using g++-4 rather than g++-3?
g++ 3 is very old and the gcc community has long since dropped maintenance of it. (GCC 4.3 is currently the oldest maintained release series.) There have been lots of language conformance improvements in newer versions (both in accepting valid code and rejecting bad code), so you'll have an easier time going forward if you bite the bullet now. You can check the release notes for each series (e.g. for 4.0) for explanations of these improvements and the code changes they might require. Personally, I find programming much more enjoyable when I can reason about programs according to a precise language specification, and only rarely be forced to understand the quirks of a particular compiler.
Also, Boost support for g++ 3 seems to be nearing an end, as Boost 1.44 considers GCC 3(.4.6) as an "additional test compiler" on only a single platform (RHEL). Boost development is linear (not branched), so you can find yourself in a situation where you need to upgrade to get bug fixes, but then find that your platform is no longer supported.
Reference this question about compiling. I don't understand how my program for Mac can use the right -arch, compile with those -arch flags, the -arch flags be for the system I am on (a ppc64 g5), and still produce the wrong object code.
Also, if I used a cross compiler and was on Linux, produced 10.5 code for mac, how would this be any different than what I described above?
Background is that I have tried to compile various apache modules. They compile with the -arch ppc, ppc64, etc. I get no errors and I get my mod_whatever.so. But, apache will always complain that some symbol isn't found. Apparently, it has to do with what the compiler produces, even though the file type says it is for ppc, ppc64, i386, x_64 (universal binary) and seems to match all the other .so mods I have.
I guess I don't understand how it could compile for my system with no problem and then say my system can't use it. Maybe I do not understand what a compiler is actually giving me.
EDIT: All error messages and the complete process can be seen here.
Thank you.
Looking at the other thread and elsewhere and without a G5 or OSX Server installation, I can only make a few comments and suggestions but perhaps they will help.
It's generally not a good idea to be modifying the o/s vendor's installed software. Installing a new Apache module is less problematic than, say, overwriting an existing library but you're still at the mercy of the vendor in that a Software Update could delete your modifications and, beyond that you have to figure out how the vendor's version was built in the first place. A common practice in the OS X world is to avoid this by making a completely separate installation of an open source product, like Apache, using, for instance, MacPorts. That has its cons, too: to achieve a high-level of independence, MacPorts will often download and build a lot of dependent packages for things which are already in OS X but there's no harm in that other than some extra build cycles and disk space.
That said, it should be possible to build and install apache modules to supplement those supplied by Apple. Apple does publish the changes it makes to open source products here; you can drill down in the various versions there to find the apache directory which contains the source, Makefile and applied patches. That might be of help.
Make sure that the mod_*.so you build are truly 64-bit and don't depend on any non-64 bit libraries. Use otool -L mod_*.so to see the dynamic libraries that each references and then use file on those libraries to ensure they all have ppc64 variants.
Make sure you are using up-to-date developer tools (Xcode 3.1.3 is current).
While the developer tool chain uses many open source components, Apple has enhanced many of them and there are big differences in OS X's ABIs, universal binary support, dynamic libraries, etc. The bottom line is that cross-compilation of OS X-targeted object code on Linux (or any other non-OS X platform) is neither supported nor practical.