texlive-bin will not build with -std=c++11

[gallafent]

I am experimenting with switching on C++11 for my macports builds, and so today I executed:

sudo port upgrade outdated configure.cxx_stdlib=libc++ configure.cxxflags=-std=c++11 \\
configure.macosx_deployment_target=10.7 configure.sdkroot=/Applications/Xcode.app/Contents/Developer/Platforms \\
/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk

Sadly, texlive-bin cannot withstand this set of build options. Build log attached.

The problem is some constants being declared which are too wide for the type designated to hold them!

[gallafent]

texlive-bin build log for failed build with c++11 switched on

[mojca (Mojca Miklavec)]

You can try to report this to the XeTeX issue tracker (even though it's not strictly XeTeX).

• ​http://sourceforge.net/p/xetex/bugs/

However, don't be surprized if other parts of the build will fail even if this gets fixed. A few months ago I tried CFLAGS=-std=c99/CFLAGS=-std=gnu99 and that failed to work for example (OK, I wasn't working on Mac, but nonetheless).

[mojca (Mojca Miklavec)]

Other that that I would say wontfix/upstreamissue. Unless it's fixed in upstream, it seems to be too much effort for the maintainer to hunt problems like this one.

Also, you should test users/dports/ports/tex. TL 2013 won't be patched any longer anyway.

[mojca (Mojca Miklavec)]

Can you please try the patch from ​http://tug.org/svn/texlive?view=revision&revision=34468 ?

[mojca (Mojca Miklavec)]

I new version of TECkit is going to be released soon and should fix all the problems. We just need to prepare a patch against TL 2014.

[mojca (Mojca Miklavec)]

The original changes to the repository can be seen here:

• ​http://scripts.sil.org/svn-view/teckit/TRUNK/

After three years of no activity they made 26 commits to their repository.

[mojca (Mojca Miklavec)]

The problem was most probably fixed upstream, both in the TECKit repository as well as in TeX Live trunk. The "problem" is that they also switched to the latest Unicode version and the diff is now nearly 1 MB long, so it's not really desirable to put it in SVN.

Dan, what's the strategy? Don't care, wait until TL 2014 and close it as 'wontfix'? Upload the complete 1 MB patch somewhere? Create a new zip for texlive-bin?

Now that we have a patch it would be nice to close this ticket either way.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

Dan, what's the strategy? Don't care, wait until TL 2014 and close it as 'wontfix'? Upload the complete 1 MB patch somewhere? Create a new zip for texlive-bin?

texlive-bin is currently at version 2014. Does that mean this issue has been resolved and we can close this ticket? texlive-bin does certainly build with libc++ on OS X 10.9 and later where that is the default; I have not tested using libc++ on OS X 10.8 or earlier.

[mojca (Mojca Miklavec)]

Sorry, I meant TL 2015 (which is going to be released relatively soon, but I'm not sure how long it will take to import it into MacPorts).

The bug report doesn't say that TL doesn't build against libc++. It only says that it doesn't build if one sets -std=c++11 manually. So the port is not really broken.

I haven't tested it recently, but even if it's still "broken" (it probably is) it should be fixed automagically when switching to TL 2015.

[mojca (Mojca Miklavec)]

Short opinion: given that no patch has been applied so far, given that the port isn't really broken and given that TL 2015 is almost out, it probably makes no sense to spend any effort into fixing this now and it will be fixed automatically when we upgrade to TL 2015. It's only a matter of taste whether we want to wait and only close the ticket once the switch to TL 2015 is actually done, or simply close the ticket now as "won't fix in TL 2014, fixed upstream, wait for TL 2015".

On the other hand there are a bunch of issues with TL 2015 that only manifest on Mac (when using system fonts in XeTeX). If anyone has extra time for testing and bug hunting before the release ...

[mojca (Mojca Miklavec)]

I'm blindly assuming that this has been fixed after upgrading to TL2015. In case I'm wrong, please reopen the ticket.