Comment 1 Johannes Jost Meixner 2014-04-11 07:41:25 UTC

Responsible Changed
From-To: freebsd-ports-bugs->xmj

I'll take it.

Please see attached the update to 1.1.4 with a rc script.

Comment 3 Johannes Jost Meixner 2015-05-25 03:01:23 UTC

Back to pool.

Note, this doesn't build well on FreeBSD <10 due to C++11 stuff.

Comment 4 Kubilay Kocak 2015-05-25 03:36:05 UTC

Maintainer,

Please provide an updated patch addressing build failures or FreeBSD versions < 10, or an updated patch setting the port as BROKEN on OSVERSIONS < 10.

If you could also include QA results (poudriere testport, portlint -AC) results as attachments once the above changes have been made, that would be great.

xmj@, if you could provide any additional detail for how to resolve this issue, please do so.

Hello,

The problem is that all GCC versions are broken on FreeBSD. Looks, even gcc 4.9 can not compile a sample C++11 code :

markand@Pomme ~ $ cat test.cpp
#include <string>

int main(void)
{
        std::to_string(1);
        std::stoi("1");

        return 0;
}
markand@Pomme ~ $ g++49 -std=c++11 test.cpp
test.cpp: In function 'int main()':
test.cpp:5:2: error: 'to_string' is not a member of 'std'
  std::to_string(1);
  ^
test.cpp:6:2: error: 'stoi' is not a member of 'std'
  std::stoi("1");
  ^

I have told to bapt@ that the compiler:c++11-lib and compiler:c++11-lang do not work at all but I don't think he really cares. Maybe because the problem comes from gcc.

So the only way to make irccd compile is to either: use plain clang (default in FreeBSD 10.0) or to install clang + libc++ from ports for <10.0. Which violates the rule of not overriding CXX and CC in the port's makefile. So at the moment, I think I have no solution except giving up on this port unless someone fixes the compiler:c++11-(lib|lang) and/or gcc on FreeBSD.

Comment 6 Kubilay Kocak 2015-05-26 10:32:35 UTC

CC'ing portmgr and gerald (GCC port maintainer) to escalate and advise on comment 5 please

Comment 7 Gerald Pfeifer 2015-06-05 11:46:41 UTC

As for C++14 (or C++11) support, this requires some more work both on
the FreeBSD side and GCC, as Andreas Tobler who kindly is looking into
this has found.

As Andreas wrote in PR:

  "Given the results of my studies it needs some work. On both sides,
  the gcc part needs to be improved regarding detection of functionality 
  and on the FreeBSD part we're still lacking some complex functions
  in libm."

Now I am wondering, Andreas: would it make sense to fake/force C++14
mode for GCC on FreeBSD, even when some fringe functionality may not
be working yet?  I guess what 99% of apps and users need, should be
there today.

Comment 8 John Marino 2015-07-09 11:13:43 UTC

I would just write off FreeBSD 8 and 9 [1]
I did exactly this on graphics/copperspice.

Fixing this correctly requires backporting libm changes from FreeBSD 10 and I don't that's going to happen.

[1] FreeBSD 8 should already be EOL but the date was extended to end of August 2015, so the real loss is "only" FreeBSD 9.

Comment 9 Carlo Strub 2015-09-15 22:30:39 UTC

would you mind updating your patch please

Comment 10 Kubilay Kocak 2016-01-30 07:11:32 UTC

@Mark, please feel free re-open this issue if and when you can provide an updated changeset (patch)

Comment 11 Bryan Drewery 2016-03-17 15:33:58 UTC

I'm working with reporter/author.

Created attachment 183741 [details]
new version

Here an updated version with rc file.

Comment 13 Tobias Kortkamp 2019-01-27 07:50:56 UTC

Can somebody please tell me what we should do with this bug?
Even David's patch is now outdated.

I'm gonna release a major version of the project this year so perhaps we can delete close this PR for the moment.