Hi —

Teemu Huovila <teemu.huovila@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

Greg Rivers <gcr+dovecot@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