Aaron Plattner wrote: >> Can you test with a install of the current X Server git master, and >> check what symbols are missing if any? Just use the script attached. > > Nifty script! I took the liberty of making it print out the paths so I > could make sure it was picking up the right binaries.
Thanks. You could also use the -f option, to print full pathnames :-) > At first, the build didn't work because I configure my build directory > with > > $ /home/aaron/X/modular/xserver/configure --prefix=/X ... > > and all of my include paths start with "/home/aaron/X/modular/xserver", > resulting in an empty xorg_symbols array. Then, instead of failing to > build, it produced an X server that did this: > > dlopen: /X/lib/xorg/modules/extensions//libextmod.so: undefined > symbol: XvScreenInitProc > (EE) Failed to load /X/lib/xorg/modules/extensions//libextmod.so > (EE) Failed to load module "extmod" (loader failed, 7) > (EE) Failed to load module "dri" (module does not exist, 0) > X: symbol lookup error: /X/lib/xorg/modules//libint10.so: undefined > symbol: xf86ReadBIOS That is strange. I think this could happen only if for some reason the cpp output was listing full pathnames, as the script logic is very simple, it only processes output generated from headers in a relative pathname. The script is used just to prevent this. If those symbols are not referenced, the linker may drop them, as there is no code path inside the X Server that access them. > It would be nice if sdksyms.sh could cause the build to fail if it finds > no > symbols. Also, the rule to build sdksyms.c needs a dependency on > sdksyms.sh and all of the headers that it includes. Otherwise, someone > will change the SDK and then wonder why his new symbol doesn't show up > because xorg_symbols is stale. A complete build should always work correctly. But it probably should be extended to check after the X Server is linked, that those symbols are found by dlsym. > Once I got the build to generate sdksyms.c correctly, the resulting server > worked fine. > The NVIDIA driver doesn't use wfbrename.h itself, but it relies on > libwfb.so not defining any [^w]fb symbols that will clash with ones from > libfb.so. From a quick skim of your nifty script's output, it looks like > all of libwfb.so's exported symbols are properly prefixed with "wfb", so I > think it's okay. There are probably some symbols in wfbrename.h that have > disappeared from the source, though, and can be removed. (Note that it > needs to rename everything exported when -fvisibility=hidden is disabled, > too). Another test I forgot to ask, please also check that symbols accessed using dlsym or LoaderSymbol are also exported. The script cannot find those. But just a grep for dlsym or LoaderSymbol in the source should tell what symbols may still fail. Paulo _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
