Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile error in trle.c, function HandleTRLE15 already has a body #214

Closed
BastiaanOlij opened this issue Jan 26, 2018 · 5 comments
Closed

Comments

@BastiaanOlij
Copy link
Contributor

Hi all,

New here and wanting to try out libvncclient. Compiling on Windows 10 using MSVC 2017, using 64bit toolchain. Using cmake to build, the build stops at the following error:

"C:\Users\basti\Development\gdnative\gdvnc\libvncserver\build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\basti\Development\gdnative\gdvnc\libvncserver\build\client_examples_backchannel.vcxproj" (default target) (3)
 ->
"C:\Users\basti\Development\gdnative\gdvnc\libvncserver\build\vncclient.vcxproj" (default target) (4) ->
(ClCompile target) ->
  c:\users\basti\development\gdnative\gdvnc\libvncserver\libvncclient\trle.c(53): error C2084: function 'rfbBool Handle
TRLE15(rfbClient *,int,int,int,int)' already has a body [C:\Users\basti\Development\gdnative\gdvnc\libvncserver\build\v
ncclient.vcxproj]

Any ideas what is causing this and how to resolve?

Many thanks!

@bk138
Copy link
Member

bk138 commented Jan 26, 2018

This is interesting, since https://ci.appveyor.com/project/bk138/libvncserver/build/1.0.177 succeeded to build with TRLE...

@bk138 bk138 added the building label Jan 26, 2018
@BastiaanOlij
Copy link
Contributor Author

@bk138 hmm, looks like that is compiling with 2013 and 2015, not with 2017 so maybe its something that MS changed recently. I do have the 2015 toolset installed (option in 2017) but I'm not sure how I could instruct cmake to use that.

@BastiaanOlij
Copy link
Contributor Author

alternatively, could it be that I'm missing any 3rd party libraries that is causing a slightly different code path?

@BastiaanOlij
Copy link
Contributor Author

Ok, this might have something to do with it:

/*
 * trle.c - handle trle encoding.
 *
 * This file shouldn't be compiled directly.  It is included multiple times by
 * rfbproto.c, each time with a different definition of the macro BPP.  For
 * each value of BPP, this file defines a function which handles a trle
 * encoded rectangle with BPP bits per pixel.
 */

I can't really tell from the cmake output but it looks like its attempting to compile it even though it should only be included.

@BastiaanOlij
Copy link
Contributor Author

I found it!

#define REALBPP 15
#include "trle.c"
#define REALBPP 15
#include "zrle.c"

In this snippet of code we first set REALBPP to 15, then include trle.c, that creates the first version of that function. At the end of trle.c REALBPP gets undefined.

Next we set REALBPP again to 15 and include zrle, again at the end of zrle.c REALBPP gets undefined unless we do not have zlib installed (which I haven't).

So a few lines later when trle.c gets included but now for BPP = 32, REALBPP is still set to 15 giving our compile error.

In zrle.c the #undef REALBPP should be moved until after the #endif where UNCOMP is also undefined

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants