dovecot - May 2015 - FYI: dovecot (008632bdfd2c) compilation woes, and minor glitch regarding update-version.sh

Hi ?

Teemu Huovila <teemu.huovila at dovecot.fi> wrote:
> On 04/24/2015 10:00 PM, Michael Grimm wrote:
>> 1) I'm trying to compile a recent hg dovecot version (008632bdfd2c)
at a FBSD10-STABLE system without success:
[?]
>> fts-tokenizer-generic.c:214:18: error: use of undeclared identifier
'MidNum'
>>        if (uint32_find(MidNum, N_ELEMENTS(MidNum), c, &idx))
>>                        ^
>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>> 20 errors generated.
>> Makefile:591: recipe for target 'fts-tokenizer-generic.lo'
failed
>> gmake[4]: *** [fts-tokenizer-generic.lo] Error 1
>> gmake[4]: Leaving directory
'/usr/local/etc/dovecot/SOURCE/dovecot-2.2/src/lib-fts'
>> 
>> 
>> 2) I don't have a python binary installed, only a python2 link to
the python27 binary (FBSD, and python27 from ports).
>>   Thus, update-version.sh will fail to evaluate hg's changeset. As
a quick fix I needed to create a link: python -> python2
> Both these are only run if you compile the source from hg, as you did.
Official release tar-balls should not have this issue.
> Still, it is not optimal and Ill definitely look into solving 1) when I
have time available for that.
> 
> For temporarily solving 1) it is worth noticing the scripts
word-break-data.sh and word-boundary-data.sh depend on /bin/bash.
Well that works, although ti's suboptimal because FBSD is more or less
bash-free. One, has to install a bash port, and one has to to create a link for
/usr/bin/local/bin/bash as /bin/bash. Easy to do, but no perfect solution, when
it comes to OS portability, though.
> You could either install bash
That works well.
> or just try if it works if you change it to /bin/sh and use whatever
FreeBSD has that pointing to.

That fails because /bin/sh equals /bin/csh at FBSD.

Thanks and with kind regards,
Michael

On Saturday, May 09, 2015 22:25:48 Michael Grimm wrote:
> > or just try if it works if you change it to /bin/sh and use whatever
> > FreeBSD has that pointing to.
> That fails because /bin/sh equals /bin/csh at FBSD.
>
I don't know if it fails or not, but if it does this is not the reason.  
/bin/sh most certainly is not /bin/csh; if it were, the system would not boot 
given that all the rc start-up scripts are written in Bourne shell.

OTOH, /bin/csh and /bin/tcsh are identical:

$ freebsd-version -uk
10.1-RELEASE-p9
10.1-RELEASE-p9
$ ls -li /bin/*sh    
108 -r-xr-xr-x  2 root  wheel   382368 Nov 11 15:03 /bin/csh*
118 -r-xr-xr-x  1 root  wheel   142184 Nov 11 15:03 /bin/sh*
108 -r-xr-xr-x  2 root  wheel   382368 Nov 11 15:03 /bin/tcsh*

-- 
Greg Rivers

Greg Rivers <gcr+dovecot at tharned.org> wrote:
> On Saturday, May 09, 2015 22:25:48 Michael Grimm wrote:
>>> or just try if it works if you change it to /bin/sh and use
whatever
>>> FreeBSD has that pointing to.
>> That fails because /bin/sh equals /bin/csh at FBSD.
> I don't know if it fails or not, but if it does this is not the reason.
> /bin/sh most certainly is not /bin/csh;
Ups. Yes, that is correct. Sorry, my fault.
> if it were, the system would not boot 
> given that all the rc start-up scripts are written in Bourne shell.
But here I will insist on /bin/sh != /bin/bash ;-) The FBSD OS is bourne free,
if I am not mistaken again.
> OTOH, /bin/csh and /bin/tcsh are identical:
> 
> 108 -r-xr-xr-x  2 root  wheel   382368 Nov 11 15:03 /bin/csh*
> 118 -r-xr-xr-x  1 root  wheel   142184 Nov 11 15:03 /bin/sh*
> 108 -r-xr-xr-x  2 root  wheel   382368 Nov 11 15:03 /bin/tcsh*
ls -al /bin/sh /usr/local/bin/bash (FBSD 10.1-STABLE):
| -r-xr-xr-x  1 root  wheel  uarch 142144 May  8 13:57 /bin/sh
| -rwxr-xr-x  1 root  wheel  uarch 895712 May  8 13:09 /usr/local/bin/bash

JFTR: Both scripts fail to run with FBSD's /bin/sh (lot of syntax errors),
but run to completion when modifying the first line to
"#!/usr/local/bin/bash" (needed, because ports are installed into
/usr/local).

Regards,
Michael