-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gprbuild seems favour LLVM over GCC for C code and causing linking error for GtkAda #60
Comments
The logic is simply the PATH order. So swapping the two toolchains (or just hiding llvm one outright) is an easy way to get what you want. You can also use the following declaration to force gcc:
|
Are you sure this is not a bug ? I am not sure that you can just replace gcc with clang without side effects, as they sometimes have different behaviours For example I get this errror:
Because the specs file is ignored by clang, the include paths ("For Source_Dirs") are missing, and the build fails. I suggest to consider re-opening this ticket and fixing the bug.. |
Yes, we are sure. If you check the doc for the word "PATH" you will see it mentioned all over the place. This is by design.
There is nothing non-deterministic about PATH - it's a string! You probably mean that it can change from one call to the next - yes indeed, and is exactly the way we want it.
No, gprbuild is not part of gcc collection to enforce such a default; besides - which gcc exactly should be the default? User system can have dozens...
If you feel that this attribute merits better documentation, feel free to propose a PR.
It should be Toolchain_Name, not Driver. The two declarations have very different semantics. If you do the above you'll be configuring for clang and just replacing the compiler driver at the last moment.
So do different versions of gcc; it's the knowledge base's responsibility to configure the toolchain correctly. The problem you are reporting suggests it's not working properly for LLVM, which is a different matter entirely - can you please open a new issue for that and we'll look into it.
There is no bug with respect to which toolchain gets selected, so please let's not recycle this issue to address an unrelated one. |
Note - please open it for gprconfig_kb project where KB is now maintained. |
Thank you for your quick answer.
By non-deteministic I mean that the tool makes a choice not only based on the inputs you give (the gprfile and the tool's own configuration, i.e. the gpr knowledge base) but also based on random environment strings (random in the sense it depends on the order in which the user installed tools and updated the PATH). I think this non-determinism is a bug, and it would be solved by either setting a default Toolchain_Name (e.g. GCC) or having this parameter mandatory for the user to set (at the minimum a warning or info should be displayed to indicate which toolchain is used and why).
Sure but it is a chicken and egg issue for me. The documentation that mentions this parameter (https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/gnat_project_manager.html) does not give the list of possible toolchain names, which is the information missing in the documentation, and does not tell where to find this information. |
But it's universally true - if the user is careless about setting up his environment, he is liable to not use the right toolchains. Even if we preferred gcc to other toolchains (which we have no practical means of doing short of hardcoding it in gprconfig), we still would in the general case have the issue of choosing between potentially several gcc toolchains. Note that the user can preconfigure his build environment with explicit paths by calling
Wait. If the two toolchains are in the same location, then PATH order is red herring. In this case toolchain will probably indeed be chosen non-deterministically (in the sense of "in arbitrary order").
It really is not a bug but expected behavior. Either the user doesn't care about the toolchain that gets used, only for the final result, or he does; in the latter case, he has the means to enforce it.
We don't have a notion of "default toolchain" at the moment; implementing such a notion may indeed be beneficial but it is a major change (requires implementing fallback mechanism at a place where none exists at the moment). If you feel motivated, again, PR is probably the best way to see this enhancement implemented.
The former would be very unfriendly, to accomplish the later you can use
Of course it doesn't - it's a property of the knowledge base, which is external to the tool and user-modifiable. Nothing prevents you from defining your own toolchain.
This information is in the chapter about the knowledge base.
Not sure I understood that - you'd be documenting the current state of things, previous versions of gprbuild have past version of documentation so necessarily don't include the passage that doesn't even exist yet... |
Indeed, this is not a path order issue, as both of the compiler resides at the same path (/usr/bin). And the system have only one gcc and one llvm, when Ada is compiled with gnat and C compiled with llvm looks weird without user direction. |
@maxime-esa Thanks for your post with that line for configuring I'm new to Ada, and have been trying to figure out how to use a locally-built version of GCC 13 dev I have at It seems like this is the trick? gprconfig --batch \
--target=x86_64-pc-linux-gnu \
--config=Ada,,default,/usr/local/gcc-dev/bin,GNAT \
--config=C,,,/usr/local/gcc-dev/bin,GCC \
--config=C++,,,/usr/local/gcc-dev/bin,G++ |
@GavinRay97 that's one way to do it; since it sounds like what you really want to tell gprconfig is "use toolchain of specific version and not any other" you can also make this explicit, with an option like |
Hi,
In Slackware-current, it has both llvm-8.0.0 and gcc-9.1.0 installed. After compiling/installing gprbuild (master trunk code), test build with gtkada (trunk code).
It compiles the C code in gtkada with llvm, and Ada part with gnat in GCC, which causing linking error.
If llvm is removed from the system, then everything is compiled fine.
What is the logic here to prefer llvm for C compilation? Is there a simple way to only use GCC in stead, or if Ada is compile with gnat then C should use gcc? Or it is a GtkAda configure problem?
The text was updated successfully, but these errors were encountered: