On Mon, Mar 09, 2020 at 08:10:04PM -0400, Greg Troxel wrote:
> The package is /usr/pkgsrc/textproc/py-sphinxcontrib-serializinghtml
> which was recently updated to 1.1.4. The 1.1.3 tarball looks fine with
> NetBSD's /bin/tar but the 1.1.4 throws lots of:
I think this pkg needs:
EXTRACT_USING=bsd
On 10.03.2020 00:07, Greg Troxel wrote:
> Kamil Rytarowski writes:
>
>> On 09.03.2020 20:05, Martin Husemann wrote:
>>> This is pretty stupid, but IMHO no big deal. We can
>>>
>> [...]
>>> - just not support (i.e. #error) on older C++ standard compiles
>>
>> There are still many programs in pkgs
This is about a system with netbsd-8 built with sources updated on
2020-02-14.
I updated pkgsrc, and several sphinx packages are failing to build.
With help from adam@, I have narrowed it down to bad extraction from the
upstream tarball.
The package is /usr/pkgsrc/textproc/py-sphinxcontrib-serial
Kamil Rytarowski writes:
> On 09.03.2020 20:05, Martin Husemann wrote:
>> This is pretty stupid, but IMHO no big deal. We can
>>
> [...]
>> - just not support (i.e. #error) on older C++ standard compiles
>
> There are still many programs in pkgsrc that set older C++ release. Some
> of them are
We gotta obey the namespace; perhaps use __max_align_t in the headers and only
expose the real typedef for c++ > 98 or whatever.
christos
> On Mar 9, 2020, at 5:44 PM, Kamil Rytarowski wrote:
>
> On 09.03.2020 20:05, Martin Husemann wrote:
>> This is pretty stupid, but IMHO no big deal. We ca
On 09.03.2020 20:05, Martin Husemann wrote:
> This is pretty stupid, but IMHO no big deal. We can
>
[...]
> - just not support (i.e. #error) on older C++ standard compiles
There are still many programs in pkgsrc that set older C++ release. Some
of them are hard to upgrade.
$ git grep c++03|wc -
Michał Górny writes:
> Given that Clang defaults to C++14 nowadays, I suppose it could be fixed
> by finding old -std= and replacing it.
I am not really following the issue, but I don't understand why what the
default C++ sublanguage is matters. It would seem that behavior should
be correct for
On Mon, Mar 09, 2020 at 08:28:58PM +0100, Michał Górny wrote:
> To be honest, this is NetBSD-specific problem. Upstream has a fallback
> for other platforms but it was explicitly disabled on NetBSD (Kamil or
> Joerg will probably know why).
No, it is not a NetBSD-specific problem. Guys, please st
On Mon, Mar 09, 2020 at 08:28:58PM +0100, Micha? Górny wrote:
> ATF-C++ forces -std=gnu++98. We could remove that but then we fail
> on deprecated auto_ptr use.
We should fix that, independently of the issue at hand.
Martin
On Mon, 2020-03-09 at 20:05 +0100, Martin Husemann wrote:
> On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> > I am not really following the issue, but I don't understand why what the
> > default C++ sublanguage is matters. It would seem that behavior should
> > be correct for any --
On Mon, Mar 09, 2020 at 08:05:41PM +0100, Martin Husemann wrote:
> On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> > I am not really following the issue, but I don't understand why what the
> > default C++ sublanguage is matters. It would seem that behavior should
> > be correct for
On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> I am not really following the issue, but I don't understand why what the
> default C++ sublanguage is matters. It would seem that behavior should
> be correct for any --std passed to compilers, per that sublanguages's
> specification,
On Mon, 2020-03-09 at 13:23 +0100, Martin Husemann wrote:
> Stupid question: if that libc+++ is only designed to be C++11 and newer,
> in what real world scenarios does it require exposing max_align_t?
>
> For sure you can easily compile the libc++.so* itself with proper standard
> flags passed to
On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote:
> Upstream libc++ maintainers are against patching libc++.
I'm buffled how you are arriving at this conclusion. Let me reiterate:
STOP MESSING UP THE TREE.
Joerg
On Mon, 9 Mar 2020 13:16:58 +0100
Kamil Rytarowski wrote:
> Today unexposed max_align_t is the only blocker for importing modern
> libc++. We worked with Michal for over a year on making it working well
> and passing tests on NetBSD.
>
> I request to expose max_align_t to at least all C++ versio
On 26.02.2020 23:47, Kamil Rytarowski wrote:
> On 26.02.2020 14:49, Joerg Sonnenberger wrote:
>> On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote:
>>> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>>>
>>> It was introduced in C11/C++11, but in practice it
Stupid question: if that libc+++ is only designed to be C++11 and newer,
in what real world scenarios does it require exposing max_align_t?
For sure you can easily compile the libc++.so* itself with proper standard
flags passed to the compiler, so it must be something else - or I'm missing
somethi
17 matches
Mail list logo
