> 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
> 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: *** [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'
> 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
> 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.
> |: 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!
I'm preparing an update to gmsh-4.0.0. They not only bumped the soname,
but also renamed the library from libGmsh to libgmsh (case change).
Also, they declared large portions of the API as private, and introduced
new gmsh.h / gmshc.h / gmsh.h_cwrap headers instead. The private API is
still installable, but officially unsupported. I'll be providing a
gmsh-devel-private package for that. Similarly for python, there is now
a gmsh.py API file, with the previous gmshpy wrapper declared private
API, which I'll provide in a python3-gmsh-private package.
The only package depending on gmsh according to repoquery is getdp. I'll
look at adapting that package as necessary.
If all goes to plan, I'll land gmsh-4.0.0 this weekend.
I intend to remove minizip from the zlib package and replace it with a more
maintained fork . To preserve backwards compatibility and ease the
transition on maintainers of dependent packages, the idea is to provide
minizip-compat and minizip-compat-devel packages in the zlib minizip
Therefore, I would like to ask all maintainers of the packages depending on
minizip and/or minizip-devel to update their dependencies to minizip-compat
and minizip-compat-devel respectively.
For now this is just a "cosmetic" change without any breakages. However,
when all related packages will require minizip-compat I will build the new
minizip package with a soname bump.
Please keep in mind that the minizip-compat package is just a temporary
solution to give us some time and should be considered deprecated as soon
as I build the new minizip package.
Finally, here's a list of related packages:
Associate Software Engineer
Red Hat <https://www.redhat.com>
I just submitted a review request  for kcov  that I recently
discovered. It has no relation to Linux's kcov and is more akin to
lcov, except that all it needs is a binary with DWARF debuginfo
instead of requiring compile-time instrumentation.
I came across kcov when I was looking for a way to measure code
coverage in a Rust project and I'm impressed. It supposedly has a low
overhead, but so far I've been monitoring small single-threaded
programs so I can't really tell. I haven't tested python and shell
support, although I have cases where it would be relevant, but I don't
have time yet.
build on all main platforms so I may have to be granted an exception
from some group starting with an F. Been busy lately, I'm a little
behind on anything Fedora. If that's the case, please RTFM me a link
to the wiki, and if you want to take the review I'll gladly take one
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 (GsfInput *input,
In file included from ../../gsf/gsf.h:54,
../../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: *** [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 (
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