Profanity: configure doesn't run correctly on my HardenedBSD (obscure FreeBSD fork) system with autoconf 2.69.

[janicez]

Expected Behavior

The expected behaviour is that ./configure after invoking ./bootstrap.sh progresses to building the Makefiles, from which I can then run gmake as any normal BSD'er would for this sort of program.

Current Behavior

checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/local/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... freebsd12.0 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for python-config... no
configure: Python development package not found, Python plugin support disabled.
checking for main in -ldl... yes
./configure: 12606: Syntax error: word unexpected (expecting ")")

Steps to Reproduce (for bugs)

I would think that installing the HardenedBSD 12 images from https://hardenedbsd.org/, then installing the devel/autoconf port (at version 2.69) as well as all other dependencies of Profanity, would be sufficient. From there you can obviously download a Profanity source tree and run the usual bootstrap/configure dance.

Context

I wished to use profanity on my HardenedBSD 12-STABLE machine. I cannot. Given my mild cognitive impairment, I am not going to be able to help make the modifications I would quite like to that would go towards helping you fix this issue.

Environment

• profanity -v output not available because I could not compile Profanity. Instead, the first 20 lines of the git log are supplied here.

[Invictus ellenor]~/src/profanity $ git log | head -n 20
commit 968006e1ddf97b5d9e8245c9dabbb0cfcfca2c3a
Author: Michael Vetter <[email protected]>
Date:   Sat Feb 8 09:28:41 2020 +0100

    travis: Update icons switch

    Use --enable-icons-and-clipboard instead of old --enable-icons

commit 17b6cfaf7d6d14bba4fa077e65119bc71c33332a
Author: Michael Vetter <[email protected]>
Date:   Fri Feb 7 21:49:21 2020 +0100

    Start next development cycle

commit 4291281629be14dd169d74251e1bf3d37841e19b
Author: Michael Vetter <[email protected]>
Date:   Fri Feb 7 21:47:41 2020 +0100

    Release 0.8.1

• Operating System/Distribution

$ uname -a; uname -KU
FreeBSD Invictus.WA.US.Umbrellix.NET 12.0-STABLE-HBSD FreeBSD 12.0-STABLE-HBSD #1  ef13175b6ad(hardened/12-stable/master)-dirty: Thu Mar  7 15:40:02 UTC 2019     [email protected]:/usr/obj/Users/hadron/src/hardenedBSD-stable/amd64.amd64/sys/HARDENEDBSD-SOFTENED  amd64
1200502 1200502

• glib version to my knowledge is 2.56

[jubalh]

Profanity 0.7.1 is in FreeBSD. I don't have such a system and can't reproduce. It might be a good idea to get in contact with the FreeBSD maintainer and ask him to update the package. When you do this you can also ask him how he was able to compile Profanity.

[janicez]

I'm hand-compiling.

[janicez]

To get the ./configure script to progress, I needed to comment out where you invoked ACX_PTHREAD.

[janicez]

Happened upon a new error...

In file included from ./src/ui/win_types.h:47,
                 from ./src/command/cmd_funcs.h:40,
                 from ./src/ui/ui.h:43,
                 from src/ui/occupantswin.c:40:
src/ui/occupantswin.c: In function '_occuptantswin_occupant.isra.0':
/usr/local/include/ncurses/ncurses.h:1192:26: error: 'colour' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 #define wattroff(win,at) wattr_off(win, NCURSES_CAST(attr_t, at), NULL)
                          ^~~~~~~~~
src/ui/occupantswin.c:47:9: note: 'colour' was declared here
     int colour;
         ^~~~~~
cc1: all warnings being treated as errors
gmake[1]: *** [Makefile:1879: src/ui/occupantswin.o] Error 1
gmake[1]: *** Attente des tâches non terminées....
In file included from ./src/ui/win_types.h:47,
                 from ./src/command/cmd_funcs.h:40,
                 from ./src/ui/ui.h:43,
                 from src/ui/rosterwin.c:42:
src/ui/rosterwin.c: In function '_rosterwin_contact':
/usr/local/include/ncurses/ncurses.h:1192:26: error: 'colour' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 #define wattroff(win,at) wattr_off(win, NCURSES_CAST(attr_t, at), NULL)
                          ^~~~~~~~~
src/ui/rosterwin.c:356:9: note: 'colour' was declared here
     int colour;
         ^~~~~~
cc1: all warnings being treated as errors
gmake[1]: *** [Makefile:1879: src/ui/rosterwin.o] Error 1
gmake[1] : on quitte le répertoire « /usr/home/ellenor/src/profanity »
gmake: *** [Makefile:1183: all] Error 2

[petvoigt]

Under FreeBSD 12.1-RELEASE-p2 (amd64) net-im/profanity 0.7.1_1 builds just fine. I therefore conclude the current issue is related to HardenedBSD.

[wstrm]

@janicez you could try to pull down v0.7.1 and compile that. If v0.7.1 succeeds but not v0.8.1 it could give us a clue where to look.

[janicez]

@petvoigt does trunk compile fine though? that's the question.

You're making the mistake of assuming I'm compiling from ports, which I'm not (I assume that would work fine, because HBSD has done nothing to the build environment that would render it incompatible with FreeBSD).

