pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Small portability issue


From: Rhialto
Subject: Re: [Pan-users] Small portability issue
Date: Wed, 9 May 2012 18:25:06 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Another thing I encountered:

Making all in usenet-utils
gmake[3]: Entering directory 
`/home/rhialto/tmp/news/pan/work.x86_64/pan-0.137/pan/usenet-utils'
  CXX    filter-info.o
  CXX    rules-info.o
  CXX    gnksa.o
  CXX    message-check.o
  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 
`/home/rhialto/tmp/news/pan/work.x86_64/pan-0.137/pan/usenet-utils'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory 
`/home/rhialto/tmp/news/pan/work.x86_64/pan-0.137/pan'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/rhialto/tmp/news/pan/work.x86_64/pan-0.137'
gmake: *** [all] Error 2
*** Error code 2

Stop.
make: stopped in /mnt/vol1/rhialto/cvs/pkgsrc/news/pan

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.

---------

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.

---------

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?

---------

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.

---------

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

That's it for now.
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- There's no point being grown-up if you 
\X/ rhialto/at/xs4all.nl    -- can't be childish sometimes. -The 4th Doctor



reply via email to

[Prev in Thread] Current Thread [Next in Thread]