compiling 10951

[Rudi De Vos]

The build files are correct.
Buildtime.obj is created in
...UltraVNC Project Root\UltraVNC\vncviewer\x64\Debug

I only can repeat myself....

Only i case you select on top
[debug][win32]
and
batchbuild
[v] debug [v]X64
Output of the batchbuild is written in vncviewer\debug
OUTPUT PATH depend on the top settings...
BOTH batchbuild and top settings need to be the same...

[Louis]

Rudi,

Thanks. It did not work, exactly the same error.

But I agree it has something to do with settings! I am almost sure that the problem is related to your remark
> Output of the batchbuild is written in vncviewer\debug
> OUTPUT PATH depend on the top settings...
> BOTH batchbuild and top settings need to be the same...

For me you was not clear engough which setting should be there.

IMHO you have two ways to solve this:
1) to change the build config files
2) to change the linker config file
Those two should correspond (whatever those config files / settings are)

I think it is best to change the linker setting because the file is generated in the x64 sub dir, which sounds more ligical to me than in the main dir where the linker is looking for it !!!


Louis

[Rudi De Vos]

The project files are correct, and set "inherit from project defaults"
You don't specify different settings for debug/release/win32/x64,
all is done via VS2010 parameters.

project defaults== top settings

Sample:
Outputdir: $(Platform)\$(Configuration)\
Linker output files: $(OutDir)$(TargetName)$(TargetExt)
....
for win32/debug this give Outputdir=debug
x64/release->Outputdir=x64/release

This is all auto generated by VS2010 and you should not change them.
Else, if you create a new config (IPP,SPECIALBUILD...) you need to manual change all folders

I don't understand why you have so many trouble with VS2010, it works installed on a blank PC.

[Louis]

Rudi,

I did another step. I installed VS2010 prof trail, nasm and direct X on a clean vista64 computer wthich had never seen visual studio any type before.

And did try to batch compile the viewer.
Guess what ........ same problem

For info vncviewer propertys after opening vncviewer.sln
General
Output Directory $(platform)\$(Configuration)\
Intermediate Directory $(platform)\$(Configuration)\

Linker
general Output File $(platform)\$(Configuration)\
*unclear to me* input spec what and where


bauild failed with exactly the same problem as before buildtime.cpp fatal error C1083 (can not open compiler generated file) debug\buildtime.obj no such file or dir

(correct it is in x64\debug)


Louis

[Rudi De Vos]

------ Rebuild All started: Project: vncviewer, Configuration: Debug x64 ------
Build started 6/04/2011 15:04:57.
_PrepareForClean:
Deleting file "x64\Debug\vncviewer.lastbuildstate".
InitializeBuildStatus:
Touching "x64\Debug\vncviewer.unsuccessfulbuild".
ClCompile:
stdhdrs.cpp
zrle.cpp
....
ClientConnection.cpp(8869): warning C4244: '=' : conversion from 'LRESULT' to 'int', possible loss of data
buildtime.cpp
Generating Code...
Compiling...
AuthDialog.cpp
...
AboutBox.cpp(139): warning C4244: 'initializing' : conversion from 'INT_PTR' to 'int', possible loss of data
Generating Code...
vncauth.c
minilzo.c
d3des.c
Generating Code...
PreLinkEvent:
Description: Setting build time...
buildtime.cpp
Link:
vncviewer.vcxproj -> D:\UltraVNC\vncviewer\x64\Debug\vncviewer.exe
Manifest:
Deleting file "x64\Debug\vncviewer.exe.embed.manifest".
LinkEmbedManifest:
vncviewer.vcxproj -> D:\UltraVNC\vncviewer\x64\Debug\vncviewer.exe
FinalizeBuildStatus:
Deleting file "x64\Debug\vncviewer.unsuccessfulbuild".
Touching "x64\Debug\vncviewer.lastbuildstate".

Build succeeded.

[Rudi De Vos]

Did you already tried to start Visual Studio with "runas admin".
This is is sometimes caused by incorrect write permissions.

[Louis]

Rudi,


1) Do not know why, but I can build the viewer now (both computers), also without administrator rights.

I tried batch build debug vnc 64 when on the screen that one was seleced, os easier batch rebuild solution

However than I get the same error I got before with zlib !!

When starting the debugger, the message ^Unable to start program. The specified file is an unrecognised or unsupported binary format)^ arrises but now in relation with ^omnitread.lib^

