Re: [wxlua-users] wxLua on wxMac

[Francesco M. <f18...@ya...>]

Anders F Björklund ha scritto:
> Francesco Montorsi:
> 
>>> Not actually using it, but will happy to give building it a try...
>> Great! Also remember us if you need some other file to generate the
>> MacBundle which is not in CVS yet. In fact, if the generation is more
>> than 2-3 commands, we may also add a script to do it under
>> distrib\macbundle (just like I do for autopackages under
>> distrib\autopackage).
> 
> Trying to build wxLua CVS (2.8.0) on wxMac 2.8.0 UNICODE/Universal.
> 
> 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?

> 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?

>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. 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...



> - The generated shared libraries only have versioned names, so they
>    aren't able to find eachother later when trying to run the binaries.
>    i.e. it installs *-2.8.0.0.0.dylib but looks for *-2.8.0.dylib ?
>    Symlinking these manually after installation fixes this issue...
hmmm, strange....

I just know that bakefiles use the following:

             <version>$(WXLUA_VERSION)</version>
             <so_version>$(WXLUA_SOVERSION)</so_version>
             <mac_version>$(WXLUA_MACVERSION)</mac_version>

where WXLUA_MACVERSION should be set to 1, WXLUA_SOVERSION to 0.0.0 and 
WXLUA_VERSION to 2.8.0

Maybe I should change mac_version tag to something else? Or remove it 
completely... I think I took that <mac_version> "logic" from wxWidgets 
bakefiles but now grepping for <mac_version> in wx\build\bakefiles gives 
no result. They have replaced it with:

     <set var="WXMACVERSION_CMD">
         <if cond="PLATFORM_MACOSX=='1'">
            <!-- Version can't be 0, so add 1 to it to force it to be 
non null -->
             -compatibility_version $(int(WX_AGE)+1).0 -current_version 
$(int(WX_AGE)+1).$(WX_REVISION)
         </if>
     </set>


         <!-- FIXME: until libtool scheme is implemented in bakefile -->
         <ldflags cond="FORMAT=='autoconf'">$(WXMACVERSION_CMD)</ldflags>

Do you think adding the above would fix the problem?


> - 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"...

>    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.

> 
> - 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?


>    Again, symlinking to the rescue - but it seems there are some
>    duplicated symbols (?) between libwx and libwxlua, so I think I
>    will have to rebuild the entire thing with static libraries...
> 
> I can do a manual build / packaging for Christmas, but I would
> hardly state that it builds "out of the box" on Mac OS X :-)
right. Would be nice to solve these problems before 2.8.0.0.

Francesco