datatype_export.c:1903:19: error: storage size of ‘myenum’ isn’t known

[tillea]

Hi,
the Debian packaged version of hdf5r received a [bug report about a build time error. While this bug report is against version 1.3.5 I've just verified that the same error also occurs in the just released version 1.3.6. The build happens when building against the Debian packaged libhdf5 1.10.8.

make[1]: Entering directory '/build/r-cran-hdf5r-1.3.6+dfsg/src'
cp 1_10_3/*.c 1_10_3/*.h .
gcc -I"/usr/share/R/include" -DNDEBUG -I/usr/include/hdf5/serial    -D__USE_MINGW_ANSI_STDIO   -fpic  -g -O2 -ffile-prefix-map=/build/r-base-J8F88F/r-base-4.2.1=. -fstack-           protector-     strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c const_export.c -o const_export.o
gcc -I"/usr/share/R/include" -DNDEBUG -I/usr/include/hdf5/serial    -D__USE_MINGW_ANSI_STDIO   -fpic  -g -O2 -ffile-prefix-map=/build/r-base-J8F88F/r-base-4.2.1=. -fstack-           protector-     strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c datatype_export.c -o datatype_export.o
datatype_export.c: In function 'create_DT_H5R_type_t':
datatype_export.c:1903:19: error: storage size of 'myenum' isn't known
 1903 |   enum H5R_type_t myenum;
      |                   ^~~~~~
datatype_export.c:1904:41: error: invalid application of 'sizeof' to incomplete type 'enum H5R_type_t'
 1904 |   hid_t base_type = get_h5_equiv(sizeof(enum H5R_type_t), issigned(enum H5R_type_t));
      |                                         ^~~~
In file included from datatype_export.c:20:
datatype_export.c:1904:73: error: conversion to incomplete type
 1904 |   hid_t base_type = get_h5_equiv(sizeof(enum H5R_type_t), issigned(enum H5R_type_t));
      |                                                                         ^~~~~~~~~~
datatype_export.h:29:24: note: in definition of macro 'issigned'
   29 | #define issigned(t) (((t)(-1)) < 0)
      |                        ^
make[1]: *** [/usr/lib/R/etc/Makeconf:168: datatype_export.o] Error 1

Kind regards, Andreas.

[hhoeflin]

Thanks for the bug report, however I have very little time to maintain this project as I am not using it myself anymore. Happy to merge a PR.

[nileshpatra]

Hi @hhoeflin

As far as I checked the hdf5 code, I am seeing "H5R_type_t" to be already
an enum, and I am not sure why this is defined again as enum here in hdf5r code.

I also looked at the previous snapshot of 1_10_0 in this very repo and and there, I do not see an enum
attached to H5R_type_t see here

I have a small patch that addresses this here and makes it as per prev version. It builds and also passes the tests in our CI, but I am not completely sure if this is sensible to do. So I'd be very very happy if you could let me know?

Cheers!

[hhoeflin]

I have to get back and dive deeper what caused this change between 1.10.0 and 1.10.3. This is some auto-generated code that I wrote a long time back. What makes me hesitate is that this code has been active since HDF5 1.10.3, hasn't changed in 3 years, and has not caused any issues since then AFAIK, so not sure why the system starts failing now.

…

On Fri, Sep 23, 2022 at 1:21 PM NILESH ***@***.***> wrote: Hi @hhoeflin <https://github.com/hhoeflin> As far as I checked the hdf5 code, I am seeing "H5R_type_t" to be already an enum, and I am not sure why this is defined again as enum here <https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_3/datatype_export.c#L1903> in hdf5r code. I also looked at the previous snapshot of 1_10_0 in this very repo and and there, I do not see an enum attached to H5R_type_t see here <https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_0/datatype_export.c#L1867> I have a small patch that addresses this here <https://salsa.debian.org/r-pkg-team/r-cran-hdf5r/-/blob/master/debian/patches/fix-hdf.patch> and makes it as per prev version. It builds and also passes the tests in our CI, but I am not completely sure if this is sensible to do. So I'd be very very happy if you could let me know? Cheers! — Reply to this email directly, view it on GitHub <#192 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASGMYTRKE5D3EZFUBMS5K3V7WHFNANCNFSM6AAAAAAQSVRQKM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hhoeflin]

This could be caused by a code change in HDF5 1.10.8 compared to the previous versions, but I haven't looked into this. I would not want to change the code for older versions of HDF5 as this has worked so far.

…

On Fri, Sep 23, 2022 at 1:31 PM Holger Hoefling ***@***.***> wrote: I have to get back and dive deeper what caused this change between 1.10.0 and 1.10.3. This is some auto-generated code that I wrote a long time back. What makes me hesitate is that this code has been active since HDF5 1.10.3, hasn't changed in 3 years, and has not caused any issues since then AFAIK, so not sure why the system starts failing now. On Fri, Sep 23, 2022 at 1:21 PM NILESH ***@***.***> wrote: > Hi @hhoeflin <https://github.com/hhoeflin> > > As far as I checked the hdf5 code, I am seeing "H5R_type_t" to be already > an enum, and I am not sure why this is defined again as enum here > <https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_3/datatype_export.c#L1903> > in hdf5r code. > > I also looked at the previous snapshot of 1_10_0 in this very repo and > and there, I do not see an enum > attached to H5R_type_t see here > <https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_0/datatype_export.c#L1867> > > I have a small patch that addresses this here > <https://salsa.debian.org/r-pkg-team/r-cran-hdf5r/-/blob/master/debian/patches/fix-hdf.patch> > and makes it as per prev version. It builds and also passes the tests in > our CI, but I am not completely sure if this is sensible to do. So I'd be > very very happy if you could let me know? > > Cheers! > > — > Reply to this email directly, view it on GitHub > <#192 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AASGMYTRKE5D3EZFUBMS5K3V7WHFNANCNFSM6AAAAAAQSVRQKM> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[nileshpatra]

Of all changes, in src/ dir, only 'src/1_10_3' has an enum with H5R_type_t. The versions before and after this have it removed/no enum with H5R_type_t. Maybe that's something to consider. I am not sure if it's relevant info for you, but in debian, the current version of hdf5 is 1.10.8 and the compiler is gcc-12. I'd be grateful if you could look at it whenever your time allows. Thanks!

On 23 September 2022 5:08:49 pm IST, Holger Hoefling ***@***.***> wrote: This could be caused by a code change in HDF5 1.10.8 compared to the previous versions, but I haven't looked into this. I would not want to change the code for older versions of HDF5 as this has worked so far. On Fri, Sep 23, 2022 at 1:31 PM Holger Hoefling ***@***.***> wrote: > I have to get back and dive deeper what caused this change between 1.10.0 > and 1.10.3. This is some auto-generated code that I wrote a long time back. > What makes me hesitate is that this code has been active since HDF5 1.10.3, > hasn't changed in 3 years, and has not caused any issues since then AFAIK, > so not sure why the system starts failing now. > > On Fri, Sep 23, 2022 at 1:21 PM NILESH ***@***.***> wrote: > >> Hi @hhoeflin <https://github.com/hhoeflin> >> >> As far as I checked the hdf5 code, I am seeing "H5R_type_t" to be already >> an enum, and I am not sure why this is defined again as enum here >> <https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_3/datatype_export.c#L1903> >> in hdf5r code. >> >> I also looked at the previous snapshot of 1_10_0 in this very repo and >> and there, I do not see an enum >> attached to H5R_type_t see here >> <https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_0/datatype_export.c#L1867> >> >> I have a small patch that addresses this here >> <https://salsa.debian.org/r-pkg-team/r-cran-hdf5r/-/blob/master/debian/patches/fix-hdf.patch> >> and makes it as per prev version. It builds and also passes the tests in >> our CI, but I am not completely sure if this is sensible to do. So I'd be >> very very happy if you could let me know? >> >> Cheers! >> >> — >> Reply to this email directly, view it on GitHub >> <#192 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AASGMYTRKE5D3EZFUBMS5K3V7WHFNANCNFSM6AAAAAAQSVRQKM> >> . >> You are receiving this because you were mentioned.Message ID: >> ***@***.***> >> > -- > Reply to this email directly or view it on GitHub: #192 (comment) You are receiving this because you commented. Message ID: ***@***.***>

-- Best, Nilesh

[hhoeflin]

Thanks I will. Do you know if 1.10.7 works for you? I looked into the code definition, and the issue seems to be that they have been going back and forth on the definition of H5R_type_t - which is why you see the code changes between 1.10.0 and 1.10.3 as well as back on 1.12.0. hdf5/src/H5Rpublic.h at 0f4e080309d09a5f0d6911efce064ee487a759be · HDFGroup/hdf5 · GitHub <https://github.com/HDFGroup/hdf5/blame/0f4e080309d09a5f0d6911efce064ee487a759be/src/H5Rpublic.h> and hdf5/src/H5Rpublic.h at cf25524474a4012a70cc2bdb6eaddc402b5ea136 · HDFGroup/hdf5 · GitHub <https://github.com/HDFGroup/hdf5/blame/cf25524474a4012a70cc2bdb6eaddc402b5ea136/src/H5Rpublic.h> inserting the 'H5R_type_t' after 'enum' which requires my code change. This has apparently changed 3 years ago, I think in 1.10.6. My old CI is unfortunately not working anymore, so will have to invest some additional time to get this going again before I can do a detailed investigation for a fix. Thanks for pointing this out.

…

On Fri, Sep 23, 2022 at 1:51 PM NILESH ***@***.***> wrote: Of all changes, in src/ dir, only 'src/1_10_3' has an enum with H5R_type_t. The versions before and after this have it removed/no enum with H5R_type_t. Maybe that's something to consider. I am not sure if it's relevant info for you, but in debian, the current version of hdf5 is 1.10.8 and the compiler is gcc-12. I'd be grateful if you could look at it whenever your time allows. Thanks! On 23 September 2022 5:08:49 pm IST, Holger Hoefling ***@***.***> wrote: >This could be caused by a code change in HDF5 1.10.8 compared to the > >previous versions, but I haven't looked into this. I would not want to > >change the code for older versions of HDF5 as this has worked so far. > > > >On Fri, Sep 23, 2022 at 1:31 PM Holger Hoefling ***@***.***> wrote: > > > >> I have to get back and dive deeper what caused this change between 1.10.0 > >> and 1.10.3. This is some auto-generated code that I wrote a long time back. > >> What makes me hesitate is that this code has been active since HDF5 1.10.3, > >> hasn't changed in 3 years, and has not caused any issues since then AFAIK, > >> so not sure why the system starts failing now. > >> > >> On Fri, Sep 23, 2022 at 1:21 PM NILESH ***@***.***> wrote: > >> > >>> Hi @hhoeflin <https://github.com/hhoeflin> > >>> > >>> As far as I checked the hdf5 code, I am seeing "H5R_type_t" to be already > >>> an enum, and I am not sure why this is defined again as enum here > >>> < https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_3/datatype_export.c#L1903 > > >>> in hdf5r code. > >>> > >>> I also looked at the previous snapshot of 1_10_0 in this very repo and > >>> and there, I do not see an enum > >>> attached to H5R_type_t see here > >>> < https://github.com/hhoeflin/hdf5r/blob/master/src/1_10_0/datatype_export.c#L1867 > > >>> > >>> I have a small patch that addresses this here > >>> < https://salsa.debian.org/r-pkg-team/r-cran-hdf5r/-/blob/master/debian/patches/fix-hdf.patch > > >>> and makes it as per prev version. It builds and also passes the tests in > >>> our CI, but I am not completely sure if this is sensible to do. So I'd be > >>> very very happy if you could let me know? > >>> > >>> Cheers! > >>> > >>> — > >>> Reply to this email directly, view it on GitHub > >>> <#192 (comment) >, > >>> or unsubscribe > >>> < https://github.com/notifications/unsubscribe-auth/AASGMYTRKE5D3EZFUBMS5K3V7WHFNANCNFSM6AAAAAAQSVRQKM > > >>> . > >>> You are receiving this because you were mentioned.Message ID: > >>> ***@***.***> > >>> > >> > > > > > >-- > >Reply to this email directly or view it on GitHub: > >#192 (comment) > >You are receiving this because you commented. > > > >Message ID: ***@***.***> -- Best, Nilesh — Reply to this email directly, view it on GitHub <#192 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASGMYQCJODXYGFNRVB6TBLV7WKUZANCNFSM6AAAAAAQSVRQKM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nileshpatra]

On 23 September 2022 5:40:17 pm IST, Holger Hoefling ***@***.***> wrote: Thanks I will. Do you know if 1.10.7 works for you?

Probably not, as the version in debian is already 1.10.8 and it's unlikely to go back in time.

I looked into the code definition, and the issue seems to be that they have been going back and forth on the definition of H5R_type_t - which is why you see the code changes between 1.10.0 and 1.10.3 as well as back on 1.12.0. [...] inserting the 'H5R_type_t' after 'enum' which requires my code change. This has apparently changed 3 years ago, I think in 1.10.6.

I see, thanks. This is quite helpful. For now I think I'll apply a patch to the debian package to fix the issue at that end. -- Best, Nilesh

[zingmars]

I'm running into this on the official R docker image. What would be the workaround for this until this issue is fixed?

[hhoeflin]

Should be fixed on master and on the way to CRAN as version 1.3.7