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.
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.
CLion has a nice integration of Clang-Tidy, but the default configuration is targeted to modern C++. The compiler I'm stuck with however is C++03 only and all the advices of Clang-Tidy on modernizing my code just continue to rub in the fact that my compiler is very old.
I have identified already a couple of checks that must be deactivated for C++03, but this list is surely far from complete:
boost-use-to-string
all modernize-use-* checks
Does anybody have compiled a list of checks to deactivate for C++03?
Unfortunately, there is no standard way to disable all irrelevant Clang-Tidy checks for old compilers in CLion.
Clang-Tidy was initially designed to modernize whole code base to new C++ standards and many checks ignore fact with old standards.
But you can easily setup and disable all irrelevant checks for your project right from context-menu:
disable Clang-Tidy from context-menu
By this, you can disable particular check (e.g. modernize-use-nullptr), whole group (e.g. all modernize-* inspections) or you can suppress Clang-Tidy for current line by inserting //NOLINT comment at the end of line.
Hope it helps you!
I have a project, where I want to link one of system libraries statically. The project uses GNU build system.
In configure.ac I have:
AC_CHECK_LIB(foobar, foobar_init)
On development machine this library is installed in /usr/lib/x86_64-linux-gnu. It is detected, but it is linked dynamically, which causes issues, as it is not present on some machines. Linking it statically (-Wl,-Bstatic etc.) works fine, but I don't know how to set this up in autotools. I tried forcing this into Makefile.am link flags for the project, but it still gives a preference to dynamic library.
I also tried using --enable-static with ./configure, but it seems to have no effect on system libraries.
If you want to link the whole program statically, then you should pass the --disable-shared option to configure. You might or might not need also to pass --enable-static, depending on the default value for that option (which you can influence via your configure.ac file). You really should consider doing this.
You should also consider making this the installer's problem, not the build system's. Let it be the installer's responsibility to ensure that all the shared libraries needed by the program are provided by the systems where it is installed. This is very common; in fact, it is one of the inspirations for package-management systems such as yum / dnf and apt, and their underlying packaging formats.
If you insist on linking only one library statically, while linking everything else dynamically, then you'll need to jump through a few more hoops. The objective will be to emit link options that cause just that library to be linked statically, without changing other libraries' linking. With the GNU toolchain, and supposing that the program is otherwise being linked dynamically, that would be this combination of options:
-Wl,-Bstatic -lfoobar -Wl,-Bdynamic
Now consider the documentation of the AC_CHECK_LIB() macro:
Macro: AC_CHECK_LIB (library, function, [action-if-found],
[action-if-not-found], [other-libraries])
[...] action-if-found is a list of shell commands to run if the link with the library succeeds; action-if-not-found is a list of shell
commands to run if the link fails. If action-if-found is not
specified, the default action prepends -llibrary to LIBS and defines
'HAVE_LIBlibrary' (in all capitals). [...]
Note in particular the default behavior in the event that the optional arguments are not provided (your present case) -- that's not quite what you want, at least not by itself. I suggest providing at least an alternative behavior for action-if-found case, and you could consider also making configure fail in the action-if-not-found case. The latter is left as an exercise; implementing just the former might look like this:
AC_CHECK_LIB([foobar], [foobar_init], [
LIBS="-Wl,-Bstatic -lfoobar -Wl,-Bdynamic $LIBS"
AC_DEFINE([HAVE_LIBFOOBAR], [1], [Define to 1 if you have libfoobar.])
])
You should also pay attention to the order of your AC_CHECK_LIB() invocations. As its docs go on to say:
This macro is intended to support building LIBS in a right-to-left
(least-dependent to most-dependent) fashion such that library
dependencies are satisfied as a natural side effect of consecutive
tests. Linkers are sensitive to library ordering so the order in which
LIBS is generated is important to reliable detection of libraries.
If you find that you still aren't getting what you want, then have a look at the link commands that make actually executes. You need to understand what's wrong about them before you can determine how to fix the problem.
With all that said, I observe that the above treatment is basically a hack, and it makes your build system much less resilient. It introduces dependencies on GNU toolchain options (which some other toolchains may nevertheless accept), and it assumes dynamic linking is being performed overall. It may be possible to resolve those issues with additional Autoconf code, but I urge you to instead go with one of the first two alternatives I described.
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.
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?