Re: [Pan-devel] compile error from current git master head

[Jack]

On 9/6/21 17:07, Detlef Graef wrote:
> Am 06.09.21 um 20:45 schrieb Jack via Discussions of Pan source code
> hacking.:
>
> > Based on some of the posts from a month ago, I decided to try again to
> > get pan to compile for me - using the most recent tarball, and some of
> > the MRs specifically addressing compile issues.  After not getting very
> > far, and having the errors just seem to be more of those the MR I was
> > testing was trying to resolve, I looked again more carefully at the
> > repository, and noticed that there has actually been a good bit of
> > recent activity, committing many of those MRs.  So, I just git cloned
> > the repository and using slight adjustment to the ./configure line I had
> > previously used, I still get a compile error:
> >
> > make[3]: Entering directory '/usr/local/src/pan/pan/build/pan/usenet-utils'
> > x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../../pan/usenet-utils
> > -I../..  -I../../.. -I/usr/include/gmime-3.0 -D_LARGEFILE64_SOURCE
> > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > -I/usr/lib64/libffi/include -pthread -I/usr/include/libmount
> > -I/usr/include/blkid  -I/usr/include/glib-2.0
> > -I/usr/lib64/glib-2.0/include
> > -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26
> > -DGLIB_VERSION_MAX_ALLOWED=G_ENCODE_VERSION\(2,36\)    -g -O2 -c -o
> > mime-utils.o ../../../pan/usenet-utils/mime-utils.cc
> > ../../../pan/usenet-utils/mime-utils.cc: In function 'GMimeMessage*
> > pan::message_add_signed_part(const string&, const string&, GMimeMessage*)':
> > ../../../pan/usenet-utils/mime-utils.cc:1752:72: error: ordered
> > comparison of pointer with integer zero ('GMimeMultipartSigned*' {aka
> > '_GMimeMultipartSigned*'} and 'int')
> >   1752 |     if (g_mime_multipart_signed_sign (gpg_ctx, gmo, uid.c_str(),
> > &err) <0)
> >        |
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
> > ../../../pan/usenet-utils/mime-utils.cc: In function 'bool
> > pan::gpg_encrypt(const string&, const string&, GMimeMessage*,
> > GPtrArray*, bool)':
> > ../../../pan/usenet-utils/mime-utils.cc:1787:75: error: ordered
> > comparison of pointer with integer zero ('GMimeMultipartEncrypted*' {aka
> > '_GMimeMultipartEncrypted*'} and 'int')
> >   1786 |     if (g_mime_multipart_encrypted_encrypt(gpg_ctx, GMIME_OBJECT
> > (part), sign, uid.c_str(),
> >        |
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >   1787 |                                            GMIME_ENCRYPT_NONE,
> > rcp, &err) < 0)
> >        |
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
> > make[3]: *** [Makefile:454: mime-utils.o] Error 1
> >
> > I initially wondered if this was due to my use of gcc  11.2.0, but
> > switching back to 10.3.0 gave me a different error:
> >
> > undefined reference to `std::__throw_bad_array_new_length()'
> >
> > (Sorry I didn't copy more of the context.)  I was able to fix this by
> > prepending "CXXFLAGS=-std=c++14" to the configure line.  Compiled like
> > this, pan installs and runs, although my testing has been only minimal.
> >
> > Thinking further, I wonder if I'd end up with this second error with
> > gcc11, if I could get past the first errors.
> >
> > My best guess (without really understanding the code is that the result
> > of the call to g_mime_multipart_signed_sign is a pointer, so the
> > comparison will have to be changed - but I have no idea whether  != NULL
> > have the same result as the original < 0.
> >
> > Thanks for any suggestions.
> Please try this patch from my repo:
>
> https://gitlab.gnome.org/dgraef/pan/-/commit/3b35d8b00702f4a0d57e5ce6a95750d8c0dddb16
>
> It compiles, but I didn't really tested it.
>
> I had the same error on Fedora 34.
Thanks for the quick reply.  I actually just made that change locally.  
To truly test, I have to figure out when that code actually gets invoked 
- is it when posting a mime-type attachment, or trying to read one from 
a post?  I suppose I can put a debug output maybe a breakpoint in gdb, 
but that only helps if I actually do hit that code.  I also wonder if 
that change needs to also be applied to the else part of those ifdefs.  
I think the change is due to a newer gcc or perhaps std=c++ version, not 
directly to the gmime2 -> 3 change.  I have no idea when gmime3 will be 
sufficiently available to remove support for gmime2, but probably not 
very soon.