[Solved] xorg-server-1.20.3:config fail: dri3proto not found

[redwood]

[Moderator edit: Changed title to try to attract relevant answers. Original title was xorg-server-1.20.3 with no further details. -Hu]

Am getting the following error when trying to upgrade xorg-server from 1.19.5-r2 to 1.20.3

Code: Select all

checking for PTHREAD_PRIO_INHERIT... yes
checking for pthread_setname_np(const char*)... no
checking for pthread_setname_np(pthread_t, const char*)... yes
checking for UDEV... yes
checking for udev_monitor_filter_add_match_tag... yes
checking for udev_enumerate_add_match_tag... yes
checking for DBUS... yes
checking for HAL... no
checking for glibc...... yes
checking for clock_gettime... yes
checking for a useful monotonic clock ...... yes
checking whether to track client ids... yes
checking for DRI2PROTO... yes
Checking temp dir /run/shm
Checking temp dir /var/tmp
checking for DRI3PROTO... no
configure: error: DRI3 requested, but dri3proto not found.

I've got x11-base/xorg-proto-2018.4, media-libs/mesa-18.2.8, x11-libs/libxcb-1.13.1

Also have got

Code: Select all

/usr/include/X11/extensions/dri3proto.h
/usr/include/xcb/dri3.h
/usr/include/xorg/dri3.h
/usr/lib/libxcb-dri3.so
/usr/lib/libxcb-dri3.so.0
/usr/lib/libxcb-dri3.so.0.0.0

Thanks for any ideas.

[Moderator edit: changed [quote] tags to [code] tags to preserve output layout. -Hu]

[Hu]

Usually, configure failures should print a message telling you to provide emerge --info, the configure log, and the build log. Please post your emerge --info inline and pastebin the configure log.

[Jaglover]

And, is x11-base/xorg-proto installed?

[fedeliallalinea]

If xorg-proto is the problem see viewtopic-t-1092564.html

[redwood]

Looks like I've accumulated quite a lot of cruft in /usr/lib/pkgconfig

Code: Select all

#> ls -l /usr/lib/pkgconfig|grep 20[0-9][0-9] | grep -v 2018 | grep -v 2017 | wc -l
#> 152

I removed /usr/lib/pkgconfig/dri3proto.pc and
then emerge of xorg-proto got through the failing DRI3proto test
but then it failed on randrproto config test
so I then removed /usr/lib/pkgconfig/randrproto.pc and
finally upgraded xorg-server to current stable version.

Am now running

Code: Select all

for f in /usr/lib/pkgconfig; equery belongs /usr/lib/pkgconfig/$f || echo "/usr/lib/pkgconfig/$f" > rmlist; done

Then will do a double check on the files not owned by any package:

Code: Select all

equery belongs $(<rmlist)

Then remove them:

Code: Select all

for f in $(< rmlist); do rm $f; done 

But there are 1500+ files in /usr/lib/pkgconfig so this will take a while.
If I were to run

Code: Select all

equery belongs $(ls /usr/lib/pkgconfig)

it would be faster, but equery doesn't output the files not owned by any package.

Once I get my system all upgraded, will then do a --depclean
Tried doing a --depclean earlier, but it wouldn't do it because xorg-server wasn't upgraded
which I couldn't upgrade because of cruft in /usr/lib/pkgconfig

[redwood]

Decided to make a list of files in /usr/lib/pkgconfig with timestamps older than 2017

Code: Select all

for f in $(ls -l /usr/lib/pkconfig |grep 20[0-9][0-9]|grep -v 2018); 
   do
       echo /usr/lib/pkgconfig/$f |grep ".pc" > pclist; 
   done

then remove them:

Code: Select all

equery belongs $(<pclist) || rm $(<pclist) 

[Hu]

Code: Select all

#> ls -l /usr/lib/pkgconfig|grep 20[0-9][0-9] | grep -v 2018 | grep -v 2017 | wc -l
#> 152

Code: Select all

find /usr/lib/pkgconfig/ \! -newermt 2018-01-01 | wc -l

Code: Select all

for f in /usr/lib/pkgconfig; equery belongs /usr/lib/pkgconfig/$f || echo "/usr/lib/pkgconfig/$f" > rmlist; done

This is a very expensive way to find the last such file. You probably want the redirect outside the loop, so that it is done once. As is, each time you echo a name, you reopen and truncate rmlist. Also, I think you lost a glob here. As written, you run the loop once with f given the value /usr/lib/pkgconfig, regardless of what files are in that directory.

