Conflict with HDF5 libraries

Conflict with HDF5 libraries

[Mark Patterson]

Hello,

I've run into a conflict between guile (1.8.5) and HDF5 (1.8.1) on  
Fedora 10. I'll post on both mailing lists as I'm not sure who is in  
the best position to fix it.

HDF5 H5public.h near line 127 has:
   #if H5_SIZEOF_LONG_LONG>0
   #   define long_long    long long
   ... snip ...
   #endif
which is still present in the latest 1.8.2 release.

GUILE scmconfig-64.h near line 83 has:
   typedef long long long_long;
I tracked the origin of this line to gen-scmconfig.c, line 287 and it  
is present in the recent 1.8.6 release.

If HDF5 is loaded before guile, the typedef becomes:
   typedef long long long long
which confuses gcc (and me). As a temporary fix, I added:
   #undef long_long
just before the typedef in scmconfig-64. It is not clear to me which  
approach for dealing with long_long is correct or how they can be made  
to play well together.

I was trying to build MPB (http://ab-initio.mit.edu/wiki/index.php/ 
MPB) which is a nice piece of software that requires both guile and  
HDF5.

Thank you,
Mark Patterson

Re: Conflict with HDF5 libraries

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Patterson wrote:
> Hello,
> 
> I've run into a conflict between guile (1.8.5) and HDF5 (1.8.1) on
> Fedora 10. I'll post on both mailing lists as I'm not sure who is in the
> best position to fix it.

I don't see any other mailing lists.

> HDF5 H5public.h near line 127 has:
>   #if H5_SIZEOF_LONG_LONG>0
>   #   define long_long    long long
>   ... snip ...
>   #endif
> which is still present in the latest 1.8.2 release.

C macros suck. Why not change this to what guile uses?

typedef long long long_long;

I think that should do it.

> GUILE scmconfig-64.h near line 83 has:
>   typedef long long long_long;
> I tracked the origin of this line to gen-scmconfig.c, line 287 and it is
> present in the recent 1.8.6 release.
> 
> If HDF5 is loaded before guile, the typedef becomes:
>   typedef long long long long
> which confuses gcc (and me). As a temporary fix, I added:
>   #undef long_long
> just before the typedef in scmconfig-64. It is not clear to me which
> approach for dealing with long_long is correct or how they can be made
> to play well together.
> 
> I was trying to build MPB (http://ab-initio.mit.edu/wiki/index.php/MPB)
> which is a nice piece of software that requires both guile and HDF5.
> 
> Thank you,
> Mark Patterson

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmKtmMACgkQp/VmCx0OL2xgFACgtyUw3d20hGBLoIXx58qX6kPw
RtAAnjl1f0zsyc2f/kuxb8yYHWmXXkEg
=vH+p
-----END PGP SIGNATURE-----

Re: Conflict with HDF5 libraries

[Ken Raeburn]

On Feb 4, 2009, at 12:21, Mark Patterson wrote:
> Hello,
>
> I've run into a conflict between guile (1.8.5) and HDF5 (1.8.1) on  
> Fedora 10. I'll post on both mailing lists as I'm not sure who is in  
> the best position to fix it.

If they're not using package-specific prefixes on symbol names, I'd  
suggest both of them should be fixed...

Ken

Re: Conflict with HDF5 libraries

[Ludovic Courtès]

Hello,

Sorry for the late reply.

Mark Patterson <mpatterson@physics.queensu.ca> writes:

> GUILE scmconfig-64.h near line 83 has:
>   typedef long long long_long;
> I tracked the origin of this line to gen-scmconfig.c, line 287 and it
> is present in the recent 1.8.6 release.

As you may have noticed, this is enclosed in:

  #if (SCM_ENABLE_DEPRECATED == 1)

I.e., Guile 1.8 configured with `--disable-deprecated' doesn't have this
problem.

I suggest that we leave it in the 1.8 series for compatibility and
remove it altogether in the next stable series.  Opinions?

Thanks,
Ludo'.

Re: Conflict with HDF5 libraries

[Andy Wingo]

On Sat 21 Mar 2009 17:14, ludo@gnu.org (Ludovic Courtès) writes:

> Mark Patterson <mpatterson@physics.queensu.ca> writes:
>
>>   typedef long long long_long;
>
> I suggest that we leave it in the 1.8 series for compatibility and
> remove it altogether in the next stable series.  Opinions?

Sounds good to me.

Andy
-- 
http://wingolog.org/