[aaronjb]

So I waited a few days before posting this in case it was something b0rked in svn that got fixed in short order.. but this looks like it's just affecting me, and I'll be damned if I can figure out why - it certainly doesn't seem to be stopping TheQuestor building his nightlies.

The change that seems to have broken things for me is r21196's changes to tinyxmlparser.cpp

Specifically compilation stops with the following:

Code:

/Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp:657: error: invalid conversion from 'const char**' to 'char**'
/Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp:657: error:   initializing argument 2 of 'size_t libiconv(void*, char**, size_t*, char**, size_t*)'

Which is this section of code:

Code:

#if defined(_LINUX) and !defined(__APPLE__)
  char* ibuf = (char*) text->c_str();
#else
  const char* ibuf = (const char*) text->c_str();
#endif
  
  if (iconv(document->iconvContext, &ibuf, &ilen, &obuf, &olen) == (size_t) -1)

I've checked and I do seem to have the latest libiconv installed - the only departure from README.osx is that I don't install with +universal or use 10.4 headers as I only intend to use the builds on my 10.5 machines - and perhaps that's causing a difference?

Editing the code above so that when __APPLE__ is defined we use the same definition for ibuf as _LINUX, everything compiles fine..


For reference, here's my port installed output.


Any clues appreciated, it's doing my nut

[althekiller]

http://trac.xbmc.org/changeset/21213/bra...parser.cpp
http://trac.xbmc.org/changeset/21215/bra...parser.cpp

[tslayer]

After you wait a few days to report something, you need to remember to svn up(date) in order to make sure it hasn't been fixed.

r21198 is from a few days ago.

Did you forget to sync up from svn?

[aaronjb]

After you wait a few days to report something, you need to remember to svn up(date) in order to make sure it hasn't been fixed.

r21198 is from a few days ago.

Did you forget to sync up from svn?

I'm stupid, but I'm not a total idiot

In fact, over the last couple of days I've completely nuked my svn repository and checked out a fresh copy repeatedly (once on Friday, once on Saturday) - still no dice.

I did it again just now, in fact:

Code:

link:Development aaronjb$ rm -rf xbmc/
link:Development aaronjb$ svn co https://xbmc.svn.sourceforge.net/svnroot/xbmc/branches/linuxport xbmc
..snip..
Checked out revision 21246.

Followed by a quick:

Code:

link:XBMC aaronjb$ autoconf && ./configure --disable-debug && make clean && make xcode_depends

Then attempted to build in Xcode to be greeted by:

Code:

cd /Users/aaronjb/Development/xbmc/XBMC
    /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -D_DEBUG -D_LINUX -D_REENTRANT -D_FILE_DEFINED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAS_SDL_JOYSTICK -isysroot /Developer/SDKs/MacOSX10.4u.sdk -ftree-vectorize -fvisibility-inlines-hidden -mmacosx-version-min=10.4 -gdwarf-2 -I/Users/aaronjb/Development/xbmc/XBMC/build/XBMC.build/Debug/XBMC.build/XBMC.hmap -F/Users/aaronjb/Development/xbmc/XBMC/build/Debug -I/Users/aaronjb/Development/xbmc/XBMC/build/Debug/include -Iguilib -Ixbmc -Ixbmc/osx -Ixbmc/linux -Ixbmc/cores -Ixbmc/cores/dvdplayer -Ixbmc/cores/ffmpeg -Ixbmc/utils -Ixbmc/lib -Ixbmc/lib/libRTMP -Ixbmc/lib/libportaudio -Ixbmc/lib/libPython/Python/Include -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include/mysql5 -I/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include -I/Users/aaronjb/Development/xbmc/XBMC/build/XBMC.build/Debug/XBMC.build/DerivedSources -c /Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp -o /Users/aaronjb/Development/xbmc/XBMC/build/XBMC.build/Debug/XBMC.build/Objects-normal/i386/tinyxmlparser.o
/Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp: In static member function 'static void TiXmlBase::ConvertToUtf8(TiXmlDocument*, std::string*)':
/Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp:657: error: invalid conversion from 'const char**' to 'char**'
/Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp:657: error:   initializing argument 2 of 'size_t libiconv(void*, char**, size_t*, char**, size_t*)'
    /Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp:657: error: invalid conversion from 'const char**' to 'char**'
    /Users/aaronjb/Development/xbmc/XBMC/guilib/tinyXML/tinyxmlparser.cpp:657: error:   initializing argument 2 of 'size_t libiconv(void*, char**, size_t*, char**, size_t*)'

Actually it appears I did make one mistake in my original posting - it's not 21198 that breaks compilation for me, it's 21215.

Defining ibuf as a const (as per the current code) causes the compilation errors above:

Code:

const char* ibuf = (const char*) text->c_str();

Changing the conditional #ifdef to always define it as a simple 'char*' fixes things and everything compiles fine..


What I don't understand is why I appear to be the only person for whom defining ibuf as 'const char*' causes problems?

[davilla]

more /opt/local/include/iconv.h and tell me what _LIBICONV_VERSION is defined as;

libiconv @1.12_2 has;

"#define _LIBICONV_VERSION 0x010B"

[aaronjb]

I have 0x010D;

Code:

link:~ aaronjb$ grep _LIBICONV_VERSION /opt/local/include/iconv.h
#define _LIBICONV_VERSION 0x010D    /* version number: (major<<8) + minor */

Which ports, at least, believes is 1.13_0

[andyblac]

i'm having similar problems when i try make "xcode_depends" i get this error

Code:

ranlib: file: libGoAhead-x86-osx.a(rom.o) has no symbols
ranlib: file: libGoAhead-x86-osx.a(SpyceModule.o) has no symbols

then i get the same error as you when i try to build using Xcode.
i too have version

Code:

libiconv @1.13_0 (active)

installed

using latest svn i even tried to deleted my copy, and checkout a new copy, same result.

[aaronjb]

libGoAhead has always said that for me - it's never prevented compilation, however.

The tinyxmlparser stuff is new, though.

[davilla]

libiconv is a mess on OSX, there are different flavors depending on version, try this;

Code:

#if defined(_LINUX) and !defined(__APPLE__)
  char* ibuf = (char*) text->c_str();
#elif defined(__APPLE__)
// do not mess with this, _LIBICONV_VERSION might not be defined on other platforms
#if (_LIBICONV_VERSION > 0x010B)
  char* ibuf = (char*) text->c_str();
#else
  const char* ibuf = (const char*) text->c_str();
#endif
#else
  const char* ibuf = (const char*) text->c_str();
#endif

[davilla]

i'm having similar problems when i try make "xcode_depends" i get this error

Code:

ranlib: file: libGoAhead-x86-osx.a(rom.o) has no symbols
ranlib: file: libGoAhead-x86-osx.a(SpyceModule.o) has no symbols

That's not an error (hint, no big fat ERROR message). This just means those object files have no exported symbols.

[aaronjb]

libiconv is a mess on OSX, there are different flavors depending on version, try this;

Code:

#if defined(_LINUX) and !defined(__APPLE__)
  char* ibuf = (char*) text->c_str();
#elif defined(__APPLE__)
// do not mess with this, _LIBICONV_VERSION might not be defined on other platforms
#if (_LIBICONV_VERSION > 0x010B)
  char* ibuf = (char*) text->c_str();
#else
  const char* ibuf = (const char*) text->c_str();
#endif
#else
  const char* ibuf = (const char*) text->c_str();
#endif

Ah yes - beautiful, error-free, compiling goodness..

I figured it must have been libiconv - I just wasn't entirely sure of the implications of defining ibuf as a char, rather than a const (or why iconv had changed, for that matter)


If macports properly supported versioning then it would all be moot, we could just depend on the older version of libiconv. Such is life, eh!


Thanks davilla

[aaronjb]

Oh look: http://trac.xbmc.org/changeset/21247

I love the speed of development on XBMC.. thanks davilla!

(The commit note on 21248 amused me though: "fixed: Quelled a noisy davilla (and some compiler warnings)." :lol: )

[jmarshall]

Um, why the hell aren't we using the perfectly good, working charsetconverter for this code?

Can someone please make it so?

Cheers,
Jonathan