Kodi Community Forum

Hi all,

Elan's recent commits to SVN sort out a lot of the issues that I think some of us (well, me anyway) have been patching and hacking, which is excellent. I now have a working build with the apple remote support, 5.1 mix down, "\" key etc plus things like mythtv integration.

I did have to make one small hack to get this build to compile however. I'm sure it's due to my noviceness in C++ on the Mac, so I wonder if anyone can help my understanding?

I understand that the pre-processor flag __APPLE__ is automatically picked up by gcc on the OSX platform. Also I see that _LINUX is set inside the Xcode project pre-proc directives. So were are treating the OSX port as a subset of the linux one, with Apple specific exceptions right?

OK, in the SVN log for CharsetConverter.cpp Elan says "OS X prefers its iconv input strings to be const char**",

But on line 354 the code is

#if defined(_LINUX) && !defined(__APPLE__)
if (iconv(m_iconvUtf8ToStringCharset, (char**)&src, &inBytes, &dst, &outBytes) == (size_t) -1)
#else
if (iconv(m_iconvUtf8ToStringCharset, &src, &inBytes, &dst, &outBytes) == (size_t) -1)
#endif

Which seems to say, if we're on Linux and NOT Mac, then cast &src to (char**), otherwise (e.g we are on the Mac) then don't. On my machine this fails to compile. Gcc complains that you can't cast char** to const char**. If I change the code to ...

#if defined(_LINUX) && !defined(__APPLE__)
if (iconv(m_iconvUtf8ToStringCharset, (char**)&src, &inBytes, &dst, &outBytes) == (size_t) -1)
#else
if (iconv(m_iconvUtf8ToStringCharset, (char**)&src, &inBytes, &dst, &outBytes) == (size_t) -1)
#endif

..all works fine.

The logic in the code seems odd to me therefore. My question is, should the _LINUX flag be set? And if so, is the logic in that fragment the wrong way round?

I hope someone can shed some light on this, I expect it's something simple which I've overlooked or misunderstood. Any guidance gratefully recieved.

Thanks,
Spiderlane

Yes, the _LINUX flag is set on OSX builds at the moment.

And I presume the complaint is rather about const char ** -> char **, not the other way around (src is const char*, so &src would be const char **).

I would have thought iconv *should* be using const char**, but obviously on linux, and on your version with OSX, it wants char** for the input. The best fix in this case is to remove the !defined(__APPLE__) - on non-linux stuff (win32/xbox) we definitely want to keep it const char**.

Cheers,
Jonathan

jmarshall Wrote:And I presume the complaint is rather about const char ** -> char **, not the other way around

Cheers Jonathan, yes you're right. That'll teach me not to have the compiler message actually open when posting. It's been a while since my C++ days and there's been a lot of Java under the bridge since then, so just tuning back into pointers and references.

Your suggested approach definitely works, I just wondered why it was written with that !defined(__APPLE__) in there, I couldn't get the logic. Obviously my change was just a hack to help me debug the problem rather than a fix.

Perhaps Elan has changed it locally and the change hasn't made it into SVN?

Anyway, thanks for the clarification, other than that small change, it builds cleanly from SVN.

Let's await Elan's input

The change for the cpp file Spiderlane listed didn't work for me with today's svn checked out code.

I had to search and insert ALL of the (char**) for rss & characterset cpp files.

I got it almost to the end when there was an error, for a missing file, FileReader.cpp

Line Location FileReader.cpp:0: Command /Developer/usr/bin/gcc-4.0 failed with exit code 1
Line Location FileReader.cpp:0: i686-apple-darwin9-gcc-4.0.1: no input files
Line Location FileReader.cpp:0: i686-apple-darwin9-gcc-4.0.1: warning: '-x c++' after last input file has no effect
Line Location FileReader.cpp:0: i686-apple-darwin9-gcc-4.0.1: /Users/gordon/Public/linuxport/XBMC/xbmc/cores/paplayer/FileReader.cpp: No such file or directory
Line Location PlayListPlayer.cpp:59: warning: control may reach end of non-void function 'PLAYLIST::CPlayList& PLAYLIST::CPlayListPlayer::GetPlaylist(int)' being inlined
Line Location Surface.cpp:288: warning: unused variable 'options'
Line Location Util.cpp:4527: warning: passing negative value '-0x00000000000000001' for argument 5 to 'CGUIMessage::CGUIMessage(DWORD, DWORD, DWORD, DWORD, DWORD, void*)'
Line Location Util.cpp:4542: warning: passing negative value '-0x00000000000000001' for argument 5 to 'CGUIMessage::CGUIMessage(DWORD, DWORD, DWORD, DWORD, DWORD, void*)'
Line Location XBApplicationEx.cpp:327: warning: unused variable 'windowres'
Line Location XBMChttp.cpp:1270: warning: passing negative value '-0x00000000000000001' for argument 2 to 'CStdString CGUIInfoManager::GetImage(int, DWORD)'

You need to remove FileReader.cpp from the list of source files, then it should build fine.

And yes it was just one example in CharsetConverter.cpp I was quoting. All the references need to be fixed. Rather than the hack I discussed, I followed Jonathan suggestion and change the lines like this


from :

#if defined(_LINUX) && !defined(__APPLE__)
if (iconv(m_iconvUtf8toW, (char**)&src, &inBytes, &outdst, &outBytes))
#else
if (iconv(m_iconvUtf8toW, &src, &inBytes, &outdst, &outBytes))
#endif

to :


#if defined(_LINUX)
if (iconv(m_iconvUtf8toW, (char**)&src, &inBytes, &outdst, &outBytes))
#else
if (iconv(m_iconvUtf8toW, &src, &inBytes, &outdst, &outBytes))
#endif

I can submit a patch for this and the FileReader.cpp reference if anyone's interested?

Cheers
Spiderlane

remove the if defined totally, and always cast the src. that should work on all systems.

If you get that taken care of, feel free to submit a patch to our tracker at sourceforge.net

Hi. XBMC newbie here. I'm trying to compile on Leopard and I get a very similar error per the original poster. I've got the latest trunk (as of this writing it's version 14055) and tried to compile using the command per the README.osx file. I end up with a fatal error:

CharsetConverter.cpp:36: error: initializing argument 2 of ‘size_t libiconv(void*, const char**, size_t*, char**, size_t*)’
** BUILD FAILED **

Just wondering if anyone's got a patch/fix. Thanks much.

.mike

Which version of iconv are you dealing with?

Good call. It turned out that I had libiconv 1.12 on the system but 1.11 was the active version. The compile is currently running (and is alot farther along than previous attempts... *crosses fingers*).

Thanks a ton.

.mike

jmarshall Wrote:Which version of iconv are you dealing with?

I've gone through several port installs and path fixes as well as inclusion of directories into the library search path (using Xcode, btw).

Now I'm stumped on this one:

i686-apple-darwin9-g++-4.0.1: installation problem, cannot exec '/Developer/usr/bin/../libexec/gcc/i686-apple-darwin9/4.0.1/collect2': Argument list too long
Command /Developer/usr/bin/g++-4.0 failed with exit code 1

Has anyone run into this? Doing a search on the forums didn't yield any applicable hits.

Thanks again.

.mike