Menu
▾
▴
wxlua-users
|
From: Francesco M. <f18...@ya...> - 2006-12-17 10:59:57
|
Hi all|Anders Björklund,
is anyone out there using wxLua on a mac?
We would be glad to publish new wxLua screenshots for wxMac, and to fix
any problem with mac-bundling, if there's any, before 2.8.0.0
Thanks!
Francesco
|
|
From: <af...@al...> - 2006-12-17 20:21:35
|
Francesco Montorsi wrote: > Hi all|Anders Bj=F6rklund, > > is anyone out there using wxLua on a mac? > > We would be glad to publish new wxLua screenshots for wxMac, and to = fix > any problem with mac-bundling, if there's any, before 2.8.0.0 Not actually using it, but will happy to give building it a try... --anders |
|
From: Francesco M. <f18...@ya...> - 2006-12-18 23:58:22
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >> Hi all|Anders Björklund, >> >> is anyone out there using wxLua on a mac? >> >> We would be glad to publish new wxLua screenshots for wxMac, and to fix >> any problem with mac-bundling, if there's any, before 2.8.0.0 > > 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). Thanks! Francesco |
|
From: <af...@al...> - 2006-12-21 23:23:00
|
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 and doesn't support the -isysroot flag which chokes the linking. So building twice it is (once for PowerPC and once for Intel, and then merging with lipo) - 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... - The generated program does not use Rez to set the icons, which for wxWidgets means that they won't receive any events either. 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?) - wxStEdit seems to install the library as libstedit, but is later trying to use it for linking with the libwx_macu_stedit name. 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 :-) --anders |
|
From: <af...@al...> - 2006-12-22 00:36:43
|
> 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 :-) It built OK using static linking of the various libraries. (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS) The good news: http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png The bad news: 316K bin/lua 24M bin/wxlua 21M bin/wxluacan 27M bin/wxluaedit 21M bin/wxluafreeze 512K lib/liblua5.1.a 12M lib/libwxlua_macu_wxbind-2.8.a 1.2M lib/libwxlua_macu_wxbindstc-2.8.a 536K lib/libwxlua_macu_wxlua-2.8.a 488K lib/libwxlua_macu_wxluadebug-2.8.a 756K lib/libwxlua_macu_wxluasocket-2.8.a ==== 32M wxlua.zip So I think I will have to get the dynamic linking working. (the above sizes were with the debugging symbols stripped) --anders PS. These were the Universal Binary builds (i.e. ppc+x86) It requires Mac OS X 10.4 to run, can do a 10.3 build too. |
|
From: Francesco M. <f18...@ya...> - 2006-12-22 13:03:10
|
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
|
|
From: <af...@al...> - 2006-12-22 15:34:58
|
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)
>> 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'
(-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)
>> 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}"
> 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
> Do you think adding the above would fix the problem?
I will experiment a little, but I'm very unfamiliar with Bakefiles.
>> - 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.
Not 100% sure why actually, but adding a resfork or bundle "fixes" it ?
>> 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
?
>> - 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)
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 ?
Will there be a 1.2.5 release out to fix this, before wxLua 2.8.0 is
out ?
--anders
|
|
From: Francesco M. <f18...@ya...> - 2006-12-22 19:13:48
|
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 |
|
From: <af...@al...> - 2006-12-22 19:49:34
|
Francesco Montorsi wrote: > 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 name of the library is "libwx_macu-2.8" (i.e. 2.8 is part of name) The API (major) version is 0, thus libwx_macu-2.8.0.dylib (the lib id) The implementation/minor version is 0.0.0, yielding all five numbers: libwx_macu-2.8.dylib -> libwx_macu-2.8.0.dylib libwx_macu-2.8.0.dylib -> libwx_macu-2.8.0.0.0.dylib libwx_macu-2.8.0.0.0.dylib I think it's done the same way on Linux ? The first library/symlink is only for developer use, since programs link to an API version. (only that Macs are more sensitive to the file suffix, than Linux) libwx_gtk2u-2.8.so -> libwx_gtk2u-2.8.so.0 libwx_gtk2u-2.8.so.0 -> libwx_gtk2u-2.8.so.0.0.0 libwx_gtk2u-2.8.so.0.0.0 > I don't have the non-corrupted version of wxLua.icns... could you send > it to me then? http://www.algonet.se/~afb/wx/wxLua.icns http://www.algonet.se/~afb/wx/wxLua.r.gz > 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. Okay, but it didn't seem to find the headers there for some reason ? --anders |
|
From: Francesco M. <f18...@ya...> - 2006-12-22 20:58:06
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >> 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 name of the library is "libwx_macu-2.8" (i.e. 2.8 is part of name) > The API (major) version is 0, thus libwx_macu-2.8.0.dylib (the lib id) > The implementation/minor version is 0.0.0, yielding all five numbers: > > libwx_macu-2.8.dylib -> libwx_macu-2.8.0.dylib > libwx_macu-2.8.0.dylib -> libwx_macu-2.8.0.0.0.dylib > libwx_macu-2.8.0.0.0.dylib > > I think it's done the same way on Linux ? In linux the library is called e.g. libwxlua_gtk2u_wxlua-2.8.so.0.0.0 and there are the symlinks: libwxlua_gtk2u_wxlua-2.8.so -> libwxlua_gtk2u_wxlua-2.8.so.0* libwxlua_gtk2u_wxlua-2.8.so.0 -> libwxlua_gtk2u_wxlua-2.8.so.0.0.0* > The first library/symlink > is only for developer use, since programs link to an API version. > (only that Macs are more sensitive to the file suffix, than Linux) > > libwx_gtk2u-2.8.so -> libwx_gtk2u-2.8.so.0 > libwx_gtk2u-2.8.so.0 -> libwx_gtk2u-2.8.so.0.0.0 > libwx_gtk2u-2.8.so.0.0.0 > >> I don't have the non-corrupted version of wxLua.icns... could you send >> it to me then? > > http://www.algonet.se/~afb/wx/wxLua.icns > http://www.algonet.se/~afb/wx/wxLua.r.gz Ok, added .icns file with correct EOL type. BTW is "Rez" now correctly called? >> 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. > > Okay, but it didn't seem to find the headers there for some reason ? There's something I cannot understand, too. My config.log says: configure:7200: checking if wxStEdit (version >= 1.2.0) is available configure:7240: g++ -o conftest -g3 -O0 -Wall -Wundef -Wno-ctor-dtor-privacy -I/usr/local/lib/wx/include/gtk2-ansi-debug-static-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ conftest.cpp -lwx_gtk2d_stedit-2.8 -L/usr/local/lib -pthread /usr/local/lib/libwx_gtk2d_stc-2.8.a /usr/local/lib/libwx_gtk2d_xrc-2.8.a /usr/local/lib/libwx_gtk2d_html-2.8.a /usr/local/lib/libwx_gtk2d_adv-2.8.a /usr/local/lib/libwx_based_net-2.8.a /usr/local/lib/libwx_based_xml-2.8.a /usr/local/lib/libwx_gtk2d_core-2.8.a /usr/local/lib/libwx_based-2.8.a -lexpat -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lfontconfig -lXext -lXrender -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lX11 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lXinerama -lSM -lpng -ljpeg -ltiff -lz -ldl -lm >&5 configure:7246: $? = 0 i.e. it manages to find stedit.h even without the -I/usr/local/include line... and I'm sure that I have stedit.h installed only at: /usr/local/include/wx/stedit/stedit.h and I have no symlinks that from "wx-2.8" go into "wx"... very strange. Maybe my GCC has a "builtin" search path the /usr/local/include path? I need to investigate. Francesco |
|
From: <af...@al...> - 2006-12-23 11:11:31
|
Francesco Montorsi wrote: >>> I don't have the non-corrupted version of wxLua.icns... could you >>> send >>> it to me then? >> >> http://www.algonet.se/~afb/wx/wxLua.icns >> http://www.algonet.se/~afb/wx/wxLua.r.gz > Ok, added .icns file with correct EOL type. Thanks, you can change it to "wxlua.icns" if you prefer lower case - as long as the same value is in the Info.plist.in file... > BTW is "Rez" now correctly called? Call seems correct, just that it operated on the wrong file... (a Bakefile issue ?) i.e. it did apps/wxlua, while the binary it should have changed is in bin/wxlua ? Think you need a $(top_builddir)/bin prefix --anders |
|
From: Francesco M. <f18...@ya...> - 2006-12-23 11:24:36
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >>>> I don't have the non-corrupted version of wxLua.icns... could you >>>> send >>>> it to me then? >>> http://www.algonet.se/~afb/wx/wxLua.icns >>> http://www.algonet.se/~afb/wx/wxLua.r.gz >> Ok, added .icns file with correct EOL type. > > Thanks, you can change it to "wxlua.icns" > if you prefer lower case - as long as the > same value is in the Info.plist.in file... ok, infact I'd like to know a thing about it: is it something required to get wxLua working when building it (just like wxlua.r -- i.e. something required by mac resource system) or rather something used only when creating the macbundle? In the first case it should be moved under wxLua\art (where we keep all resource related files); in the second one it should be kept under wxLua\distrib\macbundle... >> BTW is "Rez" now correctly called? > > Call seems correct, just that it operated > on the wrong file... (a Bakefile issue ?) right this is a bakefile bug. I've submitted a one-line fix patch. > i.e. it did apps/wxlua, while the binary > it should have changed is in bin/wxlua ? > > Think you need a $(top_builddir)/bin prefix should be ok now. Thanks, Francesco |
|
From: Francesco M. <f18...@ya...> - 2006-12-22 23:00:43
|
Francesco Montorsi ha scritto: > Maybe my GCC has a "builtin" search path the /usr/local/include path? > I need to investigate. yes, doing: cpp -v </dev/null reveals that /usr/local/include is a GCC include builtin path on my system. OTOH, I think that in any case the configure script does not need modifications. If you install things in /usr/local/include and that's not a builtin path for your GCC then you'll need to do: CPPFLAGS="-I/usr/local/include" ./configure Francesco |
|
From: <af...@al...> - 2006-12-23 10:50:16
|
Francesco Montorsi wrote: > If you install things in /usr/local/include and that's not a builtin > path for your GCC then you'll need to do: > > CPPFLAGS="-I/usr/local/include" ./configure Could be a confusion with the Mac framework headers, will investigate... i.e. <wx/wx.h> will look in /Library/Frameworks/wx.framework/Headers/wx.h Doing the explicit -I is probably preferred, even it does look silly. --anders |
|
From: Francesco M. <f18...@ya...> - 2006-12-22 13:25:16
|
Anders F Björklund ha scritto: >> 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 :-) > > It built OK using static linking of the various libraries. > (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS) > > The good news: > http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png > http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png > http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png good > The bad news: > 316K bin/lua > 24M bin/wxlua > 21M bin/wxluacan > 27M bin/wxluaedit > 21M bin/wxluafreeze > 512K lib/liblua5.1.a > 12M lib/libwxlua_macu_wxbind-2.8.a > 1.2M lib/libwxlua_macu_wxbindstc-2.8.a > 536K lib/libwxlua_macu_wxlua-2.8.a > 488K lib/libwxlua_macu_wxluadebug-2.8.a > 756K lib/libwxlua_macu_wxluasocket-2.8.a > ==== > 32M wxlua.zip huff, 32MB with release builds is a bad news. > So I think I will have to get the dynamic linking working. > (the above sizes were with the debugging symbols stripped) ach, I was just going to ask you to strip the binaries... maybe "upx" (if it's available for Mac) could help. > > --anders > > PS. These were the Universal Binary builds (i.e. ppc+x86) > It requires Mac OS X 10.4 to run, can do a 10.3 build too. I don't know how much 10.3 is old... maybe we could "drop" support for it... Francesco |
|
From: <af...@al...> - 2006-12-22 15:40:51
|
Francesco Montorsi wrote: >> PS. These were the Universal Binary builds (i.e. ppc+x86) >> It requires Mac OS X 10.4 to run, can do a 10.3 build too. > I don't know how much 10.3 is old... maybe we could "drop" support for > it... Find it easier to do one build 10.4 build for PowerPC/Intel, and one 10.3 build (that might even work on 10.2 and 10.1) Others do the Intel part for 10.4 (as is required by the OS), and the PowerPC part for 10.3 and then merge them together. --anders |
|
From: John L. <jla...@gm...> - 2006-12-22 04:42:58
|
On 12/21/06, Anders F Bj=F6rklund <af...@al...> wrote: > > 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 :-) Is there anything wrong with the code itself? It sounds like that part at least works. > It built OK using static linking of the various libraries. > (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS) I will be getting an antique mac next week to play with. I thought that macs could only be built staticly? There was also some issue about shared or multilib that didn't work with wxWidgets itself or has that been fixed? > The good news: > http://www.algonet.se/~afb/wx/wxlua28-wxluacan.png > http://www.algonet.se/~afb/wx/wxlua28-wxluamisc.png > http://www.algonet.se/~afb/wx/wxlua28-wxluahello.png Cool. > The bad news: > 316K bin/lua > 24M bin/wxlua > 21M bin/wxluacan > 27M bin/wxluaedit > 21M bin/wxluafreeze > 512K lib/liblua5.1.a > 12M lib/libwxlua_macu_wxbind-2.8.a > 1.2M lib/libwxlua_macu_wxbindstc-2.8.a > 536K lib/libwxlua_macu_wxlua-2.8.a > 488K lib/libwxlua_macu_wxluadebug-2.8.a > 756K lib/libwxlua_macu_wxluasocket-2.8.a > =3D=3D=3D=3D > 32M wxlua.zip > > So I think I will have to get the dynamic linking working. > (the above sizes were with the debugging symbols stripped) Not cool. Doesn't OSX install wxWidgets already? Can we just link against that, even if it's not 2.8, 2.6 was pretty good and probably good enough for the Mac binary. What do you think about that? Dumb question, since mac installs programs to /Applications as a package, does it also distribute the libs to the /Library dir for shared libs. Regards, John Labenski |
|
From: <af...@al...> - 2006-12-22 08:18:36
|
John Labenski wrote: > Is there anything wrong with the code itself? It sounds like that part > at least works. I think it's only 1 symbol (in Makefiles/linking), should be fixable. (Mac OS X is a little picky about "indirect symbols", for instance) >> It built OK using static linking of the various libraries. >> (using wxWidgets 2.8.0 with wxStEdit 1.2.4, and wxLua CVS) > > I will be getting an antique mac next week to play with. I thought > that macs could only be built staticly? There was also some issue > about shared or multilib that didn't work with wxWidgets itself or has > that been fixed? No, it can be built statically and dynamically... But there are only instructions from wxWidgets on how to be built it with static linking. wxWidgets developers didn't want to do shared Mac libs until next year. >> So I think I will have to get the dynamic linking working. >> (the above sizes were with the debugging symbols stripped) > > Not cool. Doesn't OSX install wxWidgets already? Can we just link > against that, even if it's not 2.8, 2.6 was pretty good and probably > good enough for the Mac binary. What do you think about that? Tiger shipped with 2.5.3. Leopard will supposedly ship with 2.8.0. And I think I would rather stay clear of the Apple library versions ? I'm using 2.6.3pl2++ for Mac OS X, and I will use 2.8.1 later on. > Dumb question, since mac installs programs to /Applications as a > package, does it also distribute the libs to the /Library dir for > shared libs. Unfortunately there are no Frameworks for wxWidgets, so it's installed UNIX-style under /usr... (as mac-unicode-debug-2.5) I've done some framework buids at http://www.algonet.se/~afb/wx/ --anders |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X