Re: [Pan-users] Small portability issue

[Duncan]

Rhialto posted on Wed, 09 May 2012 18:25:06 +0200 as excerpted:

>   CXX    mime-utils.o
> mime-utils.cc: In function 'char* pan::__g_mime_iconv_strndup
>       (__tag_iconv_t*, const char*, size_t, const char*)':
> mime-utils.cc:80: error: invalid conversion from 'char**'
>       to 'const char**'
> mime-utils.cc:80: error:   initializing argument 2 of 'size_t
>        iconv(__tag_iconv_t*, const char**, size_t*, char**, size_t*)'
> gmake[3]: *** [mime-utils.o] Error 1
> gmake[3]: Leaving directory `[]/pan/work.x86_64/pan-0.137/pan/usenet-utils'

> That line reads
> 
>       converted = iconv (cd, (char **) &inbuf, &inleft, &outbuf, &outleft);
> 
> and it compiles if I remove that cast (since inbuf is already a const
> char *).
> 
> Are there different versionf of iconv requiring different argument
> types? If so, configure should check for it, if they are so
> incompatible.

No expert here, but AFAIK from my gentoo experience (lots of compiling...
and dealing with errors like that especially when I get impatient and
unmask a new version of gcc or whatever before the gentoo tree is
fully patched for it), it's more likely to be gcc versions doing it.
Newer gccs are normally stricter than older versions, making things
errors that weren't, before.  So especially if you have a newer gcc, or
if you have a seriously patched version (like Apple's old version that
they can't upgrade from as they don't want the gplv3 changes)...

Or of course if you're using clang or Intel's ICC or whatever...

That could be your problem.

glibc, binutils, libtool, etc... the normal toolchain, basically, can
trigger similar problems.

> ---------
> 
> About gnome-keyring: the configure script checks for version 3.2.0 or
> higher, but pkgsrc has only version 2.32.0. Is that really too low or
> would it work? I tried the naive way (just reducing the required version
> in configure), and althought it built, it core dumped as soon as I
> opened the server settings window.


That'd be expected.  It's looking for the gnome-keyring from gnome3
(3.2+), while you're force-feeding it the gnome2 version.  So it barfs!

That's a new feature, obviously only compatible with gnome3 at this
point.  HM /might/ backport it, but if I were him I'd probably not.
It's a new feature anyway so no loss of functionality, and it's optional,
easy enough to leave off, so I'd simply let people's normal upgrade
cycle bring them the new feature when they do gnome3.

> ---------
> 
> If I configure --disable-nls, then still a lot of things are checked for
> intltool amd msg*, such as
> 
> checking whether NLS is requested... no
> checking for intltool >= 0.40.6... 0.50.2 found
> checking for intltool-update...
> /home/rhialto/tmp/news/pan/work.x86_64/.tools/bin/intltool-update
> checking for intltool-merge...  
> /home/rhialto/tmp/news/pan/work.x86_64/.tools/bin/intltool-merge
> checking for intltool-extract...  
> /home/rhialto/tmp/news/pan/work.x86_64/.tools/bin/intltool-extract
> checking for xgettext... /usr/bin/xgettext
> checking for msgmerge... /usr/bin/msgmerge
> checking for msgfmt...  
> /home/rhialto/tmp/news/pan/work.x86_64/.tools/bin/msgfmt
> checking for gmsgfmt...  
> /home/rhialto/tmp/news/pan/work.x86_64/.tools/bin/msgfmt
> 
> and later
> 
> gmake[2]: Entering directory 
> `/home/rhialto/tmp/news/pan/work.x86_64/pan-0.137/po'
> MSGFMT am.gmo
> MSGFMT ar.gmo
> MSGFMT az.gmo
> MSGFMT bg.gmo
> MSGFMT ca.gmo
> MSGFMT cs.gmo
> MSGFMT da.gmo
> ...
> 
> Does that make sense if I turned off localized messages?
> 
> I had down for previous versions that Pan needs libiconv and
> gettext-lib, but I gather that this is not true (any more). For iconv it
> seems to use gmime. Is that correct?

No idea but it's frustrating here, too.  English is all I read anyway.

But it /is/ kinda nice to have the occasional RtoL Hebrew or fancy Chinese
characters (as I occasionally see in sigs, etc) render properly in an
appropriate font, if installed.

But as I read only English I haven't dealt enough with i18n/l10n to
have a clue what's required for what.

> ---------
> 
> I've seen this a couple of times:
> 
> (pan:10688): Gtk-CRITICAL **: IA__gtk_tree_path_compare: assertion `a !=
> NULL' failed
> 
> but Pan seems to keep running anyway.

AFAIK, that's specifically due to the assertion catching the null-dereference
and handling it gracefully instead of triggering a segfault!  Not only are
crashes frustrating, but occasionally they're exploitable as well, so
such assertions and the error handling they trap too is very useful indeed!

> ---------
> 
> a little tool to check dependencies claims that there are various
> libraries being checked by configure that are not *direct* dependencies
> (that's what it thinks, at least; I'm not sure how it determines that).
> That should not be necessary, right?
> 
> $ verifypc
> verifypc: enchant not a direct dependency
> verifypc: gio-2.0 not a direct dependency
> verifypc: gio-2.0 not a direct dependency
> verifypc: glib-2.0 not a direct dependency
> verifypc: gmime-2.6 not found
> verifypc: gmodule-2.0 not a direct dependency
> verifypc: gobject-2.0 not a direct dependency
> verifypc: gthread-2.0 not a direct dependency

Indirect dependencies are likely dependencies of dependencies.  Libraries
pan does depend on in turn depend on other libs that pan doesn't itself
require.

On an end-user-built-and-rolling-update distribution like gentoo, such
dependencies and the "overlinking" they often result in (pan linking not
just to its direct deps, but to the indirect deps as well) can cause
serious levels of needless rebuilding when an indirect dep is upgraded.
A directly linked dep may well have to be rebuilt, if the ABI 
(application binary interface, the built-binary interface) changed even
if the API (application program interface, the coded to interface) didn't,
and such indirect deps, if still directly linked in as if they're
actually used directly, can cause "rebuild amplification", since
often many higher level apps and libs depend on mid-level libs that
really /should/ be the only thing needing rebuilt.

There's a linker flag, --as-needed, that tells the linker to be
more conservative with what it links against, actually tracking it
and only adding binary-level dependencies if they're directly
coded against.  GCC in turn takes the -Wl,--as-needed parameter, -Wl
telling gcc to pass what follows to the linker.  These days,
gentoo builds with --as-needed by default, but it wasn't always
so, and it took a lot of testing and filing bugs with upstream
projects to get their linking fixed, to get it so --as-needed
generally works without additional gentoo patching, these days.
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman