Nigel Pearson <[EMAIL PROTECTED]> 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.
osx-script-and-errors.tar.bz2
Description: Binary data
Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
