Created attachment 120119 [details] Check_elf_files: little help script to find unused libraries or undefined symbols Running ROSA 2014.1 R6 on x86_64, with a Radeon HD5750 video card. For the above distribution I routinely build updated packages of libdrm, pixman, Mesa, xserver and related libraries and drivers and test them on my pc. The latest for xserver I tried was the stable release 1.17.4. The Rosa build system has a little helper script for finding and warning about linking references to unused libraries and/or the presence of undefined symbols (attached below). By looking at the build log (also attached below) I noticed the presence of really many undefined symbols in the xserver modules: from libexe.so, libfb.so, libfbdevhw.so, libglamoregl.so, libglx.so, libint10.so, libshadow.so, libshadowfb.so, libvbe.so, libvgahw.so and libwfb.so; also the in-tree modesetting driver shows a similar problem. Usually the warnings seem to be harmless, but not always: see the bug# 93105. By inspecting the resulting binaries after a build I can see that, eg: libshadow.so undefined symbols are actually provided by $(srcdir)/fb/libfb.{a|la}, $(srcdir)/miext/damage/libdamage.{a|la} and $(srcdir)/dix/libdix.{a|la}. It looks like the building process is really underlinking the above xerver modules. IIRC our Rosa packages have similar warnings at least since release 1.16.0 (or perhaps also since 1.15.0), so: what is wrong here? Our build system or there is really some problem with the sources?
Created attachment 120120 [details] Build log of xserver 1.17.4, showing warnings aboud undefined symbols
The problem is mainly that you are expecting things that Xorg does not do. While improving our linking has been discussed on the xorg-devel mailing list from time to time, and some improvements have been made, it's not finished, and due to the number of symbols which have to be resolved against the Xorg binary, is difficult to finish on some platforms. Unfortunately, since what Xorg does works, even if it's not ideal, there's not been a lot of motivation to resolve it once and for all, and the platforms which do want it (like the Cygwin build & Solaris) have made it work for them, but not for other platforms like Linux.
OK. But I was bitten at runtime by a couple of undefined symbols: see bug# 93105. So I'm not sure that "what Xorg does works"... Anyway: there is a way to at least improve a little the situation? Let's pick an example: libglamoregl ***************** Warning: undefined symbols in /usr/lib64/xorg/modules/libglamoregl.so: serverClient lastGLContext screenInfo serverGeneration RegionEmptyData PictureScreenPrivateKeyRec PixmapWidthPaddingInfo RegionEmptyBox miChangeGC miCopyGC miChangeClip miDestroyClip miCopyClip miPolyRectangle miPolyArc miFillPolygon miPolyFillArc miImageGlyphBlt RegionAppend AllocateFontPrivateIndex miDoCopy miPolyGlyphBlt miImageGlyphBlt RegionDestroy fbComposite LogMessageVerb fbGetImage pixman_rasterize_trapezoid ValidatePicture xf86Msg fbGetSpans miPolyPoint fbAddTraps miSyncShmScreenInit ValidateGC miImageText8 fbDestroyPixmap miPolyText16 fbCopy1toN miSyncGetScreenFuncs dixRegisterPrivateKey fbGetScreenPrivateKey XNFasprintf RegionCreate miCompositeRects GetScratchGC FreeScratchGC fbValidateGC pixman_region_rectangles pixman_region_contains_rectangle CreatePicture miCreatePicture miImageText16 miDestroyPicture pixman_image_unref ChangeGC pixman_region_init_rects fb24_32ReformatTile pixman_region_extents miPushPixels fbCopyNtoN xf86AllocateScrnInfoPrivateIndex PictureMatchFormat fbCreatePixmap fbCreateGC pixman_region_union fbTriangles pixman_region_init_with_extents miHandleExposures fbPolySegment xf86ScreenToScrn pixman_region_contains_point fbSetSpans RegionValidate miPolyText8 MakeAtom FatalError xf86DrvMsg DamageDestroy dri3_screen_init fbPadPixmap pixman_region_intersect _FontSetNewPrivate pixman_image_create_bits XNFalloc pixman_f_transform_point DamageDamageRegion DamageRegionAppend miComputeCompositeRegion fbPolyFillRect LogMessage CompositePicture pixman_transform_is_int_translate pixman_f_transform_from_pixman_transform miRenderColorToPixel XNFstrdup pixman_region_copy pixman_image_get_data DamageRegionProcessPending pixman_image_composite DamageRegister FreePicture miCopyRegion CreateSolidPicture fbCopyNto1 pixman_region_subtract pixman_region_translate XNFvasprintf DamageUnregister pixman_region_init miPolySegment miPolylines fbFillSpans dixGetGlyphs pixman_region_fini fbPixmapToRegion fbPutImage miTrapezoidBounds miDestroyGC ErrorF DamageCreate ***************** I did for libglamoregl the same thing I wrote about above (for libshadow) and ended up with a little patch to force the link against libfb (see https://bugs.freedesktop.org/show_bug.cgi?id=93105#c2) and so avoid the runtime failure I was getting at the server startup: actually my patch does kill all the fbXXXX undefined symbol warnings and makes glamor to work, but it also causes many more miXXXX undefined symbol warnings than before. So something is still not right (linking order perhaps?) Given that: 1) to solve the warnings it libglamoregl AFAICT it also need to explicitly link to at least render/librender, miext/damage/libdamage, dix/libdix, dri3/libdri3, os/libos, hw/xfree86/common/libcommon, perhaps also to libpixman-1 (for the pixman_XXXXX symbols) and a bunch more that I was not able to find were they are provided... 2) I'm not really fond of the inner working of the xserver sources... There is a way to lower the chances of getting runtime errors "à la" bug# 93105, by reducing the overall number of undefined symbols in libglamoregl? I would like to help doing so, but have little clues about how do it... Ditto for the other modules...
Symbols in loadables that call up to the server are not errors. It might be unfortunate that ELF doesn't have a way to express intent there, but it's how X has worked for decades (and many other programs, for longer).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.