Problem in compiling Xara 0.5 b1199

[Dominus]

>Do you have a file: binreloc.m4 ?
Yes, I do.

>Are you using an experimental version of gcc?
No, I am not. I use Gcc ver 4.1.0, which goes by default in Suse 10.1

So, the problem seems to be related to libxml, does not it? And what about whWidgets warning messages in the output of make? Is there a chance that I failed to build wxWidgets correctly?

[BPFowler]

>Do you have a file: binreloc.m4 ?
Yes, I do.

In that case, are you able to work out why you were not picking up the AM_BINRELOC macros. Perhaps this has suddently started to work! This is the third report that I have seen on this topic, and I have no idea what is happening!

>Are you using an experimental version of gcc?
No, I am not. I use Gcc ver 4.1.0, which goes by default in Suse 10.1

I am using 4.0 and, IIRC, 3.3. It is possible that gcc 4.10 is producing more warnings and error messages in the case of code that is just 'over the edge' rather than close to ther edge. You may want to take this to developers' list to find out if anybody else is seeing this. If any of the messages correspond to code that has an easy and obviously correct fix, then you might want to post the patches as well!

So, the problem seems to be related to libxml, doesn't it? And what about wxWidgets warning messages in the output of make? Is there a chance that I failed to build wxWidgets correctly?

Your build is probably OK. The type punned messages are probably harmless, but they do mean that you have allowed the compiler and the optimiser to make assumptions about the alignment or life span of variables and that correct code cannot be guaranteed.

You might want to look on the wx list.

My guess is that we will have to move onto a later version of wxWidgets rather soon ...

Ben

[abligh]

I have recently fixed the type-punned pointer stuff in svn.

One potential problem with the binreloc macro was also fixed a couple of
days ago (it didn't like being directly included).

Beyond that, normally the absence of macros which appear to be on disk (and some of the autopoint problems) boil down to there being two versions of one of the autoxxxx tools being present on the system, the wrong one being run, which is looking in the wrong directory of shared macros. You can point at specific versions of the macros like this:

AUTOCONF=/usr/somewhere/bin/autoconf-9.9.99 autoreconf -f -i -s
(etc.)

Alex

[abligh]

And Dominus' /real/ problem is some sort of libxml API compatibility problem. I /think/ that's been fixed too.