cuneiform: character too large for enclosing character literal type

[benjamin_steinberg@…]

I'm running Mac OS X 10.8.2 and XCode 4.5.1 (4G1004) -- cuneiform build fails. I'll attach /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_textproc_cuneiform/cuneiform/main.log

The errors are "character too large for enclosing character literal type" -- I wonder if the strings in question need to be prefixed with an L, something like this:

​https://github.com/TheLevelUp/ZXingObjC/issues/3

though that might be an issue for upstream. However, I see other people have obviously built this version of cuneiform: #33708

[ryandesign (Ryan Carsten Schmidt)]

This was not a clean build attempt. Please "sudo port clean cuneiform", then try again, then attach the new main.log file.

[ryandesign (Ryan Carsten Schmidt)]

Actually I was able to reproduce the problem on my system (also 10.8.2 and Xcode 4.5.1) so I attached my main.log.

[ryandesign (Ryan Carsten Schmidt)]

Replying to benjamin_steinberg@…:

The errors are "character too large for enclosing character literal type" -- I wonder if the strings in question need to be prefixed with an L, something like this:

​https://github.com/TheLevelUp/ZXingObjC/issues/3

though that might be an issue for upstream.

Indeed please report the problem to the developers so that they can fix it. I'm not a C programmer and don't understand the significance of prefixing a string with "L" so I don't feel comfortable making that change on my own.

However, I see other people have obviously built this version of cuneiform: #33708

Yes but that's on Lion, which is a different OS. They're probably also using a different version of Xcode, which means a different version of clang, or if Xcode < 4.2, then they wouldn't even have been using clang; they'd've been using llvm-gcc-4.2.

On the hunch that this, like so many other problems we've seen, is because clang is a bit different, I tried blacklisting it and using llvm-gcc-4.2 instead. That worked, so I committed that workaround in r98766.

[ryandesign (Ryan Carsten Schmidt)]

Fixed properly in r136891, using the same fix FreeBSD used, which is indeed simply to prefix the string with L as you had suggested.