Re: CVS commit: src

[maya%netbsd.org@localhost]

On Tue, Jan 01, 2019 at 09:38:10PM -0800, Jason Thorpe wrote:
> 
> 
> > On Jan 1, 2019, at 8:26 PM, maya%netbsd.org@localhost 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)