I'm having a build issue. This is what I did:

- go into thirdparty/hdfgroup, build and install it
- clone the hds-v5 repo, build and install it
- back in starlink, git checkout hdsv5
- go into libraries/hds-v4, build and install it
- go into libraries/hds, build and install it

but making of libraries/hds would only work if I first did:

setenv CFLAGS -DHDS_INTERNAL_INCLUDES

Without this, I get things like:

In file included from hdsFind.c:46:0:
hds.h:980:10: error: unknown type name 'HDSWild'
 hdsEwild(HDSWild *iwld, int *status);

The version of hds_types.h installed by hds_v4 does not include a
definition of HDSWild, and this is the version that gets used when
building hds unless I do the above setenv.

What am I doing wrong?

David

On 3 November 2014 19:15, Peter W. Draper <[log in to unmask]> wrote:
>
> Thanks, the build is now back underway.
>
>
> On Mon, 3 Nov 2014, Tim Jenness wrote:
>
>> On Mon, Nov 3, 2014 at 10:24 AM, Tim Jenness <[log in to unmask]>
>> wrote:
>>       Ok. I'm awake now.
>> For some reason I don't understand, Brian never put those variants
>> into the HDS implementation. Trivial to add them of course, so I'll do
>> that. hds_select.c is dynamically generated from the hds.h file which
>> lists them. I'll also fix the hdsFind problem -- that's currently a C
>> wrapper around the fortran so should be skipped by hds_select.c.
>>
>> I really should turn the lazy linker off on the Mac...
>>
>>
>> On Mon, Nov 3, 2014 at 9:53 AM, Peter W. Draper
>> <[log in to unmask]> wrote:
>>       On Mon, 3 Nov 2014, Tim Jenness wrote:
>>
>>             On Mon, Nov 3, 2014 at 7:27 AM, Peter W.
>>             Draper <[log in to unmask]> wrote:
>>                   On Mon, 3 Nov 2014, Peter W. Draper
>>             wrote:
>>
>>                               As many of you know, I've
>>             recently been working on a "brand new"
>>                               implementation of HDS with
>>             this new version (version 5) based on top
>>                               of
>>                               HDF5 rather than be an
>>             evolution of the existing HDS library.
>>
>>                               I've got an almost complete
>>             implementation of the HDS API using HDF5
>>                               and you can find that
>>             at https://github.com/Starlink/hds-v5 -- it
>>                               should build and pass tests
>>             although it does require some Starlink
>>                               libraries installed because
>>             I was too lazy to reimplement stuff from
>>                               ONE
>>                               and recalculate bad values
>>             from PRM (and CNF is needed so that the
>>                               pointers created by the
>>             library can be used in Fortran code).
>>
>>
>>                         Must be some missing commits. I
>>             played around and got all the various HDS/HDF
>>                         libraries to build, but PCS will
>>             not build reporting:
>>
>>                         libhds.so: error: undefined
>>             reference to 'datGet1W_v4'
>>                         libhds.so: error: undefined
>>             reference to 'datGet1W_v5'
>>                         libhds.so: error: undefined
>>             reference to 'datGet1UW_v4'
>>                         libhds.so: error: undefined
>>             reference to 'datGet1UW_v5'
>>                         libhds.so: error: undefined
>>             reference to 'hdsFind_v4'
>>                         libhds.so: error: undefined
>>             reference to 'hdsFind_v5'
>>
>>
>> These should now resolve properly.
>>
>> Now back to trying to build a full Starlink with this working on Yosemite.
>> My main problem is that perl/Tk doesn't like /opt/X11 as the only place
>> for
>> X11 to be.
>>
>> --
>> Tim Jenness
>>
>>
>>
>
> --
> Peter W. Draper, http://astro.dur.ac.uk/~pdraper