In my attempt to compile GCC I noticed that while ./configure doesn't yield error messages and returns an error code of 0, there are still errors logged in config.log, which do later on cause make to fail. So, why doesn't configure fail already? Or does make modify config.log later on?
config.log contains the output of all configure probes. Some of them are expected to fail. For example, frequently Autoconf probes for several different possible alternative implementations of particular functionality, and some of them are expected to fail depending on the characteristics of your system.
It's therefore up to the author of the Autoconf configure.ac script to explicitly fail the configure step if the results are not viable. Some people do this when writing their configure.ac and some don't. Sometimes it can be quite hard to know at configure time whether a particular set of findings are viable. There's also a reasonable argument that it's easier to diagnose problems during the build, later on, than to issue an error message from configure and make people search through config.log for the details. That's particularly the case if the problems are relatively obscure.
The short answer is that configure didn't fail because the people who wrote the configure script you're running didn't program it to fail for the specific errors that you're seeing, for one reason or another.
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 am trying to build GridDB from source code on MacOS as recommended How to setup GridDB on macOS with instructions https://docs.griddb.net/gettingstarted/using-source-code/#build-a-server-and-client-java.
During the automake step, I get the following warning(s) for many source files:
3rd_party/MessagePack/Makefile.am:8: warning: source file '$(srcdir)/src/objectc.c' is in a subdirectory,
3rd_party/MessagePack/Makefile.am:8: but option 'subdir-objects' is disabled
Has anyone else had this? Any advice of how to make solve this warning? Is it critical in the make process?
There is a subtle difference between a warning and an error.
Both indicate problems, but while an error indicates a fatal problem that requires a solution right now, a warning is just that: a hint that there's a potential problem.
So: there's no need to solve anything right now.
As a user (of GridDB), you (normally) can ignore any such warning.
However, the maintainers (of GridDB) should look into that, as the warning might turn into an error as the world outside evolves.
Having said that, afaict not using subdir-objects with sources in subdirectories is not a problem per se, and some might prefer it that way. automake tries to push towards subdir-objects, as it fixes problems if you have multiple files with the same name in different directories. However, this (multiple same-named files in different directories) is not the case here.
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.
I find it difficult sometimes to locate errors/warnings in large projects upon make-ing (gnu). How do I segregate the errors/warnings from the usual compilation messages when the error does not stop the build process from going any further? A wrapper shell script could pick and display whatever I want, but before fleshing out one I thought of asking about the alternatives.
Thanks.
In theory, make -s will suppress the "routine" output of the build process, leaving you with only the errors and warnings. Also in theory, make will stop as soon as it encounters an error.
If either of those is not true for the project(s) you're working with, that's probably due to poorly written makefiles. So fixing the makefiles is one alternative.
To help make sense of verbose builds, some simple highlighting as provided by colorgcc can go a long way. IDEs like eclipse or even emacs can also helpfully pick out the error messages in the build output.
Also, it might be helpful to note that warning and error messages are usually written to stderr, while everything else goes to stdout. So it might be useful to simply discard stdout like so: make >/dev/null.
I am trying to debug an intermittent parallel build issue in my cmake build system around some generated files. It is however difficult to reliably test or reproduce the issue.
Does anyone know any way to exacerbate or sensitise such issues? Or other strategies for debugging them?
It is likely a missing add_dependencies to force one target to build completely before another begins, or an add_custom_command output that is used in more than one library.
If both libraries start building at the same time, and they both trigger running the custom command at the same time, then you'll get two competing custom commands running, and they may overwrite each other's results, or intermingle results.
Is your code public? Can you post it for others to inspect?
One good strategy is simply exposing it to other developers for "more eyes"...