> On Jan 1, 2019, at 9:53 PM, m...@netbsd.org wrote: > >> 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)
Yes, I see your point and it's clear that I misunderstood what you were saying. But, the email I sent directly following addresses this situation. My suggested solution would be: Octave -> Octave JIT -> LLVM 1 | Mesa | LLVM2-but-with-renamed-symbols-that-only-Mesa-knows, so you'd have: LLVM1's someFunction(int x, int y) ...and... LLVM2's __Mesa_Private_LLVM_someFunction(int x) This could be done using the same mechanism by which we rename symbols in libc, or as a separate post-processing step similar to what librump does. > 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) ...also, it seems like the GNU-style symbol versioning support might be another way to solve this, yah? -- thorpej