-
MacOS X building instructions
Dear All,
Very excited, but unable to build for OSX here:
WX widgets built as per instructions ... but then:
Macintosh:~ simonyoung$ ranlib /Users/simonyoung/XaraLX/libs/darwin/libCDraw.a
ranlib: for architecture i386 object: /Users/simonyoung/XaraLX/libs/darwin/libCDraw.a(libCDrawStatic.a-i386-master.o) malformed object (unknown flavor for flavor number 0 in LC_UNIXTHREAD command 3 can't byte swap it)
... any help gratefully received.
Kind regards,
Simon
-
Re: MacOS X building instructions
Could you report your Mac OS version and XCode version.
At the moment, to complete the build using standard methods entails quite extreme restrictions on the versions that work.
There was a similar message last month, videlicet:
http://www.xaraxtreme.org/maillists/.../msg00150.html
Could I trouble you to review the Build Instructions page at
http://www.xaraxtreme.org/developers...tructions.html
I am not saying that that page will solve the problem for you (though it might), but it would be helpful to hear of any imperfections and or omissions within it, that relate to your efforts.
When you do get Mac Xara LX running, it would be appreciated if you could check
Bug 935 "APPLICATION CLOSE".
Ben
-
Re: MacOS X building instructions
Dear Ben,
Thank you for your help; version of Xcode upgraded to 2.2.1 solved the ranlib problem.
Proceeding to XaraLX unfortuately generates errors at the autoreconf command. Please see below:
System: Mac OS X 10.4.6 18.GHz PowerPC G5
Xcode: 2.2.1
packages:
Macintosh:~/XaraLX simonyoung$ sudo fink list pkgconfig automake autoconf libpng libjpeg
Information about 2065 packages read in 1 seconds.
autoconf 2.13-5 System for generating configure scripts, ...
(i) autoconf2.5 2.59-7 System for generating configure scripts
autoconf2.54 2.54-4 System for generating configure scripts
automake1.4 1.4-5 Tool for generating GNU Standards-complia...
automake1.5 1.5-6 Tool for generating GNU Standards-complia...
automake1.6 1.6.3-6 Tool for generating GNU Standards-complia...
automake1.7 1.7.6-6 Tool for generating GNU Standards-complia...
automake1.8 1.8.5-3 Tool for generating GNU Standards-complia...
(i) automake1.9 1.9.4-2 Tool for generating GNU Standards-complia...
p automaken [virtual package]
i libjpeg 6b-16 JPEG image format handling library
i libjpeg-bin 6b-16 Executables for libjpeg package
i libjpeg-shlibs 6b-16 Shared libraries for libjpeg package
libpng-shlibs 1.0.12-7 PNG image format handling library (old ve...
i libpng3 1:1.2.8-1 PNG image format handling library
i libpng3-shlibs 1:1.2.8-1 Shared libraries for libpng3 package
i pkgconfig 0.15.0-2 Manager for library compile/link flags
executing autoreconf:
Macintosh:~/XaraLX simonyoung$ pwd
/Users/simonyoung/XaraLX
Macintosh:~/XaraLX simonyoung$ autoreconf -f -i -s
/sw/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/a...ending-aclocal
/sw/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
aclocal:configure.in:9: warning: macro `AM_BINRELOC' not found in library
/sw/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/a...ending-aclocal
/sw/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
aclocal:configure.in:9: warning: macro `AM_BINRELOC' not found in library
Macintosh:~/XaraLX simonyoung$
Help gratefully received.
Kind regards,
Simon
-
Re: MacOS X building instructions
You can ignore the warnings, I think that they are outside of our control and indicate that the m4 macros used by the folks who who built GTK et cetera were using an older version of m4 or autotools.
The AM_BINRELOC probably means that there is a package missing on from your setup, which we need but have not specified as being needed. I'll look into it.
Ben
-
Re: MacOS X building instructions
Do you have a file called binreloc.m4 in your XaraLX directory?
-
Re: MacOS X building instructions
For the avoidance of doubt, and again, I am not suggesting this is a part of getting the solution to this problem (though it might be), could you state which version of the GNU gettest tools you have, and if you wish, whether there have been any problems running autopoint.
Ben
-
Re: MacOS X building instructions
Quote:
Originally Posted by BPFowler
You can ignore the warnings, I think that they are outside of our control and indicate that the m4 macros used by the folks who who built GTK et cetera were using an older version of m4 or autotools.
The AM_BINRELOC probably means that there is a package missing on from your setup, which we need but have not specified as being needed. I'll look into it.
Ben
OK, try 1; no joy - then make clean, etc a good start. Then compilation halts with:
[snip a lot]In file included from pngfiltr.h:104, from pngfiltr.cpp:106:
outptpng.h:109:17: error: png.h: No such file or directory
outptpng.h:166: error: 'png_structp' does not name a type
outptpng.h:167: error: 'png_infop' does not name a type
pngutil.h:151: error: 'png_colorp' has not been declared
make[2]: *** [pngfiltr.o] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
Macintosh:~/XaraLX simonyoung$
-
Re: MacOS X building instructions
Quote:
Originally Posted by BPFowler
Do you have a file called binreloc.m4 in your XaraLX directory?
Yes
-
Re: MacOS X building instructions
Quote:
Originally Posted by BPFowler
For the avoidance of doubt, and again, I am not suggesting this is a part of getting the solution to this problem (though it might be), could you state which version of the GNU gettest tools you have, and if you wish, whether there have been any problems running autopoint.
Ben
Ben, I'm not sure if you mean gettext or gettest. Of the latter I can find no evidence so I'm going to assume the former (please accept my appologies in advance of being a silly newbie) ...
flagged status name installed version binary category summary
NO current gettext 0.10.40-19 0.10.40-19 0.10.40-19 base Message localization support
NO current gettext-bin 0.10.40-19 0.10.40-19 0.10.40-19 base Executables for gettext package
NO current gettext-dev 0.10.40-19 0.10.40-19 0.10.40-19 base Developer files for gettext package
NO current gettext-tools 0.10.40-19 0.10.40-19 0.10.40-19 base Developer executables for gettext package
I'm afraid that being a newbie I will not have encountered autopoint problems; is there something you would like me to run to test?
Kind regards,
Simon
-
Re: MacOS X building instructions
This is the same problem that Pekele had, videlicet,
http://www.talkgraphics.com/showpost...9&postcount=16
This has been discussed on the mailing list: there are several ways of getting the png headers for your compilation, but unfortunately all of them have some disadvantages or will cause problems down the line.
Apple actually provide the libraries as part of the Core Foundation, and if I knew where the corresponding headers were, we could use those.
I suspect that Xara LX will need to provide its own png library (just as it provides its own wxWidgets library), and whilst this means a little more work at this stage, you could certainly do this now. (The instructions will probably be amended to contain this advice).
Otherwise, you could add the fink include directory as above, which is the quickest way past this obstacle (and is what I do still)!
Ben
-
Re: MacOS X building instructions
Quote:
Originally Posted by Simon Young
Ben, I'm not sure if you mean gettext or gettest.
It is gettext.
I was under the impression that autopoint was part of recent version of gettext, but it seems that that the fink version of gettext is recent enough for us, but does not have autopoint which we need.
If practical, you may want to remove the fink gettext and install the latest GNU gettext
from source.
Ben.
(P.S. the forum software ate the first edition of this post and I have re-typed it from memory, so I am sorry if it does not reach my usual standards, which are not that high anyway)!
-
Re: MacOS X building instructions
I being a little speculative here, but I am leaning towards the idea I expressed above: The fink gettext package's not providing autopoint. Whilst this is arguably fink's bug, I do suggest removing the fink gettext and installing the latest GNU gettext.
If this is too fiddly, please post again and I will think about it. Ideally, we need to recruit a fink dev to this team or find some way of doing without autopoint.
Ben
-
Re: MacOS X building instructions
The gettext step is where i'm getting stuck. I have Mac OS 10.4.6 (PowerPC), using XCode 2.2.1. Here is what I'm seeing:
1. autoreconf fails with this:
Putting files in AC_CONFIG_AUX_DIR, `../build-aux'.
Putting files in AC_CONFIG_AUX_DIR, `../../build-aux'.
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
Putting files in AC_CONFIG_AUX_DIR, `../build-aux'.
lib/Makefile.am:57: required file `lib/strtol.c' not found
Putting files in AC_CONFIG_AUX_DIR, `../build-aux'.
lib/Makefile.am:118: required file `lib/strdup.c' not found
lib/Makefile.am:118: required file `lib/regex.c' not found
lib/Makefile.am:118: required file `lib/memchr.c' not found
/usr/share/automake-1.6/am/compile.am: DEFS was set with `+=' and is now set with `='
2. so i try ./configure and make (as in the gettext INSTALL)
3. configure works, but make fails with this:
gcc -dynamiclib -o .libs/libintl.3.4.3 .libs/bindtextdom.o .libs/dcgettext.o .libs/dgettext.o .libs/gettext.o .libs/finddomain.o .libs/loadmsgcat.o .libs/localealias.o .libs/textdomain.o .libs/l10nflist.o .libs/explodename.o .libs/dcigettext.o .libs/dcngettext.o .libs/dngettext.o .libs/ngettext.o .libs/plural.o .libs/plural-exp.o .libs/localcharset.o .libs/relocatable.o .libs/langprefs.o .libs/localename.o .libs/log.o .libs/printf.o .libs/osdep.o .libs/intl-compat.o /usr/lib/libiconv.dylib -lc -Wl,-framework -Wl,CoreFoundation -install_name /usr/local/lib/libintl.3 -compatibility_version 8 -current_version 8.3
ld: warning multiple definitions of symbol _locale_charset
.libs/localcharset.o definition of _locale_charset in section (__TEXT,__text)
/usr/lib/libiconv.dylib(localcharset.o) definition of _locale_charset
(cd .libs && rm -f libintl.3 && ln -s libintl.3.4.3 libintl.3)
(cd .libs && rm -f libintl && ln -s libintl.3.4.3 libintl)
ar cru .libs/libintl.a bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o l10nflist.o explodename.o dcigettext.o dcngettext.o dngettext.o ngettext.o plural.o plural-exp.o localcharset.o relocatable.o langprefs.o localename.o log.o printf.o osdep.o intl-compat.o~ranlib .libs/libintl.a
ar: intl-compat.o~ranlib: No such file or directory
make[3]: *** [libintl.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
I'm what you'd call "lost" at this point, any help would be appreciated. ;)
-
Re: MacOS X building instructions
Is there some sort of typo or glitch in your Makefile?
The odds are that you need automake 1.9 not 1.6, but I can't be sure at this distance.
Your probably need to clean you build directory and start from untar'ing the gettext source tarball.
Post again if you think that I am on the wrong lines.
Ben
-
Re: MacOS X building instructions
Ok, I switched to automake 1.9 -- and I get messages saying that the automake config was made with 1.6 and run aclocal to fix. Which does nothing.
This gettext piece is by far the most frustrating build I've encountered, this automake and autoreconf crapola is infuriatingly "too smart for its own good" (or mine, it would seem).
I'll wait for an OSX binary disto to start testing XaraLX, sorry folks.
-
Re: MacOS X building instructions
Quote:
Originally Posted by dbalmer
Ok, I switched to automake 1.9 -- and I get messages saying that the automake config was made with 1.6 and run aclocal to fix. Which does nothing.
That sounds like a new problem, and we would certainly be interested in seeing the error messages.
If you have the fink gettext installed, you could remove all verions of it - I am working on the basis that Xara LX needs gettext installed independently.
The fink automake 1.9 should be O.K. for Xara LX (but not for some other packages).
Ben.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
BPFowler
That sounds like a new problem, and we would certainly be interested in seeing the error messages.
If you have the fink gettext installed, you could remove all verions of it - I am working on the basis that Xara LX needs gettext installed independently.
The fink automake 1.9 should be O.K. for Xara LX (but not for some other packages).
Ben.
I found this thread via Google and wanted to mention that I'm having the exact same problem making gettext from the Gnu package... autoreconf reports the following:
Putting files in AC_CONFIG_AUX_DIR, `../build-aux'.
Putting files in AC_CONFIG_AUX_DIR, `../../build-aux'.
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
Putting files in AC_CONFIG_AUX_DIR, `../build-aux'.
lib/Makefile.am:57: required file `lib/strtol.c' not found
Putting files in AC_CONFIG_AUX_DIR, `../build-aux'.
lib/Makefile.am:118: required file `lib/strdup.c' not found
lib/Makefile.am:118: required file `lib/regex.c' not found
lib/Makefile.am:118: required file `lib/memchr.c' not found
/usr/share/automake-1.6/am/compile.am: DEFS was set with `+=' and is now set with `='
autoreconf: automake failed with exit status: 1
Note that I am using Mac OS X 10.4.7 (Intel) with Xcode 2.4 (partial install from the distribution DVD, omitting Java- and Web-related tools).
The gettext tarball is 0.14.6.
The functions strtol and strdup are supposedly part of the GNU libiberty library, which are in turn supposedly distributed with gcc, gdb, and binutils. Althought I have gcc 4.0 installed, I can find no trace of libiberty on my machine, though man pages are present for the above functions.
HUH! I just looked up at the error messages again and noticed that the error message is from automake-1.6, even though I just downloaded and installed automake 1.9 via fink. Turns out 1.9 is installed in /sw/bin, while 1.6 remains in /usr/bin, which is earlier in my path. Reversing the path order got automake 1.9 to run when I called autoreconf, but now it generates a LOT of warnings similar to
/sw/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
/sw/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
Otherwise, autoreconf now completes without an actual error.
./configure also completes without error, but make ends with
ar cru .libs/libintl.a bindtextdom.o dcgettext.o dgettext.o gettext.o finddomain.o loadmsgcat.o localealias.o textdomain.o l10nflist.o explodename.o dcigettext.o dcngettext.o dngettext.o ngettext.o plural.o plural-exp.o localcharset.o relocatable.o langprefs.o localename.o log.o printf.o osdep.o intl-compat.o~ranlib .libs/libintl.a
ar: intl-compat.o~ranlib: No such file or directory
make[3]: *** [libintl.la] Error 1
It appears to me (a non-guru) that for some reason 'make' is concatenating the 'ar' command with the 'ran' command, separated by a '~', so that 'ar' sees a spurious filename 'intl-compat.o~ranlib'
But for the life of me, I can't figure out why this is happening or how to make it stop, despite manually editing intl/Makefile.
Anyway, for now I'm stuck, unless there's another way to get the required version of 'gettext' installed.
-
Re: MacOS X building instructions
Found a binary for gettext that seems to work (so far) via i-Installer v2 from http://tug.org/i-packages/ii2.ii2
Now I'm running into problems using
autoreconf -f -i -s
in the XaraLX directory ... I get
Copying file mkinstalldirs
Makefile.am:29: directory should not contain `/'
Makefile.am:29: directory should not contain `/'
autoreconf: automake failed with exit status: 1
In short, I'm further along than I was, but stuck again.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Found a binary for gettext that seems to work (so Makefile.am:29: directory should not contain `/'
In short, I'm further along than I was, but stuck again.
You need to upgrade your autoconf and/or automake. I think that's an autoconf problem.
Alex
-
Re: MacOS X building instructions
Once again I was an unwitting victim of the path order ... I had automake 1.9 installed in /sw/bin, but it was hitting version 1.6 in /usr/bin first.
I've switched the path order in my .cshrc file, and that seems to have gotten me past the previous glitch. Now I'm on what I hope is my final glitch:
When I 'make' in ~/XaraLx, I get a bunch of warnings (see below) and then the following error:
dyld: Library not loaded: /usr/local/lib/libwx_macud-2.6.0.dylib
Referenced from: /Users/gpetty/wx/v263/build-unicode-debug/utils/wxrc/wxrc
Reason: image not found
Could not read dialogs for translation (empty or bad wxrc) [/bin/sh -c 'eval LD_LIBRARY_PATH=/Users/gpetty/wx/v263/build-unicode-debug/lib /Users/gpetty/wx/v263/build-unicode-debug/utils/wxrc/wxrc -g ./xrc/dialogs.xrc'] at .././Scripts/build-resources.pl line 423.
Makefile:335: *** "Resource build failed". Stop.
Note that I am also getting (earlier in the make):
Making all in wxOil
Testing for new resources and svn version
Rebuilding svn version
subversion/libsvn_wc/lock.c:377: (apr_err=155007)
svn: '..' is not a working copy
svnversion gives exported
It looks ominous to me, but maybe it means nothing.
Also, I get a lot of warnings about certain png files not being found ; e.g,
.././wxOil/xrc/EN/aboutres.xrc:23 Warning: Bitmap ./xrc/2.png not found
.././wxOil/xrc/EN/aboutres.xrc:82 Warning: Bitmap ./xrc/2.png not found
.././wxOil/xrc/EN/aboutres.xrc:149 Warning: Bitmap ./xrc/2.png not found
.././wxOil/xrc/EN/aboutrsw.xrc:23 Warning: Bitmap ./xrc/2.png not found
.././wxOil/xrc/EN/barsdlgs.xrc:762 Warning: Bitmap ./xrc/leftbrace.png not found
.././wxOil/xrc/EN/barsdlgs.xrc:766 Warning: Bitmap ./xrc/rightbrace.png not found
.././wxOil/xrc/EN/barsdlgs.xrc:770 Warning: Bitmap ./xrc/label.png not found
.././wxOil/xrc/EN/errordlg.xrc:31 Warning: Bitmap ./xrc/.png not found
.././wxOil/xrc/EN/register.xrc:19 Warning: Bitmap ./xrc/2.png not found
.././wxOil/xrc/EN/textres.xrc:26 Warning: Bitmap ./xrc/aspect.png not found
.././wxOil/xrc/EN/textres.xrc:74 Warning: Bitmap ./xrc/tracking.png not found
.././wxOil/xrc/EN/textres.xrc:78 Warning: Bitmap ./xrc/kerning.png not found
-
Re: MacOS X building instructions
Let me add that I just discovered that I have
/usr/local/lib/libwx_macud-2.5.3.dylib
but not the version 2.6.0 that is being sought in the make.
I did find:
/Users/gpetty/wx/v263/build-unicode-debug/lib/libwx_macud-2.6.0.dylib
I assume the build should be looking for that one; I don't know why it isn't.
-
Re: MacOS X building instructions
[QUOTE=gpetty;168410]Once again I was an unwitting victim of the path order ... I had automake 1.9 installed in /sw/bin, but it was hitting version 1.6 in /usr/bin first.
I've switched the path order in my .cshrc file, .../QUOTE]
fink should provide you with a script like:
Code:
source /sw/bin/init.sh
and instructions concerning the .rc files. (Are you really using the tsch?).
Ben
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Let me add that I just discovered that I have /usr/local/lib/libwx_macud-2.5.3.dylib but not the version 2.6.0 that is being sought in the make.
This was provided by Apple, FWIW I would suggest removing it (and all other traces of wxWidgets 2.5.x), but it was a pleasant surprise to find this library, and it would be very helpful to this project if future versions of MacOS has wxWidgets 2.6, 2.8 and so on.
Quote:
Originally Posted by
gpetty
... /Users/gpetty/wx/v263/build-unicode-debug/lib/libwx_macud-2.6.0.dylib
I assume the build should be looking for that one; I don't know why it isn't.
You want the --with-wx-config flag in your arguments to the configure script. See wxOil compiling issues for an example, and the Wx-Config page for more information about wx-config
Ben
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Once again I was an unwitting victim of the path order ... I had automake 1.9 installed in /sw/bin, but it was hitting version 1.6 in /usr/bin first.
Whilst having 2 automake's on your system isn't generally a good thing, and you have probably fixed the immediate problem, for future reference you can probably do (under bash, I don't know csh):
AUTOMAKE=/path/to/automake AUTOCONF=/path/to/autoconf AUTORECONF=/path/to/autoreconf (etc.) ./configure <options>
I know the FreeBSD guys use this.
Alex
-
Re: MacOS X building instructions
[QUOTE=BPFowler;168440]
Quote:
Originally Posted by
gpetty
Once again I was an unwitting victim of the path order ... I had automake 1.9 installed in /sw/bin, but it was hitting version 1.6 in /usr/bin first.
I've switched the path order in my .cshrc file, .../QUOTE]
fink should provide you with a script like:
Code:
source /sw/bin/init.sh
and instructions concerning the
.rc files.
Interesting. When I installed Fink + Fink Commander yesterday, I don't recall it pointing out any of this when I fired it up for the first time. I'm new to Macs (as of a few days ago), but so far at least, my experience had been that when you install a new (precompiled) program, it runs, and there's no need to dig into docs unless you run across something you don't understand. In every obvious respect at least, Fink Commander had been working fine for me so far.
Quote:
(Are you really using the tsch?).
Ben
Yes. It's what I've been using for 20 years, and no one had ever offered a reason why I should change. It gave me Emacs-style command-line editing and other benefits before other shells I knew about had that. If there's another shell (bash?) that I'd be better off with, I'm certainly willing to consider it, as long as the change isn't too painful.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
BPFowler
This was provided by Apple, FWIW I would suggest removing it (and all other traces of wxWidgets 2.5.x), but it was a pleasant surprise to find this library, and it would be very helpful to this project if future versions of MacOS has wxWidgets 2.6, 2.8 and so on.
You want the
--with-wx-config flag in your arguments to the
configure script. See
wxOil compiling issues for an example, and the
Wx-Config page for more information about wx-config
Ben
Here's the exact line I used, taking from my shell command history:
./configure --enable-debug --with-wx-config=/Users/gpetty/wx/v263/build-unicode-debug/wx-config
This in turn was taken verbatim from the "Xara LX Build for Mac" page, only substituting the slightly modified path to my wx-config
-
Re: MacOS X building instructions
Quote:
Originally Posted by
BPFowler
This was provided by Apple, FWIW I would suggest removing it (and all other traces of wxWidgets 2.5.x), but it was a pleasant surprise to find this library, and it would be very helpful to this project if future versions of MacOS has wxWidgets 2.6, 2.8 and so on.
After 20 years of muddling through builds of diverse software packages under various flavors of Unix, I'm amazed that modern build scripts still don't automatically check for, and offer advice about, conflicting versions of and/or paths to previously installed packages. Especially since scripts like configure seem to check for literally everything else.
I think the inevitable pain, suffering, and frustrated cursing that accompanies the build of almost any moderately complicated package is one important reason why Unix and its variants still haven't caught on with most non-expert users (I'm probably a major exception). The worst part is never knowing whether success will come in 5 minutes or 5 days. Or never. At some point, you make a guess as to the odds that the additional time invested will ultimately pay for itself, and you either push on or else go do something you KNOW will have a successful outcome, like mowing your lawn.
Grant
-
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
Whilst having 2 automake's on your system isn't generally a good thing, and you have probably fixed the immediate problem, for future reference you can probably do (under bash, I don't know csh):
AUTOMAKE=/path/to/automake AUTOCONF=/path/to/autoconf AUTORECONF=/path/to/autoreconf (etc.) ./configure <options>
I know the FreeBSD guys use this.
Alex
Thanks for the suggestion. I'll admit that before this particular effort, I had never even consciously encountered Automake and its kin before. There was make, and for a while there was imake, and then I took a long break from installing anything but Linux RPMs.
-
Re: MacOS X building instructions
Update: After clearing out the supplied Wx-widgets 2.5 and re-running config, autoreconf, etc., I ran make again in the XaraLX directory and ran into the same error as before, which I ended up solving with the following kludge:
% sudo ln -s /Users/gpetty/wx/v263/build-unicode-debug/lib/libwx_macud-2.6.0.dylib /usr/local/lib/libwx_macud-2.6.0.dylib
That seemed to work, as make then proceeded to run for a very long time, successfully making several large libraries (kernel, tools, etc.). But then this happened:
ranlib libTools.a
Making all in po
Makefile:431: warning: overriding commands for target `XaraLX.pot-update'
Makefile:155: warning: ignoring old commands for target `XaraLX.pot-update'
Makefile:431: warning: overriding commands for target `XaraLX.pot'
Makefile:184: warning: ignoring old commands for target `XaraLX.pot'
sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
make[1]: *** No rule to make target `../wxOil/xrc/xaralx.po', needed by `XaraLX.pot'. Stop.
make: *** [all-recursive] Error 1
Note that there don't seem to be source code or object files of any kind in ../wxOil/xrc
Any assistance will be greatly appreciated ... I feel I must be getting close.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Any assistance will be greatly appreciated ... I feel I must be getting close.
Run configure with the following additional commands:
--disable-international --disable-svnversion
The former will disable building of the internationalization resources (your resultant file will still be internationalizable). --disable-svnversion will disable building a header with the svn version number in (sometimes causes problems).
The next challenge will be at link stage.
I hope after all this you aren't going to be too disappointed when it doesn't work as well as on Linux. We have some endian problems we know we need to sort out on ppc MacOS, plus (no doubt) some other issues.
I don't quite understand why you need the symbolic link: if it's finding the correct wx-config, then
wx-config --libs
(running it with the right wx-config) should return a fully specified path to the correct library.
Alex
-
1 Attachment(s)
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
Run configure with the following additional commands:
--disable-international --disable-svnversion
The former will disable building of the internationalization resources (your resultant file will still be internationalizable). --disable-svnversion will disable building a header with the svn version number in (sometimes causes problems).
The next challenge will be at link stage.
The above options seem to have done the trick. The make completed without additional errors.
The resulting executable is huge: 784 MB. I've tried executing it, but so far all it's done is generate a couple dozen lines of debugging info. Although it hasn't terminated (it stills shows up in ps), there's no sign of life; even the debug comments have stopped. I'm uploading a file with the captured debug output, in case anyone can make sense of it.
Quote:
I hope after all this you aren't going to be too disappointed when it doesn't work as well as on Linux. We have some endian problems we know we need to sort out on ppc MacOS, plus (no doubt) some other issues.
I have no experience with the Linux version .. I only learned of Xara two days ago, but it sounded like a potential alternative to commercial programs like Adobe Illustrator. I had already shelled out for the Windows version of AI and was reluctant to do it again now that I've switched to the Mac world.
Re endian: I'm attempting to build Xara LX on an Intel-based Macbook. I assume the endianness is the same as for Linux on Intel machines.
Quote:
I don't quite understand why you need the symbolic link: if it's finding the correct wx-config, then
wx-config --libs
(running it with the right wx-config) should return a fully specified path to the correct library.
Alex
I don't understand it either. It seems to be finding everything else wx-related. But it definitely halts when it can't find the one library in /usr/lib, and creating the one symbolic link as described ended the impasse.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
The above options seem to have done the trick. The make completed without additional errors.
The resulting executable is huge: 784 MB. I've tried executing it, but so far all it's done is generate a couple dozen lines of debugging info. Although it hasn't terminated (it stills shows up in ps), there's no sign of life; even the debug comments have stopped. I'm uploading a file with the captured debug output, in case anyone can make sense of it.
The size is probably debugging symbols. Mine is "only" 147Mb.
In order to execute it successfully, you need to put it into a MacOS "bundle". I think this is pretty easy (some sort of mkdir with permissions and a copy). I'm not sure of the details, but I think it's something like this:
mkdir -p XaraLX.app/Contents/MacOS
cp xaralx XaraLX.app/Contents/MacOS
then
open XaraLX.app
Quote:
Originally Posted by
gpetty
I have no experience with the Linux version .. I only learned of Xara two days ago, but it sounded like a potential alternative to commercial programs like Adobe Illustrator. I had already shelled out for the Windows version of AI and was reluctant to do it again now that I've switched to the Mac world.
Re endian: I'm attempting to build Xara LX on an Intel-based Macbook. I assume the endianness is the same as for Linux on Intel machines.
Yes it is. You should have less difficulty here. I'm just saying it's early stages building for the Mac. But don't get me wrong, we appreciate people building it and testing it!
(you can, BTW, build wx for gtk if you install gtk on the Mac. Xtreme should then build fine but you will have a gtk interface not a Mac interface which is not what you want I presume...).
Alex
-
1 Attachment(s)
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
The size is probably debugging symbols. Mine is "only" 147Mb.
In order to execute it successfully, you need to put it into a MacOS "bundle". I think this is pretty easy (some sort of mkdir with permissions and a copy). I'm not sure of the details, but I think it's something like this:
mkdir -p XaraLX.app/Contents/MacOS
cp xaralx XaraLX.app/Contents/MacOS
then
open XaraLX.app
Three steps forward, one(?) step back.
Now that I understand what a bundle is ... it turns out the build automatically creates a folder XaraLX.app and associated subdirectories in the build directory. So all I had to do is mv the executable to ~/XaraLX/XaraLX.app/Contents/MacOS. I then used finder to open it, and voila ... it started up with a normal GUI. Initially it complained about something with fonts and then about not having ImageMagick 6.0, but these seemed not to be fatal errors.
But then disaster .. I simply clicked on the drawing window, and the program complained about a "very serious error" and said that it would have to close. Fortunately, it gave me the opportunity to generate an error report, which I have attached here.
Quote:
(you can, BTW, build wx for gtk if you install gtk on the Mac. Xtreme should then build fine but you will have a gtk interface not a Mac interface which is not what you want I presume...).
Alex
I'm too new to Macs to have any interface loyalty .. and i have no idea what the gtk interface is like. My prior experience is primarily with the Windows GUI and the Unix command line. If I continue to have problems getting a working Mac interface, I might like to take a look at the gtk version.
-
Re: MacOS X building instructions
Incidentally, the complaint about missing ImageMagick 6.0 seems spurious. I've investigated and found that I have exactly one version of ImageMagick installed --- version 6.1.8 -- and the executables are present in /sw/bin.
I'm not sure how to tell Xtreme to look for it there.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Incidentally, the complaint about missing ImageMagick 6.0 seems spurious. I've investigated and found that I have exactly one version of ImageMagick installed --- version 6.1.8 -- and the executables are present in /sw/bin.
I'm not sure how to tell Xtreme to look for it there.
Ensure it is on your path, or in your preferences (when you've got it to run once, and then quit, you will have a .xaralx/preferences in your home directory), put this:
ImageMagickPath=/sw/bin/convert
replacing the existing line
Alex
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Initially it complained about something with fonts
That would be the "we haven't written the font manager interface for the Mac yet" bug :-) (actually I'm not sure why it shouldn't work if you have pango installed, as that's all we use...)
Quote:
Originally Posted by
gpetty
and then about not having ImageMagick 6.0, but these seemed not to be fatal errors.
Harmless
Quote:
Originally Posted by
gpetty
But then disaster .. I simply clicked on the drawing window, and the program complained about a "very serious error" and said that it would have to close. Fortunately, it gave me the opportunity to generate an error report, which I have attached here.
OK, interesting. I would guess that this is CCamView::GetFrame() (in HandleDragScrolling) returnning a NULL. That method is inherited from wxView, and as far as I can tell it isn't meant to do that (ever) for an MDI-esque wxView.
What happens if you start it from the command line (with Open I suppose) and pass it one of the designs? Does it render anything useful?
It might be better to have this discussion on the dev list (see http://www.xaraxtreme.org/community/) by the way, there are more Mac folks there. I'm not sure they are a huge amount further forward than you though...
Alex
-
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
Ensure it is on your path, or in your preferences (when you've got it to run once, and then quit, you will have a .xaralx/preferences in your home directory), put this:
ImageMagickPath=/sw/bin/convert
replacing the existing line
Alex
It is in my path ... for the shell I use (tchs). But I just realized I have no idea how the Finder passes paths to the applications it opens, since it (presumably) doesn't pay any attention to my preferred shell.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
abligh
What happens if you start it from the command line (with Open I suppose) and pass it one of the designs? Does it render anything useful?
Assuming I did it correctly ("open XaraLX.app"), it does the following:
1) brings up the splash logo
2) provides only two headings on the top menu bar: XaraLX and Help (this is in contrast to the case that I open it by clicking on the icon, when I got a full suite of menus)
3) stubbornly fails to quit when told to do so.
4) chews up CPU cycles until killed from the command line.
Quote:
It might be better to have this discussion on the dev list (see
http://www.xaraxtreme.org/community/) by the way, there are more Mac folks there. I'm not sure they are a huge amount further forward than you though...
Alex
Fair enough .. I 'll check it out.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
Interesting. When I installed Fink + Fink Commander yesterday, I don't recall it pointing out any of this when I fired it up for the first time. I'm new to Macs (as of a few days ago), but so far at least, my experience had been that when you install a new (pre-compiled) program, it runs, and there's no need to dig into documentation unless you run across something you don't understand. In every obvious respect at least, Fink Commander had been working fine for me so far.
fink should explain this to you on its first run, and I would imagine that Fink Commander should as well, if you think that this was not happening for you, and you installed fink following the fink instructions, then this sounds like a defect in fink, and you you should submit it as a bug to fink .
See the First Time Installation guide for fink.
Yes, the Mac interface prides itself on the ease of installing programs, and their being highly usable without early recourse to manuals or online help. Whether this can be readily transferred to libraries such as wxWidgets or programmers' tools such as fink is a question that is still not totally solved...
Quote:
Originally Posted by
gpetty
Yes. It's what I've been using for 20 years, and no one had ever offered a reason why I should change. It gave me Emacs-style command-line editing and other benefits before other shells I knew about had that. If there's another shell (bash?) that I'd be better off with, I'm certainly willing to consider it, as long as the change isn't too painful.
I was asking because the syntax needed in .rc files for the csh/tcsh differs from bash. bash is the more popular, and Apple switched the default from tcsh to bash with Panther. Someone is only likely to be using tcsh if they have deliberately set things that way, and I thought that it was more likely that I had misunderstood something. Sorry if my enquiry caused offence.
Note that you will be needed to look at a command like
Code:
source /sw/bin/init.csh
and not the one I erroneously quoted.
-
Re: MacOS X building instructions
Quote:
Originally Posted by
gpetty
... solving with the following ...
Code:
% sudo ln -s /Users/gpetty/wx/v263/build-unicode-debug/lib/libwx_macud-2.6.0.dylib /usr/local/lib/libwx_macud-2.6.0.dylib
'Installing' by making a symbolic link will work, but if you are willing to modify your system to that degree, why not use the target to properly install your wxWidgets. This will make several things simpler for you.
Quote:
Originally Posted by
gpetty
make[1]: *** No rule to make target `../wxOil/xrc/xaralx.po', needed by `XaraLX.pot'. Stop.
I had that difficulty with xaralx.po, and I copied a working version of that file to the place from whence it seemed to be missing. It is possible that the Makefiles do not properly account for OBJDIR builds, and if one of us can establish a reproducible case, then it should be reported as a bug.
Ben.