Re: MacOS X last lap

[Bill Northcott]

> > 1. src/collections/collections.m
> > as part of the compilation it makes a file collections.xm.  This file
> > appears to contain almost every line twice.  This spews a row of 
errors
> > and dies.  This error has been the same on every compiler I have 
tried.

> I know for sure I've seen that. I think it happens when gperf is not
> installed. I wish I could remember.

> > 2. src/defobj/HDF5Object.m
> > at lines 1045 and 1070 the following code appears:
> >   if (cdata->command == H5T_CONV_INIT)
> >     cdata->need_bkg = H5T_BKG_TEMP;
> >   else if (cdata->command == H5T_CONV_CONV)
> >
> > H5T_BKG_TEMP appears nowhere else in the source and is not replaced by 
the
> > precompiler, presumably the first conditional has not been true on 
other
> > platforms.  Any idea where H5T_BKG_TEMP should be defined and what 
it's
> > for.
> $ rpm -q hdf5
> hdf5-1.4.3-1RH73
> $ cd /usr/include
> $ grep H5T_CON H*
> address@hidden include]$ grep H5T_B H*
> H5Fpublic.h:    H5T_BKG_NO              = 0,    /*background buffer is
> not needed, send NULL */
> H5Fpublic.h:    H5T_BKG_TEMP    = 1,    /*bkg buffer used as temp

> > 3. src/defobj/defobj.m
> > in the intermediate file defobj.xm there is what appears to be an out 
of
> > context @end near the beginning.  The causes a parse error followed by
> > other problems and it dies.

> Too abstract for me

> >
> > 4. src/activity/activity.m
> > in the intermediate file activity.xm there is a parse error in line 6.
> >
> Don't these xm errors trace back to failures of gperf, sed, or emacs ?

Thanks for the HDF5 stuff.  We now know all the other errors were due to 
BSD sed, which was fixed by installing GNU sed, and the missing gperf as 
you surmised.

The current score is that after replacing sed and installing gperf, an FSF 
compiler can compile all the source code.  The Apple version of the same 
compiler crashes on ten of the programs.  The README.MacOSX on the cvs has 
been updated to reflect the state of game.

The current stopper is a failure linking libdefobj.la.  The make file is 
generating a link instruction with libavcall.la included twice. This 
appears to be an error in the Swarm configuration system.  I suspect that 
the gnu linker ignores the duplicate, which is why the bug has been missed 
before.  Apple's dyld linker does what it is told and then complains about 
duplicated symbols.

If I execute the link instruction by hand without the duplication, it 
works.  However, when I run make again it insists on running the 
instruction and fouling up.

I have one idea to fix it which I will try before I go to bed.

Bill Northcott

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.