One of goals for the toolchain prior to the FreeBSD 11 branch is to
create a libllvm.so and libclang.so for use by all of the LLVM family
tools installed in the base system. This message is just a heads-up in
case anyone has questions or comments on the idea.
We currently build a large number of s
Hi Ed,
Please can we have a name other than libclang, to avoid name collisions and
confusion with, uh, libclang? libcfe maybe?
David
On 16 Dec 2014, at 15:46, Ed Maste wrote:
> One of goals for the toolchain prior to the FreeBSD 11 branch is to
> create a libllvm.so and libclang.so for use b
On 16 Dec 2014, at 16:58, David Chisnall wrote:
> On 16 Dec 2014, at 15:46, Ed Maste wrote:
>> One of goals for the toolchain prior to the FreeBSD 11 branch is to
>> create a libllvm.so and libclang.so for use by all of the LLVM family
>> tools installed in the base system. This message is just a
On 16 Dec 2014, at 16:04, Dimitry Andric wrote:
> This is precisely why the libs should go into /usr/lib/private, so as to
> avoid collisions with any upstream libraries installed by e.g. ports (or
> when you manually run "make install" after building).
That's still potentially an issue if we ad
On 16 Dec 2014, at 17:15, David Chisnall wrote:
>
> On 16 Dec 2014, at 16:04, Dimitry Andric wrote:
>> This is precisely why the libs should go into /usr/lib/private, so as to
>> avoid collisions with any upstream libraries installed by e.g. ports (or
>> when you manually run "make install" afte
> On Dec 16, 2014, at 9:32 AM, Dimitry Andric wrote:
>
> On 16 Dec 2014, at 17:15, David Chisnall wrote:
>>
>> On 16 Dec 2014, at 16:04, Dimitry Andric wrote:
>>> This is precisely why the libs should go into /usr/lib/private, so as to
>>> avoid collisions with any upstream libraries installe
On 16 December 2014 at 11:15, David Chisnall wrote:
>
> Upstream doesn't call it libclang (that's the name of the library with a
> stable C ABI, which is why I'd like us not to confuse it with something with
> a library with an unstable C++ API). They do produce a libLLVM.so from the
> LLVM bui
On 16 December 2014 at 12:39, Warner Losh wrote:
>
> We should defer testing until after that import :)
Indeed. I have an early WIP patch in a local branch, but any new work
before 3.5.x lands will be wasted, so it will be in the new year that
I'll have something to start testing.
___
> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote:
>
> Fair enough, I'd definitely like to see fewer build-time knobs over
> time, not more.
Until we stop using build-time knobs to control what’s in the final image
as a poor man’s packaging scheme, I expect the number of knobs to
continue to grow.
On 16 Dec 2014, at 18:54, Warner Losh wrote:
>
>> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote:
>>
>> Fair enough, I'd definitely like to see fewer build-time knobs over
>> time, not more.
>
> Until we stop using build-time knobs to control what’s in the final image
> as a poor man’s packaging
On 28 Nov 2014, at 22:03, Dimitry Andric wrote:
>
> We're working on updating llvm, clang and lldb to 3.5.0 in head. This
> is quite a big update again, and any help with testing is appreciated.
>
> To try this out, ensure you have good backups or snapshots, then build
> world and kernel from t
> On Dec 16, 2014, at 12:01 PM, Dimitry Andric wrote:
>
> On 16 Dec 2014, at 18:54, Warner Losh wrote:
>>
>>> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote:
>>>
>>> Fair enough, I'd definitely like to see fewer build-time knobs over
>>> time, not more.
>>
>> Until we stop using build-time kn
On 16 December 2014 at 14:47, Warner Losh wrote:
>
> My comment was
> more to Ed’s notion that these numbers will be dropping any time soon.
To be clear, I don't expect we'll be dropping knobs soon. We should
keep that as a goal to aim for.
___
freebsd-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/16/2014 14:36, Dimitry Andric wrote:
> * The second exp-run had much better results: the failure with the
> highest number of dependencies is devel/mingw32-gcc, but this
> seems to be due to a problem with makeinfo, not clang. The next
> high
emaste updated the summary for this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1327
To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe,
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.
REVISION SUMMARY
When asked to strip a specific symbol (-N) strip still defaulted to
STRIP_ALL. In this case binutils defaults to stripping nothing (other than the
requested symbol(s), of course), which makes a lot mor
imp added a subscriber: imp.
imp accepted this revision.
imp added a reviewer: imp.
imp added a comment.
This revision is now accepted and ready to land.
Looks good to me.
REVISION DETAIL
https://reviews.freebsd.org/D1327
To: emaste, imp
Cc: imp, freebsd-toolchain
_
17 matches
Mail list logo
