On Sat, 2016-08-06 at 17:34 +0200, ⚛ wrote: > On Sat, Aug 6, 2016 at 4:32 PM, Jan Vesely <jan.ves...@rutgers.edu> > wrote: > > > > On Sat, 2016-08-06 at 13:00 +0200, ⚛ wrote: > > > > > > We could add a verifier to the build process that tests the > > > foo_dri.so > > > libraries (as well as all other libs subject to dlopen by Mesa) > > > for > > > undefined symbols: > > > > > > $ LD_PRELOAD=libGL.so ldd -d -r radeonsi_dri.so \ > > > | grep "^undefined" && echo "red alert!" > > > > > > This will ensure that Mesa does not break apps after replacing > > > all > > > RTLD_NOWs with RTLD_LAZY. > > > > > > I am going to start writing a new patch verifying relevant *.so > > > files > > > at buildtime. > > > > This won't help at all. the linking process already includes no- > > undefined flag, so the build will fail at linking stage if symbols > > can't be resolved. > > You are wrong about --no-undefined being used for *_dri.so. Grep your > Mesa build log for "-o .libs/gallium_dri.so" and then send an email > with your opinion please.
(ignoring the uncalled for display of arrogance) it does not change the fact that -Wl,--no-undefined is the tool to catch unresolved symbols, instead of introducing a custom tool. to be more constructive. The situation I'm concerned about is as follows: 1.) mesa builds fine using existing build environment. 2.) I update LLVM. This update changes symbols (function parameter changed type, a function was moved to header, or devirtualization pass did a better job, ...) I want to know whether this happened and mesa rebuild is necessary. surely most llvm symbols are used immediately, but if optimizations like shader cache are present it can take some time before the compiler path is exercised, postponing failed symbol lookups well into the future. Jan > > > > > RTLD_NOW detects bugs in deployment. IMO it's preferable if DE > > fails to > > start instead of crashing hours into work. sure I can set > > LD_BIND_NOW > > env var, but there are programs that have much stronger case for > > using > > lazy binding (like LO) that would be negatively affected. > > > > shaving 6M instructions does not seem like strong enough benefit to > > justify this. -- Jan Vesely <jan.ves...@rutgers.edu>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