@wstrm I ended up removing -Werror from the CFLAGS and removing your ACX_PTHREAD invocation in configure.ac. Both are hacks, frankly, since I think the Profanity project put -Werror in the CFLAGS. I did get a successful compilation of the profanity XMPP client, but the user interface was hard on my head. In any case, it did work.

[wstrm]

@jubalh That compile warning is right though. Looking in src/ui/occupantswin.c the colour variable could be left uninitialized. Now I'm wondering why I don't get the warning when compiling...

[jubalh]

@jubalh That compile warning is right though. Looking in src/ui/occupantswin.c the colour variable could be left uninitialized. Now I'm wondering why I don't get the warning when compiling...

How can it be?
In case of PREF_OCCUPANTS_COLOR_NICK will be initialized.
Later on colour is only used in the PREF_OCCUPANTS_COLOR_NICK case too. So it can't be used uninitialized. The compiler just doesnt detect this.

[wstrm]

@jubalh That compile warning is right though. Looking in src/ui/occupantswin.c the colour variable could be left uninitialized. Now I'm wondering why I don't get the warning when compiling...

How can it be?
In case of PREF_OCCUPANTS_COLOR_NICK will be initialized.
Later on colour is only used in the PREF_OCCUPANTS_COLOR_NICK case too. So it can't be used uninitialized. The compiler just doesnt detect this.

Ah, right. Which compiler is @janicez using? I didn't get the warning, or are we silencing the warning somewhere?

Anyhow, a simple check on colour could be added to silence it.

[jubalh]

Anyhow, a simple check on colour could be added to silence it.

Yes. Like I do for the presence_colour variable just below.

[arvedarved]

Hi, just like to point out, I have updated the FreeBSD port to 0.8.1. AFAIU hardnedBSD uses the freebsd-ports. I have used clang 8.0.1. The port compiles without Werror though,

--- src/ui/console.o ---
src/ui/console.c:2524:45: warning: incompatible pointer to integer conversion passing 'char [14]' to parameter of type 'char' [-Wint-conversion]
win_println(console, THEME_DEFAULT, "Version %sdev", PACKAGE_VERSION);
^~~~~~~
./src/ui/ui.h:364:71: note: passing argument to parameter 'ch' here
void win_println(ProfWin *window, theme_item_t theme_item, const char ch, const char *const message, ...);
^
--- src/ui/occupantswin.o ---

--- src/ui/console.o ---
src/ui/console.c:410:49: warning: incompatible pointer to integer conversion passing 'char [36]' to parameter of type 'char' [-Wint-conversion]
win_println(console, THEME_DEFAULT, "Welcome to Profanity, version %sdev", PACKAGE_VERSION);
^~~~~~~~~
./src/ui/ui.h:364:71: note: passing argument to parameter 'ch' here
void win_println(ProfWin *window, theme_item_t theme_item, const char ch, const char *const message, ...);
^

[wstrm]

Okay, so Clang seems to be the culprit. I don't think we'd be able to run FreeBSD in Travis easily as it uses Docker containers. A Dockerfile that uses Clang could be added, so we at least make sure to be compatible with Clang, too :)

[jubalh]

I have updated the FreeBSD port to 0.8.1.

Awesome! Thank you.

A Dockerfile that uses Clang could be added, so we at least make sure to be compatible with Clang, too :)

That sounds like a good idea!

[petvoigt]

On Mon, 10 Feb 2020 02:03:16 -0800
Tilman Keskinöz [e-mail] wrote:

Hi, just like to point out, I have updated the FreeBSD port to 0.8.1.
AFAIU hardnedBSD uses the freebsd-ports. I have used clang 8.0.1. The
port compiles without Werror though,

net-im/profanity 0.8.1 builds fine (FreeBSD 12.1-RELEASE-p2 amd64).
Thanks for upgrading.

[janicez]

I believe I was using clang @wstrm but I can't be truly sure.

As I said about ACX_PTHREAD, I had to comment that and it seemed to work (but I have not tried it on illumos, another platform that I sometimes use which I know is asinine about pthread, so who knows how well that'll shake out).

[jubalh]

I'm not sure about the ACX_PTHREAD problem here. But since it works for FreeBSD I don't think it's our problem.

Also the code is right and the variables will always be initialized. Adding checks everywhere for not correct compiler detection is not so nice I think.

But in one case I added it anyways ;)

Closing this for now. @janicez if problems persist please contact an HardenedBSD maintainer.

Thanks again to @arvedarved for updating the FreeBSD port.

[janicez]

ACX_PTHREAD in this case is referring to the fact that the generated ./configure script has an untransformed autoconf directive (ACX_PTHREAD, for what that's worth), which I needed to comment out before ./configure would progress normally.

And I went directly to you because I was installing the package directly from your sources, not through ports.

[jubalh]

ACX_PTHREAD in this case is referring to the fact that the generated ./configure script has an untransformed autoconf directive (ACX_PTHREAD, for what that's worth).

I don't know what that means.
Since on all systems except HardenedBSD this works (as far as I know) I assumed it's a specificity of that system. And asked you to ask a maintainer there.
If you know what the problem is you can create a pull request.

[arvedarved]

ACX_PTHREAD is part of devel/autoconf-archive. @janicez you are probably missing this dependency.