I was wondering about the BII_IMPLICIT_RULES_ENABLED flag which I had switched off in one of my CMakeLists.txt files, in order to get an OpenGL related block to compile on a Mac, following a suggestion from biicode. This setting is still there and everything works perfectly, but I would like to find out more about it. Could someone explain what it does exactly?
Thanks!
BII_IMPLICIT_RULES_ENABLED activates the addition of system libs to the target that has included certain headers. For example, if your code contains an:
#include "math.h"
And you are in *nix systems, then the library "m" (libm) will be added to your target via TARGET_LINK_LIBRARIES.
You can see the headers that are processed in your cmake/biicode.cmake file, in the HANDLE_SYSTEM_DEPS
My recommendation: Put it to False whenever possible, and handle the required system libs yourself, exactly what you have done. It is something that will be deprecated soon, or at least set to False by default to new projects. This option sometimes causes troubles, if something fails or there is a bug in biicode.cmake, e.g. in the past it tried to add libm to targets also in windows. It will be gradually deprecated and probably substituted by some CMake macros hosted (as in http://www.biicode.com/biicode/cmake) that could be used by users if they decide to, but not automatically as it is done now.
Related
I am trying to build the apcupsd package under a newer version of MacOS and Xcode, but the configure script supplied with the current version of apcupsd breaks under Xcode 12.4 (though it worked under Xcode 11.2).
The error is gethostbyname_r is required. Now, configure tests for this function, and ordinarily it adapts to systems that do not provide it. On the newer Xcode version, however, configure just exits with an error. I THINK it has something to do with Apple making the -Werror setting mandatory. I've found that I can get a successful build by commenting out the broken test in configure, then running it and explicitly passing the flag that configure is supposed to set. But that's not very satisfactory.
Is there is a general way to pass an override to configure for the compiler? I tried setting -Wno-error in the CPPFLAGS and CFLAGS environment for configure, but the configtest program seems to ignore those. What seems to be going on is configure is seeing that gethostbyname_r doesn't exist and sets it to no but then later on still tests for it. I'm just wondering if there's a flag or something to get past this error, as it seems to me that whatever Apple did to break (or fix) Xcode after version 11.2 would have broken a lot of people's projects.
I am looking for a solution that does not involve modifying the program sources or the Autotools input files. The project manual is not helpful in this regard.
As an update: someone on the apcupsd list told me that this issue is fixed in a later version of Xcode. I have not tried that yet but when I do if that is what it proves out to be I'll post a followup
Is there is a general way to pass an override to configure for the
compiler? I tried setting -Wno-error in the CPPFLAGS and CFLAGS
environment for configure, but the configtest program seems to ignore
those.
If you set the CFLAGS or CPPFLAGS variable in configure's environment, then not only should configure use those flags when it builds test programs, but it should also memorialize the variable so that you don't need to specify it again to make. Indeed, this ...
What seems to be going on is configure is seeing that
gethostbyname_r doesn't exist and sets it to no
... suggests that it is doing so in your case.
In that event, if it seems to test again later, or else to fail in some other way despite determining that the function is not present, then that suggests a flaw in the project's own autotooling.
I'm just wondering if there's a flag or something
to get past this error,
You have already tried the most likely candidate (CFLAGS). Alternatively, you might also be able work around the issue through use of a cache file. That's still hacky, but I think less so than modifying the configure script. I'm afraid I have no specific guidance on doing this.
as it seems to me that whatever Apple did to
break (or fix) Xcode after version 11.2 would have broken a lot of
people's projects.
It did. That does not imply that there is a quick or easy solution, though it would be good news if indeed Apple solved the issue in a later version of Xcode.
I have some C++ code using NEON intrinsics. From what I have read, all you need to do is include arm_neon.h to your project.. And then I read that this arm_neon.h header is not actually readily available to you automatically, you have to get it from the web. So I found and added this version to my project:
http://clang.llvm.org/doxygen/arm__neon_8h-source.html
In my project's prefix.pch I added:
#import "arm_neon.h"
And when I try to build on my iPhone6 device (I am not using the simulator), I get a billion errors inside the arm_neon.h file:
Can anyone please explain to me what I am missing here?
You've been misinformed about being able to pick up an arm_neon.h from the Internet. Generally the header is not just compiler specific, but compiler version (even compiler revision) specific. For GCC it relies on a number of compiler built in function calls, and from your screenshot of Clang the same holds there. As you'd expect, if the name of these internal-only functions changes, the header will fail to compile.
What surprises me is that you're unable to use an include of whichever arm_neon.h ships with your build environment. The only thing I can think of that would cause this is the build command trying to build for x86_64 (for the simulator) but you say this isn't what is happening. It might be worth checking your build settings one more time.
If you're still not getting anywhere, remember that arm_neon.h is sometimes considered as a system header, so in C++ you might need to #include <arm_neon.h> rather than #include "arm_neon.h" to get the compiler to search the system paths.
I am learning compilers and want to make changes of my own to GCC parser and lexer. Is there any testing tool or some another way available which let me change gcc code and test it accordingly.
I tried changing the lexical analysis file but now I am stuck because I don't know how to compile these files. I tried the compilation using other GCC compiler but show errors. I even tried configure and make but doing this with every change does not seems efficient.
The purpose of these changes is just learning and I have to consider GCC only as this is the only compiler my instructor allowed.
I even tried configure and make but doing that wit every change is not at all efficient.
That is exactly what you should be doing. (Well, you don't need to re-configure after every change, just run make again.) However, by default GCC configures itself in bootstrap mode, which means not only does your host compiler compile GCC, that compiled GCC then compiles GCC again (and again). That is overkill for your purposes, and you can prevent that from happening by adding --disable-bootstrap to the configuration options.
Another option that can help significantly reduce build times is enabling only the languages you're interested in. Since you're experimenting, you'll likely be very happy if you create something that works for C or for C++, even if for some obscure reason Java happens to break. Testing other languages becomes relevant when you make your changes available for a larger audience, but that isn't the case just yet. The configuration option that covers this is --enable-languages=c,c++.
Most of the configuration options are documented on the Installing GCC: Configuration page. Throroughly testing your changes is documented on the Contributing to GCC page, but that's likely something for later: you should know how to make your own simpler tests pass, by simply trying code that makes use of your new feature.
You make changes (which are made "permanent" by saving the files you modify), compile the code, and run the test suite.
You typically write additional tests or remove those that are invalidated by your changes and that's it.
If your changes don't contribute anything "positive" to the compiler upstream will probably never accept them, and the only "permanence" you can get is the modifications in your local copy.
There is a bug in RHEL5's gcc-4.3.2 with which we are stuck. As a work-around we have extracted the missing object and put it in an object file. Adding this object file to every link makes the problem go away.
While adding it directly to LDFLAGS seems like a good solution, this doesn't work since e.g. libtool cannot cope with non-la files in there.
A slightly more portable solution seems to be to directly patch the gcc spec to add this to every link. I came up with
*startfile:
+ %{shared-libgcc:%{O*:%{!O0:/PATH/TO/ostream-inst.o}}}
where ostream-inst.o is added to the list of startfiles used in the link when compiling a shared library with optimizations.
Trying to compile boost with this spec gives some errors though since its build directly sets some objects with ld's --startgroup/--endgroup.
How should I update that spec to cover that case as well, or even better, all cases?
Go through this URL Specifying subprocesses and the switches to pass to them and GCC Command Options
If this help you, thats great.
I know this is not the answer you want to hear (since you specified otherwise in your question), but you are running into trouble here and are likely to run into more since your compiler is buggy. You should find a way of replacing it, since you'll find yourself writing even more work-around code the next time some obscure build system comes along. There's not only bjam out there.
Sorry I can't help you more. You might try simply writing a .lo file by hand (it's a two-liner, after all) and insert it into your LDFLAGS.
If it is a bug of GCC 4.3, did you try to build (by compiling from sources) and use a newer GCC. GCC 4.6.2 is coming right now. Did you consider using it?
I've run into trouble in the past when I've tried porting some C++ code written on Mac OS X to a Linux system, or trying to compile code written against an older version of gcc/g++ with a newer one:
It seems that some (older?) versions of gcc/g++ would automatically include some header files for you.
For example, code that uses printf should require #include <stdio.h>. And code that uses memcpy should require #include <string.h>. But depending on the version of gcc I'm using, it will occasionally include these for me.
It wreaks havoc when I forget to include something and then never get errors until I go to compile the code on another system. At that point it's a game of running all over the project and fixing the includes.
Has anyone else run into this? Is there a way to force gcc to autoinclude or to not autoinclude? Or, is there a way to know what it's autoincluding?
-include file
Process file as if #include "file" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the #include "..." search chain as normal.
If multiple -include options are given, the files are included in the order they appear on the command line.
http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
Are you sure it's not other headers pulling those one's in, and on the other platforms not doing so?
When compiling on different systems, you might meet different problems and not only includes.
I would suggest investing in a continuous build system that will compile on all OS you need after each update of the code, so you are rapidly aware of any portability issue.
You can also put all common system header files inside a specific header file you will write and systematically include it in all your files.