Tag: glibc

Gentoo update tips when updating packages with blocks and masked files

It’s not so rear to have

blocks or masked files

when using Gentoo emerge system, but it is not complex and in most cases it is easy to resolve

To summarize it up at the beginning and then we are going to show you other articles using these advises here where you’ll see what are the steps we took to resolve the conflicts and masked packages:

  • Use verbose,verbose-conflicts and backtrack with emerge
  • Remove only big GUI packages, which have really big dependency graph like office suites or development IDEs
  • Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!
  • Do not update everything with one line, you could update only the base libraries like QT, which are very important for the Linux GUI in general
  • Include explicitly packages, which block our updates in the emerge line! You could specify packages with the versions.
  • use tools like “equery” (part of app-portage/gentoolkit) for checking dependencies and/or which packages depend on the queried package. You can use it with specific version for the package. “qlist” (part of app-portage/portage-utils) also is a handful tool.
  • Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.
  • In rear cases you can use “–nodeps” when updating or installing a new package (we do not need and show this one here!)
  • Do NOT rebuild the entire system with “emerge -v world” every time when you rebuild glibc, gcc, it is not mandatory to do it to have a healthy system.
  • Add or remove USE flags if needed – emerge will show you information about it. Use package.use, package.mask, package.unmask and so on.
  • use qlist to update/re(build) to pull currently installed packages with some name or category (categories) 
    emerge -v $(qlist -IC|grep <NAME>)

    and for update just add “u” to “-v”:

    emerge -vu $(qlist -IC|grep <NAME>)

Keep on reading!

glibc 2.26 and failure to compile because of xlocale.h

Since release of glibc 2.26 there is no xlocale.h file any more, because there was never intended to be as separate file! According to the Release notes of glibc 2.26 this file

was a strict subset of the standard header locale.h

Apparently this file had had to be used only internally for the glibc, but many programs used it directly and now they fail to compile with:

In file included from /usr/include/mlt/framework/mlt_animation.h:27:0,
                    from /usr/include/mlt/framework/mlt.h:39,
                    from /usr/include/mlt++/MltAnimation.h:26,
                    from /usr/include/mlt++/Mlt.h:24,
                    from /var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1/thumbnailer/mltpreview.h:2 ,
                    from /var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1/thumbnailer/mltpreview.cpp:21:
    /usr/include/mlt/framework/mlt_property.h:34:10: fatal error: xlocale.h: No such file or directory
    #include <xlocale.h>
            ^~~~~~~~~~~
    compilation terminated.
    distcc[19778] ERROR: compile /var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1/thumbnailer/mltpreview.cpp on localhost failed
    make[2]: *** [thumbnailer/CMakeFiles/mltpreview.dir/build.make:63: thumbnailer/CMakeFiles/mltpreview.dir/mltpreview.cpp.o] Error 1
    make[2]: Leaving directory '/var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1_build'
    make[1]: *** [CMakeFiles/Makefile2:1434: thumbnailer/CMakeFiles/mltpreview.dir/all] Error 2
    make[1]: *** Waiting for unfinished jobs....
    make[2]: Leaving directory '/var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1_build'
    make -f renderer/CMakeFiles/kdenlive_render.dir/build.make renderer/CMakeFiles/kdenlive_render.dir/build
    make[2]: Entering directory '/var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1_build'

The above output is from a Gentoo linux distro trying to compile the kde-apps/kdenlive (kde-apps/kdenlive-17.12.1), but it is a known fact that many programs used the file and you may see another program to fail with the same or similar compilation error. You may encounter such errors when compiling perl or perl modules.
The workaround till the maintainer (if the project is alive, of course) fixes it is so simple, just link the missing file with a symbolic link:

ln -s /usr/include/locale.h /usr/include/xlocale.h