------------------------------
Date: Thu, 23 Aug 2018 08:04:15 +0100
From: Daniel P. Berrangé <berrange(a)redhat.com>
Subject: Re: libgsf build help - MinGW edition
To: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
Message-ID: <20180823070415.GA23703(a)redhat.com>
Content-Type: text/plain; charset=utf-8
On Wed, Aug 22, 2018 at 10:06:17PM -0500, Greg Hellings wrote:
> Recent versions of libgsf (since 1.14.43) have begun to fail to build in
> MinGW environments. The error is straightforward enough - a function
> signature definition differs between its forward declaration and its
> implementation. But I don't see any clear way that it differs. The same
> code compiles cleanly in the native libgsf with nary a hiccup. The specific
> error is as follows:
>
> ../../gsf/gsf-input.c:632:1: error: conflicting types for
> 'gsf_input_set_modtime_from_stat'
> gsf_input_set_modtime_from_stat (GsfInput *input,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from ../../gsf/gsf.h:54,
> from ../../gsf/gsf-input.c:24:
> ../../gsf/gsf-input-impl.h:67:10: note: previous declaration of
> 'gsf_input_set_modtime_from_stat' was here
> gboolean gsf_input_set_modtime_from_stat (GsfInput *input,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> make[2]: *** [Makefile:706: gsf-input.lo] Error 1
>
> Anyone know what could be different here vs in native builds? I've pushed a
> copy of my development branch to my own fork of the mingw-libgsf repo (
>
https://src.fedoraproject.org/fork/greghellings/rpms/mingw-libgsf). It
> lives in the branch named 1_14_44. There is nothing about it that should
> differ in compilation between f28 and current Rawhide.
>
> I'm definitely stumped at this. The two declarations look the same to me,
> but obviously there's something hidden in the bowels of these headers that
> changes the definitions between those two places. Any help would be
> appreciated.
Given that the two declarations are identical, the difference must be in
the way they are being interpreted. The likely candidate for the cause
is the "struct stat" parameter.
Looking at the code in gsf-input.c, it pulls in gsf.h which pulls in
gsf-input-impl.h with one definition of the struct.
At this point, however, 'sys/stat.h' has not been included yet, so the
'struct stat' is likely an undefined type.
Later gsf-input.c includes 'sys/stat.h' and then after that the second
declaration of the function is done, which now sees the 'struct stat'
type.
IOW, moving the sys/stat.h include to the top of gsf-input.c should
fix this problem, or adding it to the top of gsf.h is probably even
better.
The reason for the difference is probably the glib.h header file.
I expect that on native builds, it ends up pulling in a definition
of 'struct stat' from somewhere, while this does not happen on
Mingw platforms.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|
Your advice was perfect. When I then went to report the bug to libgsf
along with my hack-a-patch I found a pending MR for the change that
was better. Thanks!
--Greg