MacOS X building instructions

[gpetty]

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.

[abligh]

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

[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, 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

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

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.

[BPFowler]

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.

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

[gpetty]

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

[gpetty]

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

[BPFowler]

[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:

source /sw/bin/init.sh

and instructions concerning the .rc files. (Are you really using the tsch?).

Ben

[gpetty]

[QUOTE=BPFowler;168440]

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:

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.

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

[BPFowler]

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

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

source /sw/bin/init.csh

and not the one I erroneously quoted.