On Tue, Jan 01, 2019 at 09:38:10PM -0800, Jason Thorpe wrote: > > > > On Jan 1, 2019, at 8:26 PM, m...@netbsd.org wrote: > > > > Having two versions of LLVM in use by a binary is going to fail in > > surprising ways. > > > > Base can be several years old at some point, increasing the odds of the > > LLVM non-compatibility biting us. > > And libGL is very widely used. > > You're conflating two things that aren't related. Mesa's use of LLVM is > conceptually similar to the "Canadian cross", and at no point should the > compiler run-times of the "build", "host", or "target" systems ever > intermingle.
How come? If an arrow means dynamic linking, Octave -> Octave JIT -> LLVM 1 | Mesa | LLVM 2 LLVM1 has someFunction(int x, int y) LLVM2 has someFunction(int x) I'm under the impression that, due to the flat namespace, whether a call to someFunction works correctly depends on which symbol is picked up first, LLVM1's or LLVM2's. And, this applies to in-library calls in LLVM too. This does seem to be the case. if I load a WebGL thing, > pmap -p `pgrep firefox` |grep -i llvm 0000777D9FA00000 56024K read/exec /usr/pkg/lib/libLLVM-7.so 0000777DA30B6000 2044K /usr/pkg/lib/libLLVM-7.so .. Fortunately Firefox does not use LLVM twice in different ways, so failures don't happen. (Also the Octave scenario is not possible any more)
