Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src
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)
Home |
Main Index |
Thread Index |
Old Index