OpenBSD support for domoticz, cmake problem mostly

[vuokko]

I was able to hack and compile and at least start Domoticz on OpenBSD 6.0.
This is mainly cmake problem which isn't allowing it to compile and cmake is one of those things which I'm not familiar.

First some versions:

cmake-3.5.2
python-3.5.2
boost-1.58.0p2
git-2.9.0

The EPROTO substitute as OpenBSD doesn't have EPROTO in MQTT/config.h was selected from mosquitto-1.4.2 port patch.

I attached path and my notes to make it. I'm happy to test cmake features to enable clean compile.

domoticz_compile.txt

0001-Openbsd-compile-support-patch.txt
Edit: Added cmake logs
CMakeOutput_log.txt
CMakeError_log.txt

[gizmocuz]

Thanks for the reports!
I have upgraded MQTT to the latest version (1.4.10) (also the config.h file)

Could you try if the getExecutablePathName for FreeBSD is also working for OpenBSD, as they use the same sysctl function ?

I think there should be no harm checking /proc, or for example /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/temp1_input
Sure they will fail, that is why we check against this...
Maybe some code in the hardware monitor class needs to be adjusted for openbsd as well ?

Can't help you with the normal openbsd nagging stuff... Again they got it wrong and is not misused ;)
(maybe you can add a compile flag to disable this ?)

I can't see (clearly...) the first error in CMakeList.yxy (* fail. Bost and threads... -pthread fix)
What was the error ?

There are other users compiling this on OpenBSD as well... could it be that your using outdated versions of gcc/boost maybe ?

[vuokko]

Thanks for the reports!
I have upgraded MQTT to the latest version (1.4.10) (also the config.h file)

Could you try if the getExecutablePathName for FreeBSD is also working for OpenBSD, as they use the same sysctl function ?

The sysctl is same but the implementaton is different. On openBSD that returns the argv array and it may be different. Output of getExecutablePathName testing function:

$ ls -l grr hmm
lrwxr-xr-x  1 vuolasah  wheel     3 Feb 14 22:30 grr -> hmm
-rwxr-xr-x  1 vuolasah  wheel  7001 Feb 16 16:58 hmm
$ ./grr
arg 0: ./grr
executable: /tmp/hmm

I think there should be no harm checking /proc, or for example /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/temp1_input
Sure they will fail, that is why we check against this...

Actually I ifdef'd out the infile.open("/proc/cpuinfo"); which would throw an exception. I was lazy and optimized out the dead code for OpenBSD. I just wanted to domoticz to compile first.

Maybe some code in the hardware monitor class needs to be adjusted for openbsd as well ?

$ sysctl hw.sensors|grep temp
hw.sensors.acpitz0.temp0=64.00 degC (zone temperature)
hw.sensors.cpu0.temp0=60.00 degC

Also the tempereatures could be digged through sysctl(3) but there is no file to read them.

Can't help you with the normal openbsd nagging stuff... Again they got it wrong and is not misused ;)
Yep. I can see at least one is correct. pid_t is 32-bit integer so it can be about 4*10^9 and the newline at the end... Rest I didn't really check.
(maybe you can add a compile flag to disable this ?)
Maybe comment on the source that this line will nag on OpenBSD is better as AFAIK disabling those warnings isn't easy without suppressing good warnings too.

I can't see (clearly...) the first error in CMakeList.yxy (* fail. Bost and threads... -pthread fix)
What was the error ?

This comes from memory. Cmake tested for pthread and determined -pthread is right choice.
However I don't know why it didn't end up as switch when stdafx.h is used.

I couldn't find anything similar listed in: https://cmake.org/cmake/help/git-master/module/FindBoost.html documentation. Cmake is one of those tool which I have avoided.

The step which link.txt is edited is result from CMakeList.txt lines: 665 and 670-680 I believe.

There are other users compiling this on OpenBSD as well... could it be that your using outdated versions of gcc/boost maybe ?

Of course it is old gcc. OpenBSD lags behind in really stable versions. g++ (GCC) 4.2.1 20070719
I'm running 6.0 stable from January 15. Boost is from package. Maybe other users are compiling Domoticz differently :)

[gizmocuz]

Sound good... i might have created a problem upgrading MQTT, seems some users have connection issues now... strangely enough ;)
Is it possible you could create a pull request with the needed changes (excluding CMakeList.txt for now) to get it all working for you on OpenBSD ? (also the temperature part?)

[vuokko]

The pull request seems reasonable. I'll have it set up in few days after rebasing to current version and figuring out of the best and proper way of doing the sensor handling.

Could you have a look on the CMakeList.txt to get checks for -ptheads CXXFLAGS and -rt and --static-libstdc++ dropped when not supported?

[gizmocuz]

Is this issue still open ?

[vuokko]

I have had almost ready set for a while. Unfortunately life happen. And haven't had time to finish it yet. So yes I'm workkng on it.

[gizmocuz]

No worries... Just wanted to know if ended to keep this ticket open

[vuokko]

I had time to finish the code. However I still have the original problem of missing -pthread in everywhere where boost is used and undefined -rt in linking. Removing -rt is needed. So I'm not comfortable to push to master the changes. However code is here: https://github.com/vuokko/domoticz

I have no idea how to fix that in cmake. Domoticz has quite large cmake environment. So good pointers, help, and hints are welcome. After fixing that I'll fire pull request.

[correa]

The changes in vuokko commit referenced here are part of current development branch. I guess this could be closed then.

[vuokko]

I think this can be closed. I'll sen more pull requests if I find more issues.