x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -o xdg-user-dirs-gtk-update parse.o update.o -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libudev.so.0, needed by /usr/lib64/libEGL.so.1, not found (try using -rpath or -rpath-link) /usr/lib64/libEGL.so.1: undefined reference to `udev_device_get_devnode' /usr/lib64/libEGL.so.1: undefined reference to `udev_device_get_parent' /usr/lib64/libEGL.so.1: undefined reference to `udev_device_unref' /usr/lib64/libEGL.so.1: undefined reference to `udev_device_get_property_value' /usr/lib64/libEGL.so.1: undefined reference to `udev_device_new_from_devnum' /usr/lib64/libEGL.so.1: undefined reference to `udev_unref' /usr/lib64/libEGL.so.1: undefined reference to `udev_new' collect2: ld returned 1 exit status make[2]: *** [xdg-user-dirs-gtk-update] Error 1 I can provide more information if requested but this looks pretty obviously like a missing dep to me.
> libudev.so.0, needed by /usr/lib64/libEGL.so.1, not found libEGL is part of mesa. Why was this assigned to xdg-user-dirs maintainers?
Looks like you forgot to run revdep-rebuild after updating udev:ç
*** Bug 454188 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Looks like you forgot to run revdep-rebuild after updating udev:ç it's a catalyst run, there has never been an update, only initial installs
(In reply to comment #1) > > libudev.so.0, needed by /usr/lib64/libEGL.so.1, not found > > libEGL is part of mesa. Why was this assigned to xdg-user-dirs maintainers? Honestly because when I ran "qfile /usr/lib64/libEGL.so.1" on my host system I didn't get any output so I assigned it where it fails in the hopes that the maintainer knew better :-) Thanks for knowing better.
/usr/lib64/libEGL.so.1 is a symlink which is managed by eselect opengl
emerge -1 mesa revdep-rebuild --library libudev.so.0 or otherway around either way, doesn't look like a bug, looks like some of the postinst messages was nor read
(In reply to comment #7) > emerge -1 mesa > revdep-rebuild --library libudev.so.0 > > or otherway around > > either way, doesn't look like a bug, looks like some of the postinst > messages was nor read This is a catalyst build, nothing was updated, ever. this is not user error, it is not even possible to be user error. Something else is wrong. I can't run revdep-rebuild in the middle of a catalyst run.
It appears that what happened is this: seed stage has udev-171 stage 1 builds mesa, links mesa against udev-171 even though udev-197-r3 is later installed in the chroot (so mesa is broken) How do we fix it when a .so version changes like that? nothing in stage2 or stage3 seems to handle that properly... In stage2 or 3 we should really "emerge -e @system", or at least revdep-rebuild... Thoughts from the team?
> In stage2 or 3 we should really "emerge -e @system", or at least > revdep-rebuild... stage3 seems to pretty much only be "emerge -e @system" and this was still broken... maybe we need a revdep-rebuild in there to see wtf is happening?
building mesa in stage1 looks like misunderstanding of what "stage1" is.
The problem is also in mesa which links against udev when r600, radeonsi or nouveau are enabled. But the dependencies don't reflect that yet. A way to solve the udev upgrade problem might be EAPI=5 sub-slotting.
in stage1 all dependenices are (except only specific ones) ignored, building mesa in stage1 is beyond any sense.
I didn't post last night because it was late when I finished testing but I found the issue. Here is what is happening: Catalyst stage1 begins with an "update_seed" which updates gcc and all it's deep dependencies. On my profile, this includes mesa because I have significantly more use flags enabled than gentoo's desktop profile. At this time, a binpkg is made of mesa, because udev-171 is on the seed stage, mesa is linked to udev-171 Stage1 and stage2 builds as expected, no problems or bad linkings. When stage3 is built, mesa is called in as part of my system set (again, remember my profile is significantly needier than gentoo desktop) and the mesa binpkg from "update_seed" is used to satisfy this install. The problem here is that the "update_seed" part of stage1 run should NOT be building binpkgs. "update_seed" is meant to update the seed to prevent this kind of bad linking issue but as long as we are not updating the entire seed stage we cannot trust the binpkgs to use later in the build. The solution to this is almost certainly to add --buildpkg=n to the update_seed lines, but I'll be testing that later today and committing the fix.
(In reply to comment #14) > I didn't post last night because it was late when I finished testing but I > found the issue. > > Here is what is happening: > > Catalyst stage1 begins with an "update_seed" which updates gcc and all it's > deep dependencies. On my profile, this includes mesa because I have > significantly more use flags enabled than gentoo's desktop profile. At this > time, a binpkg is made of mesa, because udev-171 is on the seed stage, mesa > is linked to udev-171 > > Stage1 and stage2 builds as expected, no problems or bad linkings. > > When stage3 is built, mesa is called in as part of my system set (again, > remember my profile is significantly needier than gentoo desktop) and the > mesa binpkg from "update_seed" is used to satisfy this install. > > The problem here is that the "update_seed" part of stage1 run should NOT be > building binpkgs. "update_seed" is meant to update the seed to prevent this > kind of bad linking issue but as long as we are not updating the entire seed > stage we cannot trust the binpkgs to use later in the build. > > The solution to this is almost certainly to add --buildpkg=n to the > update_seed lines, but I'll be testing that later today and committing the > fix. As I told Rick yesterday and he confirmed here, he should be updating @world on his update_seed. As an alternative, and probably an easier solution, he should probably move some of his stuff to a stage4 and use the stage3 as the seed for his builds.
> As I told Rick yesterday and he confirmed here, he should be updating @world > on his update_seed. As an alternative, and probably an easier solution, he > should probably move some of his stuff to a stage4 and use the stage3 as the > seed for his builds. The defaults in catalyst are not to update world, it is possible for this to happen with a .so version bump in another package (maybe file since it is in the default stage builds). To protect users from this issue we really should do one of two possible options (that I can think of): 1.) Make the default to update the entire @world on the stage and tell users that not doing that isn't supported 2.) don't make binpkgs in the update_seed part of the stage. I would seem to me there is almost no downside of option 2, and almost no one will be able to tell the difference as it will have no effect on people using the default gentoo base or desktop profiles. Can we please add --buildpkg=n to the update_seed command? If approved I'll write and test the change.
Solved in commit e7ea409acb52b43e9ea141c57201f9f87673f7ba by passing "--buildpkg=n" during update_seed
While Zero_Chaos' fix avoids the issue for catalyst stage1s, it can still bite folks using mesa binary packages in other contexts. Since both udev and mesa use EAPI-5 ebuilds, we should fix this the right way by adding an ABI-sub-slot declaration to the udev ebuild and a sub-slotted dependency to the mesa ebuild. Another benefit of informing Portage of the dependency would be that you'd no longer need to revdep-rebuild after changes. For more background, see http://thread.gmane.org/gmane.linux.gentoo.devel/80705/focus=84964
(In reply to comment #18) > While Zero_Chaos' fix avoids the issue for catalyst stage1s, it can still > bite folks using mesa binary packages in other contexts. Since both udev > and mesa use EAPI-5 ebuilds, we should fix this the right way by adding an > ABI-sub-slot declaration to the udev ebuild and a sub-slotted dependency to > the mesa ebuild. Another benefit of informing Portage of the dependency > would be that you'd no longer need to revdep-rebuild after changes. > > For more background, see > http://thread.gmane.org/gmane.linux.gentoo.devel/80705/focus=84964 I would be happy to push this for you as hard as I can, but I would need a suggested changeset as using subslots requires modifying the both the atom and the depend ebuilds typically. I'm a bit crazed at the moment honestly and as my builds are still running I'm not likely to find the time to write it myself.
(In reply to comment #19) > I would be happy to push this for you as hard as I can, but I would need a > suggested changeset as using subslots requires modifying the both the atom > and the depend ebuilds typically. The udev ebuilds are complicated ;). I've opened a bug for the first stage of this, which will be adding ABI sub-slots to sys-fs/udev [1]. After that we'll probably have to tweak virtual/udev before we can mess with media-libs/mesa. [1]: https://bugs.gentoo.org/show_bug.cgi?id=466162
