I had to upgrade xcode today, if I wanted to try to get my iOS project submitted to Apple. However, now my Mac version, which was working, won’t build. I get two errors:
No matching function for call to ‘iconv_close’
No matching function for call to ‘iconv’
I found another thread () and tried both adding -liconv and tried adding libiconv to the “link binary with libraries” section, but still get the error.
I’ve googled this, and it sounds like a build issue, but I didn’t change anything in my project. I guess the new xcode may be doing this?
Does anyone know enough about iconv and xcode to offer a suggestion?
[UPDATE] Ok, I know this sounds very risky, but both calls to iconv() and iconv_close() are in CCFontAtlas, which I don’t use. Since I can’t build with those calls, I’ve commented them out, and so far, everything is running fine. I’m getting my text (CCLabel), and my UIEditBox is working fine.
I think it’s only used on Mac? So you could ignore if you’re only building your iOS target.
I also believe it’s no longer used in the cocos2d project itself, so if you created a new game project the mac version probably builds fine, since it doesn’t reference CCFontAtlas by default?
In your game project you can go to the Mac Target > “Build Phases”, then expand “Link Binary with Libraries”, then the plus ‘+’ to add , then type “iconv” to search, then choose “libiconv.tbd” (might have a different extension depending on xcode/sdk versions.
note: if you see it in the list of libraries before adding, remove it first (just to make sure you’re linking the correct version - old one may be invalid path)
p.s. the other library is libz.tbd (but that’s also only used for specific classes)
Ah, I see that I do have it similar in my iOS project as:
OTHER_LINKER_FLAGS = $(inherited) -lz -liconv
So, I should probably test if adding those to the Mac Target works the same, instead of the Build Libraries phase?
Not sure if either is better than the other. With Xcode I do usually prefer limiting how much I edit the build settings directly, at least recently (back in Xcode 4-8 era the build settings were simpler/easier)
Hope something I said helps, because commenting out is probably not ideal
Thanks! Yeah, I’ve tried -liconv and tried adding the library. I want to get this out asap, and that’ll give me some breathing room to revisit again. Right now, I build the game for Windows, Mac, and now iOS. I sell the Windows and Mac versions on Steam, but hope to add the Mac version to the Apple store this year. I’m also hoping to have the iOS version ready within a month. It runs great, just need to tweak some UI things.
Thanks much!
BTW, have you seen the debacle over at Unity?? Wow, I’m glad I’m not on that platform. I do plan on eventually trying Unreal, but no hurry.
You may have entered it incorrectly, based on your screenshot.
The format I showed was setting the “Other Linker Flags” directly.
Instead, you should replace that highlighted in blue line to be just the text -liconv
I am working on one game that is using Unity. Thankfully it looks like if we don’t upgrade past Unity 2022 LTS none of it applies, but also even if we had to pay the fees our games is planned for a $10+ release, so the fees would be minimal. And need to gross $200k before any fees, we can now optionally not show Unity splash screen, and if we subscribe to pro (admittedly expensive $5k/user/year I think) then no fees until 1M installs and $1M gross (revenue, not profit) … and regardless I’ll personally make only a small % of the profits anyway, shrug
The main thing for me is that while Unity changes are not great, it’s not terrible as long as they stick to their final terms, at least for any game I’d be involved with. The financials and terms of the fees are mostly an issue for free-to-play or ad-based games, which I try to avoid working on. There is a chance they’ll send a bill for 10x more than any game should owe, and proving sales, installs, and reinstalls, and related numbers could become very onerous Unity decides to continue as the villain.
However, they’ve fully lost the trust of any Indie developers, so that part is a huge issue and I’ll no longer want to use Unity in the future if I have any control of choosing the engine or frameworks.
For any new games I make on my own I’ll probably use either axmol (cocos2d-x) for 2D or Godot for 3D going forward (or make “custom” engines based on libraries, frameworks, or heavily customized axmol/cocos2d as a base).
Unreal is too heavy for smaller games, so I’d only end up using it (or learning it) if I got a job (or want to apply) at a larger studio, or at least with a large game.
Thanks, Steve, good info! Yeah, my game isn’t huge either, and cocos2d has been good. The biggest problems are having to write some work-arounds occasionally, but that’s ok. Right now, the iPad keyboard drives me nuts (the three different keyboards have different behaviors, and I can’t get the undocked one to close when I tap outside my edit box I’m editing), but really Windows is my biggest customer.
I don’t make enough to worry about Unity fees, and I have too many features I want to add to my game for next year, so I’m going to stick with cocos2d-x for at least one more year. Then I think I’d check out the options you mentioned. I need to look into axmol, since I’d been quite familiar with its heritage, and I’ll also check into godot.
Ah, so those errors are different than what I understood in your initial post. It is still possible that the initial error was partly a missing “iconv library” reference for the linker.
This latest error basically says that there are two function calls where the linker cannot find the actual function because it’s trying to pass a void * to a function where the only candidates require a iconv_t as the first parameter.
note: This is probably a recent change to the iconv.h library header source in iOS 15/16/17 SDK, where they wanted to specify parameters and member fields. It’s also possible this is a C++ standard or POSIX standard update? Who knows (I mean you could google why :D)
Anyway, if you add an explicit cast to the function calls you should be able to build.
CCFontAtlas.cpp
// Add explicit cast (iconv_t) for the first function parameter in each error location
// Line 249 (approx. line)
iconv((iconv_t)_iconv, (char**)&pin, &inLen, &pout, &outLen);
// Line 140 (approx.)
iconv_close((iconv_t)_iconv);
It’s also possible you could instead change the data type of _iconv to iconv_t instead of void* but that has a chance to cause issues across the code base. My guess would be the header solution would be the ideal solution, and likely not cause other issues (since this is narrowly used for fonts only), but again this reply is mostly about getting your build working quickly, especially since there’s no more work being done on the cocos2d-x project.
Hopefully your project is set up with cocos2d library sources that you can edit, otherwise we’ll have to submit a Github request and hope the team or persons who have commit access will merge it sooner than later.
** you can also try and undo the changes you made to add “-liconv” and “-lz” to test if the build is still successful, in which case your project(s) were set up to build correctly before, but the error was just ambiguous and the only actual error was this ambiguous or ‘missing’ function definition.
Thank you so much for helping me to solve this issue. Your suggestion is works fine. But I am preferring the second one which @dragon0962 suggested in below comment.
No problem, glad you chose the more ideal solution
I did mention you could also modify the type in the header, but it sort of hidden because I mentioned it in passing.
In this instance there is no issue because the change in the header only affects one .cpp file, but sometimes modifying the type of a variable or class member can require fixing up a lot more code if it affects other .cpp files. It’s more correct, but can be only possible if you have full source for everything that references the header file.
This is why I mentioned it’s the ideal solution, but I gave you the solution that in general is often the easier, quicker, and sometimes safer* solution.
* safer in the sense that if you have prebuilt libraries (like many in the /external/ folder) then you can cause linking issues
Just for the sake of posterity: I’m posted this for my own sake to have a reference
So, I did confirm that Xcode 15.0 iOS SDK does contain a newer version of iconv.h that changes the type iconv_t from a void* to the opaque tag type struct __tag_iconv_t * (and then confirmed Xcode 12-14 contain the old version)
Also, checked previous Xcode SDKs if they include the old or new version of iconv.h
