Bug 245178 - graphics/mesa-dri no member named 'CGFT_ObjectFile'
Summary: graphics/mesa-dri no member named 'CGFT_ObjectFile'
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL: https://reviews.freebsd.org/D24222
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-30 02:29 UTC by Mikhail Teterin
Modified: 2020-05-16 04:46 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
Use llvm::CGFT_ObjectFile instead of llvm::TargetMachine::CGFT_ObjectFile (368 bytes, patch)
2020-03-30 02:29 UTC, Mikhail Teterin
no flags Details | Diff
Allow compiling with llvm10 (507 bytes, patch)
2020-03-30 16:15 UTC, Mikhail Teterin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Teterin freebsd_committer 2020-03-30 02:29:29 UTC
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?
Comment 1 Niclas Zeising freebsd_committer 2020-03-30 07:02:35 UTC
Which version of LLVM are you using?  It looks like you're trying to use llvm10, which is not supported.
Comment 2 Mikhail Teterin freebsd_committer 2020-03-30 13:59:27 UTC
(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?
Comment 3 Niclas Zeising freebsd_committer 2020-03-30 14:11:35 UTC
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.
Comment 4 Mikhail Teterin freebsd_committer 2020-03-30 15:07:16 UTC
(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...
Comment 5 Niclas Zeising freebsd_committer 2020-03-30 15:08:01 UTC
Seems to be an error in how mesa forces llvm80.  jbeich posted a patch here https://reviews.freebsd.org/D24222 , can you try it?
Comment 6 Mikhail Teterin freebsd_committer 2020-03-30 15:19:05 UTC
(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.
Comment 7 Mikhail Teterin freebsd_committer 2020-03-30 16:15:25 UTC
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 :-)
Comment 8 Niclas Zeising freebsd_committer 2020-03-30 16:26:39 UTC
(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.
Comment 9 Mikhail Teterin freebsd_committer 2020-03-30 17:41:39 UTC
(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.
Comment 10 Jan Beich freebsd_committer 2020-03-30 17:55:55 UTC
(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.
Comment 11 Niclas Zeising freebsd_committer 2020-03-30 18:01:58 UTC
(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.
Comment 12 Mikhail Teterin freebsd_committer 2020-03-30 18:54:03 UTC
(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.
Comment 13 Niclas Zeising freebsd_committer 2020-03-30 19:27:08 UTC
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.
Comment 14 Mikhail Teterin freebsd_committer 2020-03-30 20:02:21 UTC
(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.
Comment 15 Niclas Zeising freebsd_committer 2020-03-31 10:45:06 UTC
(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.
Comment 16 commit-hook freebsd_committer 2020-05-11 20:12:30 UTC
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
Comment 17 commit-hook freebsd_committer 2020-05-16 04:46:48 UTC
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