[SOLVED] Libreoffice, llvm, mesa problem on AMD Graphics
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
After the Slackware64-current update on 4.10.2018, I have a problem on one of my boxes. It has two display controllers:
Intel Corporation HD Graphics 620 (rev 02) and
Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] (rev c3)
Now Libreoffice won't start - (neither libreoffice-6.1.2-x86_64-1alien, nor libreoffice-6.1.0-x86_64-1alien, nor Slackbuild's lbreoffice).
At the console I get the following messages:
Intrinsic has incorrect return type!
i8 addrspace(2)* ()* @llvm.amdgcn.dispatch.ptr
Intrinsic has incorrect return type!
i8 addrspace(2)* ()* @llvm.amdgcn.dispatch.ptr
Intrinsic has incorrect return type!
i8 addrspace(2)* ()* @llvm.amdgcn.dispatch.ptr
Intrinsic has incorrect return type!
i8 addrspace(2)* ()* @llvm.amdgcn.implicitarg.ptr
LLVM ERROR: Broken function found, compilation aborted!
The only considerable change on 4.10.2018 was mesa-18.2.2-x86_64-1.txz
So it seems to me that there maybe is an incompatible change concerning current's llvm, or AMDGPU or Libreoffice is at fault (perhaps didn't catch up quickly enough). Interesting that no other program is affected, and on my other 2 boxes (one with intell graphics, and another with nvidia) libreoffice is starting just fine...
I went back to the previous version of mesa (mesa-18.2.1-x86_64-1.txz) for Slackware64-current to test this. And everything went back to normal again !
I went back to the previous version of mesa (mesa-18.2.1-x86_64-1.txz) for Slackware64-current to test this. And everything went back to normal again !
Where did you find this package? I have googled and can't seem to find it. i would love to be able to load this previous version and get libreoffice working again.
I have a router with usb storage attached, where I keep some of the latest updates for Slackware64-current.
It's easier when updating the rest of my computers.
If you are interested , it can be reached here - ftp://109.199.241.108:59461/usb/SYSTEM/20180922/
May I ask, just out of curiosity, what is your graphics adaptor?
Would it be possible to bisect mesa with git and find out when this issue was introduced?
Sorry ,I don't know how to do this.
I feel ashamed, but I've never done this before, at least not with git!
And I imagine that it's not a simple job to compile mesa.
It is on my list with packages, that I don't have the courage to deal with compiling, like libreoffice, qt, VirtualBox, and such.
Its not really hard as it is tedious, you can use Pat's slackbuild as a template for building mesa, except you want to clone their git master instead of extracting the stable tarballs.
The steps are roughly.
1. Test the mesa git master to make sure its not already fixed.
2. Find a good working commit.
3. Find a bad not working commit.
4. Now inside the mesa git clone...
- git bisect start
- git bisect bad >bad commit hash here<
- git bisect good >good commit hash here<
- Build the commit that it points out and test the issue.
- If it works: 'git bisect good'
- If it doesn't work: 'git bisect bad'
- If it fails for an unrelated reason making it not possible to test: 'git bisect skip'
5. Build the commits it points out repeating the above until it tells you the first bad commit.
If you have any specific questions on the process I can try to help, but it will need to be done by someone that can reproduce the issue.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,039
Rep:
Quote:
Originally Posted by Hooks123
Where did you find this package? I have googled and can't seem to find it. i would love to be able to load this previous version and get libreoffice working again.
I have a router with usb storage attached, where I keep some of the latest updates for Slackware64-current.
It's easier when updating the rest of my computers.
If you are interested , it can be reached here - ftp://109.199.241.108:59461/usb/SYSTEM/20180922/
May I ask, just out of curiosity, what is your graphics adaptor?
I did the same thing that toodr did. I went back to the previous version of mesa (mesa-18.2.1-x86_64-1.txz) for Slackware64-current and it didn't work for me.
I went back to the previous version of llvm-6.0.1-x86_64-2.txz. libreoffice worked. I then upgradepkg llvm-7.0.0-x86_64-1.txz so now i am back to the current llvm-7.0.0-x86_64-1.txz and libreoffice still works. Very strange. Im just happy to have libreoffice in my life again. lol
to orbea: Thanks for the explanation, I'll have to dive in git when I have more free time.
Although if I get it right, the people at mesa have done some changes (which affect only the amdgpu driver for cards newer than 4xxx) and the people at libreoffice development didn't sensed that a change was made, or did not have a machine with newer AMD GPU (which is almost unbelievable) or could not react in time for some reason, or it is a simple coincidence - mesa update came out 1-2 days before libreoffices update. Anyway, libreoffice will have to cope with the changes in mesa (so we'll see it updated in the next release) and it's not the other way around, right?
So I would rather wait for libreoffice to be updated to cover the changes in mesa, and then I would update mesa and libreoffice for this particular computer.
I checked their devel forums and did not find an indication that they are aware of this problem. Should I report to them?
to Hooks123: Yes, this adaptor uses the same driver amdgpu, so it's highly probable that this is the case there.
In my case though, I have 2 graphics adaptors (Intel and AMD) and I did not set PRIME=1 when starting libreoffice, so theoretically libreoffice should have used the Intel adaptor and not bother with the AMD one, but obviuosly it checks both at runtime and thats how I ended without libreoffice too.
There could be a lot of reasons this is failing, it may just be a typo in the mesa code or it could be something much more involved. The usefulness of bisecting with git is to know exactly what this change is, then we will hopefully have a better idea of why its broken and who to contact with the bug report.
I reinstalled mesa-18.2.2-x86_64-1.txz for current and deleted ./config/libreoffice directory. And after a restart, now everything works OK. Must have been a corrupted package or something.
to orbea:
Thanks for pointing me how to bisect on git. I followed the instuctions and every package came out good. This was why I reinstalled current's mesa package, which upon a restart proved out to be good as well. I didn't understand that git bisect was a command and had to google it a bit. Anyway now I can do bisecting alright (as long as it is not a really complex and large package).
I resolved this by downgrading to an older version of Mesa (18.1*) where LibreOffice worked, and upgraded to latest again (18.2.3) and now Libre works again, with latest Mesa.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.