> ------------------------------ > > Date: Thu, 23 Aug 2018 08:04:15 +0100 > From: Daniel P. Berrangé <berrange@xxxxxxxxxx> > Subject: Re: libgsf build help - MinGW edition > To: Development discussions related to Fedora > <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Message-ID: <20180823070415.GA23703@xxxxxxxxxx> > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/HPTOJ5ZTZOQGJARQOJF42I4W4MPVYBPQ/
