[mythtv] OSX build issues and patches

[David Abrahams]

Nigel Pearson <nigel at ind.tansu.com.au> writes:

> 	David, some discussion on your changes:
>
>
>> * I'm trying to build a backend, so that's been enabled in the script.
>
> 	I suspect that most people will _not_ be building
> the backend for a while, so I would like to leave that
> default as is. How about a '--enable-backend' flag?

Agreed; I was just documenting the changes I made.  This particular
one, I wasn't suggesting be kept.

>
>> * Many of the SourceForge download addresses in there wouldn't work
>>   for me.  I changed the script to use a different mirror
>
> 	I guess we should have a variable up near the top
> to select a particular mirror. I have added:
>
> our $sourceforge = 'http://internap.dl.sf.net'

Good.

>> * FreeType is now at 2.1.10 and you can't get 2.1.9 anymore; updated
>
> 	Indeed. Will check in that change now.
>
>
>> * As part of one flawed attack at the problem above, I tried it with
>>   QT 4.  Its configure options are completely different.  I left those
>>   lines in the script, commented out, in case it becomes useful to
>>   someone.
>
> 	Thanks. It will come in handy.
>
>>
>> * After I got the QT mac version test program to compile, it wouldn't
>>   link.  Based on
>>   http://lists.trolltech.com/qt-interest/2005-05/thread00265-0.html I
>>   added -lobjc to the link line.  Since it seemed to have the answers
>>   I also added '-platform macx-g++' to the configure options.  I don't
>>   remember offhand whether that addressed a specific obstacle or if I
>>   just went on faith based on that article.  I know it was necessary
>>   when I was trying to work with QT4, so it may well have been needed.
>
> 	That doesn't seem to be needed for a frontend build against
> QT/Mac 3.3.4, so I have left it out for now.

Okay.  This may well have been related to the fact that it was picking
up X11 libraries.

>> * In libexif-0.6.12/libexif/exif-utils.c, line 86, exif_get_sshort is
>>   defined as static after being already declared without; I had to
>>   comment out the 'static' in order to make the compiler happy
>>
>> * In qt-mac-free-3.3.4/mkspecs/macx-g++/qplatformdefs.h,
>>
>>     #define QT_SOCKLEN_T int
>>
>>   needs to be
>>
>>     #define QT_SOCKLEN_T socklen_t
>>
>>   in order to work with the latest system headers.
>
> 	Weird. The build just works for me. Are you using a newer GCC?

Maybe.

> % gcc --v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)

I get 4.0.1

I'd tend to suspect the system headers, though.

I think we should automate these patches or serve our own, patched
tarballs.

>> * Some QT things were failing to find -lXext at link time, and after
>>   mucking about with fink for *way* too long trying to find it (and I
>>   hope I didn't mess up my configuration), I realized it was already
>>   installed.  So I added -L/usr/X11R6/lib to qmake_opts and QT got
>>   happier.
>
> 	That is not a correct fix. The OS X frontend
> does not use _any_ X11 code. Nada. Ziltch.
> If something is trying to pull in X11 stuff,
> then _it_ needs to be fixed.

I don't know what it was; I'm now on a system without X11, and it's
not happening anymore.

> 	I will do a --enable-backend build next,
> and see if I can reproduce this fault.
>
> 	Is it possible that you have a Qt/X11 build
> (e.g. Fink's) that is somehow being referenced?

Yes, it was very likely the case.

>> * mythtv seems to hardcode the use of distcc into its Makefiles, and
>>   OSX doesn't have a distcc binary available
>
> 	Hmmm. My 10.3.9 install has it:
>
> % which distcc
> /usr/bin/distcc

Yep, mine has it too, on the clean machine.  Strange.  It may have
been the lack of ccache that was messing that up.  I did have to
install that on the clean machine before distcc could work.

> 	I am not sure why it is often enabled,
> but configure lets you turn this off:
>
> % ./configure --disable-distcc
> # Basic Settings
> Compile type     release
> Compiler cache   no
> DistCC           no
> ...

Heh, I got it going on multiple macs now, for my first experience of
distributed builds.

> % head config.mak
> # Automatically generated by configure - do not modify
> PREFIX=/usr/local
> QMAKE_CC=cc
>
>
> (instead of the default:
>  % head .osx-packager/src/myth-svn/mythtv/config.mak
>  # Automatically generated by configure - do not modify
>  PREFIX=/Volumes/MythOSXbuild/.osx-packager/build
>  QMAKE_CC=distcc cc
> )
>
> ...
>> @@ -1048,7 +1076,7 @@
>>      {
>>          if (! -e "$SCRIPTDIR/.osx-packager.dmg")
>>          {
>> -            Syscall(['hdiutil', 'create', '-size', '1000m',
>> "$SCRIPTDIR/.osx-packager.dmg",
>> +            Syscall(['hdiutil', 'create', '-size', '1500m',
>> "$SCRIPTDIR/.osx-packager.dmg",
>
> 	Why increase this? 

A temporary state of hackery.  I *was* running out of space on that
disk when I was building against QT4, because there wasn't any obvious
way to disable all the parts that we're disabling in QT3.  I just
never changed it back.  Again, this was not intended to be a patch
submission; I'd have cleaned it up a lot more than that if it was.

> The previous size is plenty big enough
> for the frontend plus some extra growth (extra plugins, a few
> archived copies of the frontend, et cetera). Bigger means that
> people need that much extra space on their disks to actually
> create the image.

My latest problem is that the construction of the MythBackend package
isn't completing correctly.  I'm not sure what's gone wrong there and
I need someone with more dylib expertise to take a look, if possible.
I've enclosed the latest build script and the error log.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: osx-script-and-errors.tar.bz2
Type: application/octet-stream
Size: 17698 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20051214/a7fe01db/osx-script-and-errors.tar-0001.obj
-------------- next part --------------

Thanks,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com