[Bug 207253] cad/openvsp: Fix in 11-CURRENT

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253

Raphael Kubo da Costa <rakuco at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fernando.apesteguia at gmail.c
                   |                            |om
 Attachment #167391|                            |maintainer-approval?(fernan
              Flags|                            |do.apesteguia at gmail.com)

--- Comment #13 from Raphael Kubo da Costa <rakuco at FreeBSD.org> ---
Created attachment 167391
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167391&action=edit
Enclose array in a namespace

(In reply to Dimitry Andric from comment #11) 
> Well, try to report this to libc++ upstream, and see what they say.  I don't
> much feel like hacking our local copy with some change that will conflict
> with whatever upstream is doing, let alone that we cannot do anything about
> the existing copies of libc++ out there.

OK. I was hoping you'd be willing to do that as it happened a few other times
in the past.

(In reply to fernando.apesteguia from comment #12)
> What strikes me is that the very same software works on FreeBSD 9.x and 10.x
> without issues
> (http://portsmon.freebsd.org/portoverview.py?category=cad&portname=openvsp).
> So something must have changed in libc++. I'm afraid we can break other
> software as stupid as they can be using names. I think it's worth having a
> look at what it changed around July 2015 that was when the port started
> failing.

What changed is that libc++ and the rest of clang/LLVM were updated to more
recent versions during that period, and these new versions introduced the
changes that are breaking OpenVSP.

> I'm working on the port of OpenVSP 3.0 but it requires the addition of other
> ports first and it will take a while. In the meantime I would rather compile
> OpenVSP with gcc as the patch purposes instead of working on a new patch for
> the code.

Please take a look at this patch I'm attaching. It builds fine on HEAD for me,
and doesn't force the use of GCC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.