aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
blob: aca1ef106e9f65addb1e9175a6b2ea9113764c43 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
when enabling the cgi wrapper I get,


generating wrappers..
"/var/www/cgi-bin/ikiwiki.cgi.c", line 91: warning: implicit function declaration: flock
"/var/www/cgi-bin/ikiwiki.cgi.c", line 91: undefined symbol: LOCK_EX
cc: acomp failed for /var/www/cgi-bin/ikiwiki.cgi.c
failed to compile /var/www/cgi-bin/ikiwiki.cgi.c


 cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12


I don't know enough C to provide a patch, but from googling it, people seem to be suggesting fcntl has an alternative.


-----


changing

    if (lockfd != -1 && flock(lockfd, LOCK_EX) == 0) {
   

to read

    if (lockfd != -1 && lockf(lockfd, F_LOCK,0) == 0) {


in IkiWiki/Wrapper.pm  lets it compile, according to
http://man-wiki.net/index.php/3:lockf "On  Linux, this call is just an
interface for fcntl(2)"  does this seem like a sensible fix?a

> Don't see why not. flock was used only because it's being used
> in the same file for testing some other locks.
> 
> While lockf's fcntl locks are not inherited across a fork,
> that doesn't matter for this lock, which is only used to
> prevent more than one ikiwiki perl process being run at a time.
> Nor is there any need to be compatible with some other user of this
> lock; it's only checked in one place. [[applied|done]]
> --[[Joey]]