Generation of rfbconfig.h and rfbint.h

[cinemast]

Hi!

At debian we currently have troubles with multi-arch support for libvncserver because of the dynamic generation of the above mentioned headers. Is this really required?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786822

Can you help us out with that? How would it influence if we only generated those files on an amd64 build machine and reuse it for all the other archs?

How does the WORDS_BIGENDIAN influence the compilation?

Thank you in advance.

[bk138]

I'll have a look. Maybe @dscho can provide some insights on this as well...

[dscho]

IIRC the rfbint.h was written out due to a lack of stdint.h in MinGW headers back in the days.

Unfortunately, I do not think that we can do anything about generating rfbconfig.h. It prevents incompatible .so libraries to be picked up (e.g. when the struct assumes that libjpeg is available and sets aside a couple of fields to use it, but libjpeg is actually not available as per the libvncserver.so).

[cinemast]

I see. But what about the WORDS_BIGENDIAN? How does it influence the build process. Can this maybe be moved to a header which is not exported to /usr/include?

[cinemast]

I think it is only used by common/md5.c

[bk138]

To start with, https://github.com/LibVNC/libvncserver/tree/gen-headers-rework removes rfbint.h generation, which should be reasonable nowadays.

[bk138]

97f442e now relies (as md5sum.c did already) on endian.h instead of doing build system tests. Please comment.

[dscho]

I guess if anybody wants to get LibVNCServer to compile on Windows again, they should fix it (IIRC there was no endian.h in MinGW nor in Visual Studio's headers when I last tried to compile that). So I am fine with your change.

[cinemast]

Thank you for being so supportive on this :)

I will take those two commits as patches to the debian package. I assume they will be integrated in the next release of libvncserver?

[bk138]

Yep.