Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >>> Here are the issues I've run into: >>> >>> - Bakefile doesn't seem to support Universal Binaries, it uses the >>> -MMD flag which chokes the compilation >> with which error? > > gcc: -E, -S, -save-temps and -M options are not allowed with multiple > -arch flags > (Universal Binaries uses "-arch ppc -arch i386" flags, to build for > both arches) ahah. This is the post related to this problem (on bakefile-dev):
http://article.gmane.org/gmane.comp.sysutils.bakefile.devel/843 I've posted a reply asking Armel if he managed to fix this in bk-deps. >>> and doesn't support the >>> -isysroot flag which chokes the linking. >> hmm, are you saying that it doesn't add (by default) the -isysroot or >> that in some way you cannot specify it at all? > > The flag worked OK for the compilations, but not for linking the > dynamic libraries: > shared-ld: unhandled option '-isysroot' that is, it's a compiler flag, ok. > (-isysroot is used when cross-compiling from one Mac OS X version over > to another: > "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" or > MacOSX{10.3.9,10.2.8,10.1.5}.sdk) ok >>> So building twice it is >>> (once for PowerPC and once for Intel, and then merging with lipo) >> hmmm, I see the -MMD flag is added by bk-make-pch: >> >> # can do this because gcc is >= 3.4: >> ${compiler} -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}" >> >> It's used for dependency tracking. > > An unrelated problem here is that you get a "no _main" when > cross-compiling. > > I think it must be written like this, to work with Apple > cross-compilers: > ${compiler} -c -o ${outfile} -MMD -MF "${depsfile}" "${headerfile}" can you confirm that adding the "-c" fix the "no _main" problem ? It that's the problem we should submit a bakefile patch. >> I don't understand why it chokes your >> compilation but I wonder if doing: >> >> LDFLAGS="-isysroot" ./configure --disable-dependency-tracking >> >> wouldn't help you to solve these problems... > > Oops, my bad... Apple actually recommends that in their notes: > http://developer.apple.com/technotes/tn2005/tn2137.html so, in conclusion, adding the --disable-dependency-tracking fixes the problem ? >> Do you think adding the above would fix the problem? > > I will experiment a little, but I'm very unfamiliar with Bakefiles. I'll try to do some experiment, too. I'll look at the diffs of the Makefile.in trying to look if I can get applications to link against versioned libraries of wxLua, i.e. the *-2.8.0.0.0.dylib libraries. That is the right thing to do, isn't it? Also, is it common on Mac to have versioned libraries named like *-2.8.0.0.0.dylib (5 numbers!)? >>> - The generated program does not use Rez to set the icons, which >>> for wxWidgets means that they won't receive any events either. >> sorry, I'm not sure to get what you mean here saying "events"... > > They stay in the background. Menus are inactive. Windows are inactive. > The only thing they respond to is closing the main window or quitting. Thus, they're basically unusable. > Not 100% sure why actually, but adding a resfork or bundle "fixes" it ? see below >>> It needs to call upon Rez with the Carbon.r and wxLua.r files. >>> Unfortunately `wx-config --rezflags` is now gone from wx 2.8.0. >>> To complicate things more, the wxLua.r.gz is corrupted (ASCII?) >> sorry, I always forgot the "-kb" flag when adding binary things to CVS. >> See my other msg. > > Np, guessed that - seemed that wxLua.icns was corrupted in the same way > ? I don't have the non-corrupted version of wxLua.icns... could you send it to me then? BTW I've found out that I was missing some <mac-res> in apps.bkl. I've added them and committed the updated Makefile.in to CVS. Could you verify that Rez is now correctly called? Also, I've added (this time with -kb) the file "wxlua.r" (note the lowercase) under wxLua\art since that's the place where we keep wxLua resource files. >>> - wxStEdit seems to install the library as libstedit, but is later >>> trying to use it for linking with the libwx_macu_stedit name. >> libwx_macu_stedit should be right. Are you sure are you using the >> latest >> CVS for wxStEdit too? > > I am certain that I am using wx 2.8.0 and wxstedit 1.2.4 (not CVS > versions) John, is wxstedit 1.2.4 generating the wxlike-libname (and in this case there's something wrong somewhere with wxstedit's Makefile.in) or rather you've added this feature only in wxstedit CVS? > It installed the headers in /usr/local/include/wx as well, instead of in > /usr/local/include/wx-2.8/wx. But it's possible that this is fixed in > CVS ? this is not a bug. This is wanted. Better not to mess with the wx's include folder. /usr/local/include/wx (unversioned) is a safer place. > Will there be a 1.2.5 release out to fix this, before wxLua 2.8.0 is > out ? Good question: I'd like to see wxStEdit 1.2.5 if 1.2.4 is using libstedit as libname... Francesco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