So, the fact that you use the assembler now for zlib is perhaps solving the previeus problem. But it is clear now that the problem is not uniq to zlib!!


2)Question. Is the viewwer.sln that what you describe as "toplayer" or is there a higher "toplayer" !!?? Related, where do you defile the toplayer settings?


Louis

[Louis]

Rudi,

I think I understand the problems now:
- why I could link sometimes and sometimes not and
- why the binairys can't be used
The problems are related !!

To start with there is a major problem related to the config files:
- x64 should in x64 or x64/debug
- 32 should be in x86 or x86/debug

Problem is that that is not consequently so !!!!

Assume I do a clean install and:
1) start compiling the 64 bit debug version
==> the linker failes because it is looking in the base dir not x64
2) now I compile the 32 bit debug version
==> the bould is OK and data is stored in e.g. ...... the base dir
3) now I compile the 64 bit debug version again
==> the linker is saying OK, but is infact using 32bit building blocks
4) now I start debuging and the binairy is not OK, you got it :<

(I assume this is what happens)

So, the conclusion is the data from 32bit and 64bit should be strictly sepparated in x86 and x64 dirs and the main dir should NEVER be used.

same holds for the ipp stuff (what ever it is!!)


Louis

[Louis]

Rudi,

Did you read my previeus two mails?
I really think it is not ok!

I also noted that inlude / lib directorys seems to be specified per result type (x86/x64 etc).
I noticed that you did include the direct x references in the x64 tree, but not in the x86 tree.

I have been loking where to change the linker source directory settings since the linker is looking in the wrong subdir when linking x64
(it looks in the main dir in state of x64/debug)
How to change that !?

Sincerely,


Louis

[Louis]

Rudi,

Even in het nederlands dat is makkelijker :>

Ik probeer enigzinds te begrijpen hoe het VS2010 C++ configuratie management in elkaar zit. Haast bizar en ik begrijp nog lang niet alles

- info onder andere verkregen via
* according to VS => tools => options => vc++ directorys => ? the toplevel path are stored in envirement variables like INCLUDE, LIBPATH and LIB
==> However those envirement variables do not exists on my system !!
==> en er wordt ook geen rekening gehouden met x86/x64 specifieke paden
- verder lees ik
* there is an option of projec specific directory list
* and per user (discusting, is my first and second impression)
==> waarbij ik zowel in eerste als ook tweede instandtie walg van het idee van user specifieke settings (settings horen bij het project !!)

ze zijn overigens terug te vinden op By default, per-user property sheets are located at <drive>:\Documents and Settings\ <user>\Local Settings\Application Data\Microsoft\MSBuild\v4.0.
OEPS!! weer elders C:\Users\<actual user>\AppData\Local\Microsoft\MSBuild\v4.0
e.g. Microsoft.Cpp.x64.user.props / Microsoft.Cpp.Win32.user.props / Microsoft.Cpp.Itanium.user.props

dan kijkende naar de property manager dan heeft het domme ding bovenin twee selectors namelijk ^configuration^ en ^platform^ waarbij in beide gevallen ook "all" mogelijk is

deze gelijkwaardige (naar het lijkt) selectors leiden dus tot enorme onbeheersbare matrix aan mogelijkheden

Je zou denken dat de hierargie zou moeten zijn:
- envirement variabelen (zijn er niet)
- vs settings (zijn er niet, er lijken verborgen VS-defaults!!???)
- configuration settings all
- configuration settings specific
- platform settings all
- platform settings specific
waarbij oveerigens alleen in uitzondelijke gevallen op de lagere (override) niveaus iets ingevuld zou moeten zijn

Dan hebben we het alleen nog maar gehad over input pader, en nog niet over code generatie paden en linker zoekpaden. En die moeten uiteraard alle ook platform specifiek zijn.

Geen idee waar dat te configuren. Ik zou niet verbaast staan als dat bij
==> configuration properties ==> C/C++ ==> output files is
Echter dan zou daat een $platform moeten staan om e.e.a. platform type specifiek te maken (en die zie ik niet).

Wat een goed bedoelde zooi!! Ik begin werkelijk te verlangen naar een simpele configfile waar in ik gewoon weg kan aangeven wat ik wil :>


Louis

[Louis]

Rudi,

Given the situation as described in my previeus mails, I completely understand. However the property manager setting seems to by messy.

Lets take vncviewer as example.
Open vncviewer.sln => expand vnc viewer => doubel click debug | Win32
output dir = $(SolutionDir)$(Configuration)\
intemediate dir = $(Configuration)\

