[mythtv] OSX build issues and patches
David Abrahams
dave at boost-consulting.com
Wed Dec 14 20:28:58 EST 2005
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
More information about the mythtv-dev
mailing list