On Tue, Jan 01, 2019 at 05:45:31AM +0100, Kamil Rytarowski wrote:
> LLVM has no API/ABI stability contract and we are down to just keep
> syncing the headers and libraries with LLVM releases.
Can you explain this in more detail? Sounds like a no-go to me.
We provide abi compatibility, so does thi
On Tue, Jan 01, 2019 at 04:18:06AM +0100, Joerg Sonnenberger wrote:
> On Sat, Dec 29, 2018 at 08:48:37PM -0500, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Sun Dec 30 01:48:37 UTC 2018
> >
> > Modified Files:
> > src/libexec/ld.el
On Tue, Jan 01, 2019 at 04:49:57AM +0100, Thomas Klausner wrote:
> On Tue, Jan 01, 2019 at 04:13:57AM +0100, Joerg Sonnenberger wrote:
> > On Mon, Dec 31, 2018 at 07:33:08PM +, Maya Rashish wrote:
> > > Module Name: src
> > > Committed By: maya
> > > Date: Mon Dec 31 19:33:
On Tue, Jan 01, 2019 at 05:45:31AM +0100, Kamil Rytarowski wrote:
> Regarding usefulness, it's a step forward to reusing builtin toolchain
> for dependencies (xsrc, pkgsrc).
Installing headers alone is absolutely useless. You can't do anything
useful in that form. It's just wasting space.
Joerg
I'm stuck between the hammer and the anvil here.
I'd like NetBSD to use a recent MesaLib, the kind that uses LLVM.
I keep getting reports that r600.so isn't actually functional*, and
amdgpu would be even more noticeable.
I've done my best to improve support of MesaLib for modular xorg within
pkgsr
On Tue, Jan 01, 2019 at 02:22:54PM +, m...@netbsd.org wrote:
> I'm stuck between the hammer and the anvil here.
> I'd like NetBSD to use a recent MesaLib, the kind that uses LLVM.
Can you explain how the MesaLib build uses llvm?
This kinda sounds like you need a special build time binary that
On Tue, Jan 01, 2019 at 03:34:47PM +0100, Martin Husemann wrote:
> On Tue, Jan 01, 2019 at 02:22:54PM +, m...@netbsd.org wrote:
> > I'm stuck between the hammer and the anvil here.
> > I'd like NetBSD to use a recent MesaLib, the kind that uses LLVM.
>
> Can you explain how the MesaLib build u
> On Jan 1, 2019, at 6:34 AM, Martin Husemann wrote:
>
> Can you explain how the MesaLib build uses llvm?
>
> This kinda sounds like you need a special build time binary that would
> live in $TOOLDIR and it is not exactly clear how installing some headers
> helps building this tool (as you ca
m...@netbsd.org wrote:
>On Tue, Jan 01, 2019 at 03:34:47PM +0100, Martin Husemann wrote:
>> On Tue, Jan 01, 2019 at 02:22:54PM +, maya%netbsd.org@localhost wrote:
>> > I'm stuck between the hammer and the anvil here.
>> > I'd like NetBSD to use a recent MesaLib, the kind that uses LLVM.
>>
>
On Tue, Jan 01, 2019 at 04:02:01PM +, Robert Swindells wrote:
>
> m...@netbsd.org wrote:
> >On Tue, Jan 01, 2019 at 03:34:47PM +0100, Martin Husemann wrote:
> >> On Tue, Jan 01, 2019 at 02:22:54PM +, maya%netbsd.org@localhost wrote:
> >> > I'm stuck between the hammer and the anvil here.
>
Anyway, would static linking be good?
> On Jan 1, 2019, at 8:02 AM, Robert Swindells wrote:
>
> How does the usage of libLLVM from MesaLib make use of the LLVM headers
> at *runtime* ?
>
> If they are not needed at runtime then why do they need to be installed
> on a target machine ?
What's needed on the target machine are the L
On Tue, Jan 01, 2019 at 08:03:23AM -0800, Jason Thorpe wrote:
> LLVM is used in the graphics pipeline at run-time to generate native
> code that runs on the GPU.
Yeah (and to waste more than an additional hour in a full build of
NetBSD) - but then we need a working plan how to provide libllvm as
p
> On Jan 1, 2019, at 11:23 AM, Martin Husemann wrote:
>
> Yeah (and to waste more than an additional hour in a full build of
> NetBSD) - but then we need a working plan how to provide libllvm as
> part of the installed system, not only headers for building libmesa.
I'm not arguing the merits
m...@netbsd.org wrote:
>On Tue, Jan 01, 2019 at 04:02:01PM +, Robert Swindells wrote:
>> How does the usage of libLLVM from MesaLib make use of the LLVM headers
>> at *runtime* ?
>>
>> If they are not needed at runtime then why do they need to be installed
>> on a target machine ?
>
>it does
On Tue, Jan 01, 2019 at 09:45:03AM -0800, Jason Thorpe wrote:
>
>
> > On Jan 1, 2019, at 8:02 AM, Robert Swindells wrote:
> >
> > How does the usage of libLLVM from MesaLib make use of the LLVM headers
> > at *runtime* ?
> >
> > If they are not needed at runtime then why do they need to be ins
On 01.01.2019 14:33, Martin Husemann wrote:
> On Tue, Jan 01, 2019 at 05:45:31AM +0100, Kamil Rytarowski wrote:
>> LLVM has no API/ABI stability contract and we are down to just keep
>> syncing the headers and libraries with LLVM releases.
>
> Can you explain this in more detail? Sounds like a no-
On 01.01.2019 15:07, Joerg Sonnenberger wrote:
> On Tue, Jan 01, 2019 at 05:45:31AM +0100, Kamil Rytarowski wrote:
>> Regarding usefulness, it's a step forward to reusing builtin toolchain
>> for dependencies (xsrc, pkgsrc).
>
> Installing headers alone is absolutely useless. You can't do anything
On 01/01/2019 21:30, Kamil Rytarowski wrote:
Joerg seems to just want to play with Clang out of the LLVM projects,
deteriorating experience with the rest blocking this patch. Other people
need more than that.
I can see both sides here, and it seems that our repository is split the
same way - w
> Module Name: src
> Committed By: jnemeth
> Date: Tue Jan 1 01:52:40 UTC 2019
>
> Modified Files:
> src/sys/conf: copyright
>
> Log Message:
> Welcome to 2019!
Could you please send pullup requests for netbsd-7 and netbsd-8?
Thanks,
---
Izumi Tsutsui
On 02.01.2019 02:52, Roy Marples wrote:
> On 01/01/2019 21:30, Kamil Rytarowski wrote:
>> Joerg seems to just want to play with Clang out of the LLVM projects,
>> deteriorating experience with the rest blocking this patch. Other people
>> need more than that.
>
> I can see both sides here, and it
On Wed, 2 Jan 2019, Roy Marples wrote:
On 01/01/2019 21:30, Kamil Rytarowski wrote:
Joerg seems to just want to play with Clang out of the LLVM projects,
deteriorating experience with the rest blocking this patch. Other people
need more than that.
I can see both sides here, and it seems that
mrg@ wrote:
> Log Message:
> initial import of xorg-server-1.20.3
Is there some summary of API changes between 1.18 and 1.20?
I'm afraid this update also affects X68k server
in xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/
as the previous update (I'll also changes against Xnest).
Thanks,
I might be extrapolating, but AIUI:
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.
OpenSSL is similar in this regard: repl
On Wed, Jan 02, 2019 at 04:26:10AM +, m...@netbsd.org wrote:
> I might be extrapolating, but AIUI:
>
> 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 bit
thanks for cleaning up.
> - Provide missing cursor function
i would have done this by not doing it here but instead turning
off the #define in the relevant Makefile.
.mrg.
I'll note I don't know of a single package using LLVM and a library as
well as libGL, even though it looks like it should be a likely scenario.
The closest example was Octave that uses 3D graphs (with acceleration)
and at some opint had a LLVM-based JIT, but had given up on it because
it was an un
> 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'r
> On Jan 1, 2019, at 9:23 PM, m...@netbsd.org wrote:
>
> I'll note I don't know of a single package using LLVM and a library as
> well as libGL, even though it looks like it should be a likely scenario.
>
> The closest example was Octave that uses 3D graphs (with acceleration)
> and at some opi
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 th
> 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.
On Tue, Jan 01, 2019 at 10:30:38PM +0100, Kamil Rytarowski wrote:
> Joerg seems to just want to play with Clang out of the LLVM projects,
> deteriorating experience with the rest blocking this patch. Other people
> need more than that.
Can we please keep down on the ad hominem, thanks?
> > We pro
On Tue, Jan 01, 2019 at 10:07:11PM -0800, Jason Thorpe wrote:
>
> ...also, it seems like the GNU-style symbol versioning support might be
> another way to solve this, yah?
It would, if it wasn't (intentionally?) crippled down to the point of
useless. So yes, it seems like renaming all symbols wi
33 matches
Mail list logo