Now do the same with debug | 64
output dir = $(Platform)\$(Configuration)\
intemediate dir = $(Platform)\$(Configuration)\

This is just an example of bull shit of course!
- What ever the correct option is, it is the same !!!
- and $Platform SHOULD always be part of the path
- and intemediate dir SHOULD NOT equal the output dir

So the win32 options are definitly wrong and
the x64 dir settings are definitly wrong as well

Not sure what about what the good (best) settings are, but I think you might consider something like
output dir = $(SolutionDir)$(Platform)\
intemediate dir = $(ProjectTmpDir)$(Platform)\

Where ProjectTmpDir is just a name at this moment


Same kind of thinking holds for the build logfile dir
$(IntDir)\$(MSBuildProjectName).log
however:
- to choose one dir for all logfiles go to the same dir, might be a good idea
- but of course what ever you choose, it should be the same across the project.


Note that I do not at all blame you, since IHMO it is hardly maintainble given the crazy confusing VS GUI. And I also noticed that there is a lot of history in the project.

I think however that it is necessary to clean this whole config scene to keep the project longterm "under control"


Louis

[shadowfax]

When compiling 1.0.9.5 or 1.0.9.6 I get the following errors (External references not found)

Code: Select all

error LNK2019: símbolo externo _compress sin resolver al que se hace referencia en la función "protected: int __thiscall vncClient::SendCacheZip(class std::vector<struct rfb::Rect,class std::allocator<struct rfb::Rect> > const &)" (?SendCacheZip@vncClient@@IAEHABV?$vector@URect@rfb@@V?$allocator@URect@rfb@@@std@@@std@@@Z)
error LNK2001: símbolo externo _compress sin resolver
error LNK2019: símbolo externo _adler32 sin resolver al que se hace referencia en la función "public: int __thiscall vncClient::GenerateFileChecksums(void *,char *,int)" (?GenerateFileChecksums@vncClient@@QAEHPAXPADH@Z)
error LNK2019: símbolo externo _uncompress sin resolver al que se hace referencia en la función "public: bool __thiscall vncClient::ReceiveFileChunk(int,int)" (?ReceiveFileChunk@vncClient@@QAE_NHH@Z)
error LNK2019: símbolo externo _deflateEnd sin resolver al que se hace referencia en la función "public: virtual __thiscall vncEncodeTight::~vncEncodeTight(void)" (??1vncEncodeTight@@UAE@XZ)
error LNK2001: símbolo externo _deflateEnd sin resolver
error LNK2001: símbolo externo _deflateEnd sin resolver
error LNK2001: símbolo externo _deflateEnd sin resolver
error LNK2019: símbolo externo _deflate sin resolver al que se hace referencia en la función "protected: int __thiscall vncEncodeTight::CompressData(unsigned char *,int,int,int,int)" (?CompressData@vncEncodeTight@@IAEHPAEHHHH@Z)
error LNK2001: símbolo externo _deflate sin resolver
error LNK2001: símbolo externo _deflate sin resolver
error LNK2001: símbolo externo _deflate sin resolver
error LNK2019: símbolo externo _deflateParams sin resolver al que se hace referencia en la función "protected: int __thiscall vncEncodeTight::CompressData(unsigned char *,int,int,int,int)" (?CompressData@vncEncodeTight@@IAEHPAEHHHH@Z)
error LNK2019: símbolo externo _deflateInit2_ sin resolver al que se hace referencia en la función "protected: int __thiscall vncEncodeTight::CompressData(unsigned char *,int,int,int,int)" (?CompressData@vncEncodeTight@@IAEHPAEHHHH@Z)
error LNK2001: símbolo externo _deflateInit2_ sin resolver
error LNK2001: símbolo externo _deflateInit2_ sin resolver
error LNK2019: símbolo externo _inflateInit_ sin resolver al que se hace referencia en la función "public: __thiscall rdr::ZlibInStream::ZlibInStream(int)" (??0ZlibInStream@rdr@@QAE@H@Z)
error LNK2019: símbolo externo _inflateEnd sin resolver al que se hace referencia en la función "public: virtual __thiscall rdr::ZlibInStream::~ZlibInStream(void)" (??1ZlibInStream@rdr@@UAE@XZ)
error LNK2019: símbolo externo _inflate sin resolver al que se hace referencia en la función "private: void __thiscall rdr::ZlibInStream::decompress(void)" (?decompress@ZlibInStream@rdr@@AAEXXZ)
error LNK2019: símbolo externo _deflateInit_ sin resolver al que se hace referencia en la función "public: __thiscall rdr::ZlibOutStream::ZlibOutStream(class rdr::OutStream *,int,int)" (??0ZlibOutStream@rdr@@QAE@PAVOutStream@1@HH@Z)
fatal error LNK1120: 11 externos sin resolver

