Created attachment 212851 [details] Use llvm::CGFT_ObjectFile instead of llvm::TargetMachine::CGFT_ObjectFile Trying to build mesa-dri on FreeBSD-12/i386, I got the following error: common/ac_llvm_helper.cpp:138:9: error: no member named 'CGFT_ObjectFile' in 'llvm::TargetMachine'; did you mean 'llvm::CGFT_ObjectFile'? llvm::TargetMachine::CGFT_ObjectFile)) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ llvm::CGFT_ObjectFile /opt/llvm10/include/llvm/Support/CodeGen.h:65:5: note: 'llvm::CGFT_ObjectFile' declared here CGFT_ObjectFile, The change helpfully suggested by the compiler seems to have worked and the build is proceeding, but the file is over a year old -- how did it work for others?
Which version of LLVM are you using? It looks like you're trying to use llvm10, which is not supported.
(In reply to Niclas Zeising from comment #1) Well, I do have llvm=10 in the defaults list, just was not sure, if the port uses that -- seemed like /usr/bin/c++ was used for compiling (which on 12.1-stable is 9.0.1). In either case, if the attached change is all it takes to get it to work -- it finished compiling and installed -- maybe, add the patch to the port's files/ directory? Or do you think, it is a bug in compiler?
Forcing llvm10 is probably why it breaks. mesa still uses llvm80 from ports, because there were runtime issues when we switched to llvm90 in ports, so even if your patch fixes your problem, it might break compiling using the default set up (I haven't tested your patch using the default set up), so I'm quite hesitant to apply it. The waning you pasted seem to indicate that it picks up /opt/llvm10/include/llvm/Support/CodeGen.h (that's where I got llvm10 from). Do you have a special install of llvm10 in /opt? There hasn't been any changes to mesa in a while, and it builds fine on the FreeBSD build cluster.
(In reply to Niclas Zeising from comment #3) > it picks up /opt/llvm10/include/llvm/Support/CodeGen.h (that's where I got llvm10 from). Duh, of course -- sorry, I missed that part of my own bug-report :) > Do you have a special install of llvm10 in /opt? Not special -- /opt is the PREFIX on all of my systems. I'm not "forcing" llvm10 -- I simply have llvm=10 listed in the DEFAULT_VERSIONS. Certainly, that will become standard soon -- in a few month -- so it may be worth investigating the problem right now... Depending on whether this is a compiler or the code bug, we'd want to report it to the correct upstream -- but have a fix ready as well...
Seems to be an error in how mesa forces llvm80. jbeich posted a patch here https://reviews.freebsd.org/D24222 , can you try it?
(In reply to Niclas Zeising from comment #5) > Seems to be an error in how mesa forces llvm80 I doubt it -- it would only have effect, if there was no llvm-entry in the DEFAULT_VERSIONS setting at all. And the only llvm I have installed on this machine is llvm10 anyway -- it did not quietly build llvm8, while I was not watching :) My only 12.x machine is this old box, where recompiling anything takes forever (building llvm10, for example, took 24 hours), so I cannot easily try things on it, unfortunately.
Created attachment 212863 [details] Allow compiling with llvm10 Ok, I was able to reproduce the problem on my main (fast) machine running FreeBSD-11-STABLE (amd64). Not a compiler bug -- seems like the namespace was simply rearranged in llvm-10. This patch makes the port compilable with any LLVM-version (tested with both 9 and 10 -- I no longer have 8). I also think, the forced setting of LLVM_DEFAULT in Makefile.common should be removed altogether, but that's a separate topic. (The check currently does not catch 10.0, because 10 < 90 :-)
(In reply to Mikhail Teterin from comment #7) Forcing mesa to use llvm80 is correct. There are runtime issues with later llvm versions, at least with amd gpu hardware. The phabricator review I linked you to has a fix that properly fixes the llvm downgrade if llvm10 is selected, which is why I asked you to test it.
(In reply to Niclas Zeising from comment #8) > There are runtime issues with later llvm versions Then it should be using IGNORE= or BROKEN= instead of quietly dragging-in an entire new compiler suit :-( For all we know, these unidentified "issues" may have been solved upstream already -- but, with the current "work around", we're unlikely to ever know... There is also a simple rule of thumb: if your port can only be built with a particular compiler, then the underlying code is broken... Years ago, the then-maintainer of OpenOffice.org created lang/gcc-ooo -- a version of gcc intended solely for building OpenOffice. It was ridiculous then, and it remains ridiculous today... At any rate, the proposed patch allows the code to compile with llvm10, if the compiler is ever allowed to run.
(In reply to Mikhail Teterin from comment #9) > Then it should be using IGNORE= or BROKEN= instead > of quietly dragging-in an entire new compiler suit :-( Not how USE_GCC works, so it wouldn't make sense to do the same in DEFAULT_VERSIONS. If you want to limit the number of concurrently installed llvm* packages use DEFAULT_VERSIONS+=llvm=80 or lower. > For all we know, these unidentified "issues" may have been solved > upstream already -- Sure. Switch to https://github.com/myfreeweb/freebsd-ports-dank/tree/lite/graphics/mesa-dev then fix i386 support there. > but, with the current "work around", we're unlikely to ever know... See bug 239682 drama. Sorry, I'm not interested in your rant.
(In reply to Mikhail Teterin from comment #9) This is not the case. mesa uses llvm libraries for shaders and software rendering, as a few examples. The FreeBSD base system does not carry those libraries, on purpose, so mesa requires llvm from ports. No matter what you do, this will be the case. There are runtime issues when running mesa (the version we have in ports) with a llvm version later than 8.0, so it is clamped to use llvm80. This has nothing to do with needing a special compiler to build, and everything to do with having a specific runtime. The bug here is that the check for llvm version in the mesa port is broken, something I've provided a link to a patch for.
(In reply to Jan Beich from comment #10) > If you want to limit the number of concurrently installed llvm* packages > use DEFAULT_VERSIONS+=llvm=80 or lower. Is it really asking too much to want to use the latest version of the compiler? > Sorry, I'm not interested in your rant. Had you actually been sorry, you wouldn't have posted this, Jan. Do try to remain professional, at least, in public. > (In reply to Niclas Zeising from comment #11) > so mesa requires llvm from ports I think, the proper way to handle the pieces of llvm missing from base (be they the recently-added OpenMP, or AMDGPU or whatever) is by adding them via a port of their own. But that, of course, is out of scope of this ticket... Anyway, you have the patch allowing your port to compile with llvm10 -- whether it actually works afterwards (and it seems like for non-AMD it should already), it will be the end-user's responsibility... The patch can be dropped into the port's files/ and this ticket can be closed -- thanks for the prompt response.
Breaking out libLLVM.so and friends out of the llvm* ports is indeed out of the scope of this PR, and probably very hard, and a bad idea. It also wouldn't help very much, you still need to build them, and I assume they are not small things to build. It has been discussed several times why mesa requires llvm from ports rather than base, here is more info: https://wiki.freebsd.org/WhyDoIHaveToBuildLLVMWhenIAlreadyHaveClangInstalled Whether mesa works or not is not the end-users responsibility, it is our responsibility as porters. I'm not dropping in a patch, and making mesa even harder to maintain, just because you want to use a non-default, unsupported configuration. There is a reason mesa is clamped to use llvm80 or earlier.
(In reply to Niclas Zeising from comment #13) That link does not explain very much -- just saying "it happens". If all, that needs to be added, is the AMDGPU-backend, then it can be done -- especially, if the base compiler is of the same version as desired. > Whether mesa works or not is not the end-users responsibility If the user set a particular compiler, rather than using the defaults, then it is his own responsibility. Perhaps more to the point, there is a large number of users, for whom this is all unnecessary in the first place -- those with i915 cards, for example. Or those like myself, with Radeon R300, which LLVM does not seem to support at all. > I'm not dropping in a patch I did my best... You are welcome.
(In reply to Mikhail Teterin from comment #14) It is not just the AMDGPU backend. It is libLLVM, which the FreeBSD base system does not carry, since it is not guaranteed ABI/API stable (as you've seen, since you get compile errors), so using the base LLVM version is out of the question.
A commit references this bug: Author: jbeich Date: Mon May 11 20:11:42 UTC 2020 New revision: 534936 URL: https://svnweb.freebsd.org/changeset/ports/534936 Log: Adapt LLVM_DEFAULT downgrades to the new version scheme in devel/llvm10 $ DEFAULT_VERSIONS=llvm=90 make -V LLVM_DEFAULT -C graphics/mesa-dri 80 $ DEFAULT_VERSIONS=llvm=10 make -V LLVM_DEFAULT -C graphics/mesa-dri 10 PR: 245178 Reported by: mi Approved by: x11 (zeising), maintainer timeout (2 months) MFH: 2020Q2 (for llvm10 users) Differential Revision: https://reviews.freebsd.org/D24222 Changes: head/devel/libclc/Makefile head/devel/oclgrind/Makefile head/devel/py-llvmlite/Makefile head/devel/qtcreator/Makefile head/graphics/mesa-dri/Makefile.common head/security/afl/Makefile
A commit references this bug: Author: jbeich Date: Sat May 16 04:45:53 UTC 2020 New revision: 535352 URL: https://svnweb.freebsd.org/changeset/ports/535352 Log: MFH: r534936 Adapt LLVM_DEFAULT downgrades to the new version scheme in devel/llvm10 $ DEFAULT_VERSIONS=llvm=90 make -V LLVM_DEFAULT -C graphics/mesa-dri 80 $ DEFAULT_VERSIONS=llvm=10 make -V LLVM_DEFAULT -C graphics/mesa-dri 10 PR: 245178 Reported by: mi Approved by: x11 (zeising), maintainer timeout (2 months) Approved by: ports-secteam (joneum) Differential Revision: https://reviews.freebsd.org/D24222 Changes: _U branches/2020Q2/ branches/2020Q2/devel/libclc/Makefile branches/2020Q2/devel/oclgrind/Makefile branches/2020Q2/devel/py-llvmlite/Makefile branches/2020Q2/devel/qtcreator/Makefile branches/2020Q2/graphics/mesa-dri/Makefile.common branches/2020Q2/security/afl/Makefile