pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] Latest HOTFIX commit fails to compile


From: Duncan
Subject: Re: [Pan-users] Latest HOTFIX commit fails to compile
Date: Mon, 14 Jan 2013 07:07:47 +0000 (UTC)
User-agent: Pan/0.140 (Chocolate Salty Balls; GIT 09d34ae /usr/src/portage/src/egit-src/pan2)

Heinrich Müller posted on Sun, 13 Jan 2013 11:28:01 +0100 as excerpted:

> Am 13.01.2013 01:29, schrieb walt:
>>
>> On 01/12/2013 12:28 PM, walt wrote:
>>> However, I'm still getting this compile error:
>>> pan/general/locking.h:50: undefined reference to `pan::Mutex::mutex'
>> I got it to compile by deleting the 'static' from locking.h:16 (which
>> you put there just three days ago) but decoding jpegs is still broken
>> so I know that isn't the right fix :(
>>
>> Any idea why the compiler is complaining about locking.h?
> the "static" is there because then the mutex is initialized. It could
> lead to erroneous behaviour if you just deleted it.
> I'll supply a fix for that.

FWIW, I just updated 09d34ae..2c870a4 and am seeing the same undefined 
mutex issue.  glib-2.34.3 if that makes a difference.  (I see you bumped 
the test from 2.34.1 to 2.34.2, which made me check glib version, but 
don't know what the significance of that bump was...)

Given that I've tomorrow off and was thinking about finally getting that 
NSP block account I've been talking about getting, finding out that my 
current pan build is subject to "erroneous behavior" isn't exactly the 
most thrilling news I could imagine ATM. =:^(  But as I should be 
sleeping already anyway, with a bit of luck, I'll wake up and find you 
fixed it. =:^)


Meanwhile, that error happened to be in a rather convenient spot to point 
out a rather worrying int/long-int warning immediately previous to it.  
The warning seems to have been there for awhile (back the four logrotate 
weeks' worth of emerge buildlogs I keep, anyway), so if it a live problem 
on amd64 (for all I know the two types are the same length on amd64) I 
don't seem to be triggering it often, but I've read enough bad-type-
conversion security-vuln tales to worry about it now that I'm actually 
looking at it:

post-ui.cc: In member function 'void pan::PostUI::update_filequeue_label
(GtkTreeSelection*)':
post-ui.cc:184:124: warning: format '%u' expects argument of type 
'unsigned int', but argument 4 has type 
'std::vector<pan::Task*>::size_type {aka long unsigned int}' [-Wformat]

-- 
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




reply via email to

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