SOLVED: Must get rid of the precompiler condition ZLIB_WINAPI in debug mode on the project zlibstat.

[Qbfinest83]

I am trying to compile winvnc on VS2010. I read about the NASM but when I went to http://www.nasm.us/ but it says its VS2008 I dont see it for VS2010. I tried to google it but couldnt find NASM that worked with VS2010. Does anyone know how to make it work with VS2010


UPDATE: Never mind. I added the NASM path in VC++ Directiories >Executable Directories and it worked fine .

[Rudi De Vos]

Qbfinest83,

Is it compiling fine after you added nasm and directx ?
Louis had a lot of trouble, but i was unable to repeat them on my site.

[Qbfinest83]

Qbfinest83,

Is it compiling fine after you added nasm and directx ?
Louis had a lot of trouble, but i was unable to repeat them on my site.

Yeah after I installed NASM on my Win7 machine and open VS2010 I right click on libjpeg-turbo-win and went to properties> VC++ Directories> Executables Directories and there notice that the NASM install directory was pointing to the wrong place so I pointed it to the correct directory and tried to run it again and it work.

I was able to compile debug fine however when I try to do the release now I am getting "LINK : fatal error LNK1181: cannot open input file 'zlibstat.lib'"

[Rudi De Vos]

did you put the top
[release][win32]
and
batch build the same
[v] release win32 winvnc/vncviewer

before doing a rebuild

For some unknown reason, VS2010 use the top as parameters for the
output path...

[Qbfinest83]

did you put the top
[release][win32]
and
batch build the same
[v] release win32 winvnc/vncviewer

before doing a rebuild

For some unknown reason, VS2010 use the top as parameters for the
output path...

Yes its set for release win32. I double checked the configuration manager and thats also says release win32.

In .\zlib-1.2.5\contrib\vstudio\vc10\x86 I found two folders ZlibStatDebug and ZlibStatRelease and in both they have the zlibstat.lib

[Rudi De Vos]

zlibstat.lib is in
..\UltraVNC Project Root\UltraVNC\zlib-1.2.5\contrib\vstudio\vc10\x86\ZlibStatRelease

This is correct.

The path used for finding the lib is at
winvnc->properties->common properties->framework and references->zlibstat
In my case
Full Path= the path used to find the lib ( path depend on top settings)
H:\ultravnc_195_turbojpeg\UltraVNC Project Root\UltraVNC\zlib-1.2.5\contrib\vstudio\vc10\x64\ZlibStatRelease\zlibstat.lib

[Qbfinest83]

OK I checked winvnc->properties->common properties->framework and references->zlibstat
and I got the correct path C:\Ultra\UltraVNC\zlib-1.2.5\contrib\vstudio\vc10\x86\ZlibStatRelease\zlibstat.lib

However one thing I notice is on VC++ directories there was a path under library called H:\ultravnc_195\UltraVNC Project Root\UltraVNC\lib\debug\x86;$(LibraryPath)

I was like wait I dont have a H:\ so whats going on here. So I said what the heck. I deleted the H:\ path and added
C:\Ultra\UltraVNC\zlib-1.2.5\contrib\vstudio\vc10\x86\ZlibStatRelease and to my surprise it compiled.
------------------------------
To recap I

1)Installed VS2010
2)Install Nasm
3)Check where NASM installed
4)Right click on libjpeg-turbo-win added NASM install path to VC++ directories>Executable Directories
5)Right click on winvnc and changed VC++ directories>Library from H directory to .\zlib-1.2.5\contrib\vstudio\vc10\x86\ZlibStatRelease where zlibstat.lib is

and it compiled for me

[Rudi De Vos]

Other soltiuon for zlibstat is just to erase it from
Configuration Porperties->Linker->Input.
The framework take care of it, it doesn't need to be added manual.
(Like how it is configured for debug)

Then you can also erase the extra lib path.

tested, both zlibstat.lib and path can be removed, not needed.

[Qbfinest83]

Yup that work to. Thanks for all your help