Code: Select all

for f in $(< rmlist); do rm $f; done

Code: Select all

rm $(< rmlist)

Both are wrong in the presence of files with special characters in the name, though.

Code: Select all

$ echo 'a b' > f
$ printf '%s\n' $(< f)
a
b
$

Decided to make a list of files in /usr/lib/pkgconfig with timestamps older than 2017

Code: Select all

for f in $(ls -l /usr/lib/pkconfig |grep 20[0-9][0-9]|grep -v 2018); 
   do
       echo /usr/lib/pkgconfig/$f |grep ".pc" > pclist; 
   done

Never use ls to feed a script. Also, as written, you include files modified in 2017 and 2019, but your caption says you want only things from before 2017. This loop again truncates the result for each hit.

Code: Select all

find /usr/lib/pkgconfig \! -newermt 2017-01-01 -name \*\?pc\* > pclist

I matched your logic of accepting any filename consisting of a character followed by pc, anywhere in the filename. If you meant to match only at the end and require a literal dot, use -name \*.pc instead.

Code: Select all

$ echo npc | grep .pc
npc

[Leio]

Blindly removing pkgconfig files based on their timestamp sounds like a very bad idea and recipe for disaster, ending up having to rebuild packages to get necessary pkgconfig files back. At least check if something actually owns it or not before (with qfile tool or something)...

Is this a 32bit system or an amd64 with 17.0 profile? I'm asking because there's no emerge --info, and if it's a 17.1 amd64 profile, then just 32bit multilib stuff is being deleted here. I'm guessing though that /usr/lib is a symlink to /usr/lib64 and actually you are then deleting files from /usr/lib64 really, and should also check with that path with qfile, as it might not return anything when going through the symlink.

[redwood]

Thanks for the tips on my bash sripting, Hu. I like your solution using "\! -newermt " . As for the redirect ">", that was a typo -- should've been append ">>", and moving it outside the for loop would indeed be faster (but the for loop only took 10 or 15 seconds to run).

It was a quick & dirty script to pick out files in /usr/lib/pkgconfig older than a year ago. I saved the found filenames to a filelist "pclist" and looked and scrolled through the files for anything that looked weird. Afterwards I ran "equery belongs $(<pclist)" to find out if any of the files were owned by a package. If not, and only then, did I remove them "rm $(<pclist)" .

No, I wouldn't want someone to blindly try this out on their own system if they stumble upon this thread searching for a similar configure failure during an emerge.

Yes, Leio, this is an old x86_32 bit desktop system (an ancient AMD Athlon 64 X2 Dual Core Processor 4200+) that's been running Gentoo 24X7 since Nov 2006. Don't laugh. So far hasn't quit on me yet. Did max out the memory at 8G (with HIGHMEM kernel support) and replaced hardrives a couple times -- currently running on pair of black WD RE4 2TB drives in software raid. Did splurge once on a Hyper R MK II 880W power supply that's still going strong. No onboard video, but managed to squeeze in a long, double-wide bulky nvidia card.

Obviously not the fastest system by today's standards. Only getting 3GB/s out of my 6GB/s SATA drives. And similar bottlenecks with the bus system, memory, etc. If/when the MB or cpu fails, then I'll get a new system. Emerge'ing is slooow. Had thought about switching to a binary distro like gentoo-derivative Sabayon (but they no longer support 32bit). Maybe Fedora still supports 32bit (but who knows for how much longer?) Maybe a x86_32 Gentoo Reference System?

The system is fast enough for office work other than recent changes to KDE/qt5/kf5/akonadi which has made kmail unbareable and unusable. Ran mysqltuner to optimize akonadi but no real improvement. Was using kmail b/c it allowed simulataneous connection to multiple imap accounts to I could check email and move messages about easily and keep emails sorted into project folders for easy archiving. Currently have about 25G of emails all total in my imap accounts (including archive accounts) and kmail performance is just horrible. Not really sure if a faster computer would help or not. Webmail programs like roundcube/squirrelmail have no performance issues with the imap accounts (just can't easily move emails from one account to another other than forwarding). I've been blaming akonadi but maybe it's a glitch in kmail/kf/qt5 or a glitch in nvidia-drivers/xorg-servers. "emerge -uvDN world" is currently working on about 60 packages. Fingers crossed and hoping kmail/akonadi peformance improves.