Confusion over CharsetConverter.cpp, _LINUX and __APPLE__
#1
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
Reply
#2
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
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#3
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.
Reply
#4
Let's await Elan's input Smile
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#5
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)'
Reply
#6
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
Reply
#7
remove the if defined totally, and always cast the src. that should work on all systems.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#8
If you get that taken care of, feel free to submit a patch to our tracker at sourceforge.net
Reply
#9
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
Reply
#10
Which version of iconv are you dealing with?
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#11
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?
Reply
#12
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
Reply

Logout Mark Read Team Forum Stats Members Help
Confusion over CharsetConverter.cpp, _LINUX and __APPLE__2