Re: [Nel] stl port problem remains, only a few warnings left otherwise

[Vincent Caron]

Frederick Desimpel wrote:
> i still get the link error because it doesnt find an stlport lib file, why
> don't i have it? Please help, it's the only error i still have.
>
> LINK : fatal error LNK1104: cannot open file "stlport_vc6_debug.lib" --is
> this the stlport_vc6_stldebug_static.lib ?--

These are not the same libray files : the first one makes your program 
link against the DLL version of STLport while the latter one statically 
links (=embeds) STLport in your program. NeL uses the DLL version. It is 
possible you didn't build the DLL version of STLport. However the 'all' 
target shoul build all of what you need, taken from STLport-4.5.3/INSTALL :

"Using appropriate makefile, do "make clean all" to build the STLport 
libraries (makefiles are set up to build several different flavors - 
debug/nondebug, static/dynamic versions)"


> also, vc says while compiling: 'Using STLport version ??? in normal mode
> is this a 'normal' mode as opposed to unicode mode? Then your answer doesn't
> fit completely, because before i used 4.5, and it also said 'using STLport
> version 4.5 in normal mode'.

This is written out by a #pragma in nel/src/misc/common.cpp. The 
'normal' mode is to be compared to the 'stldebug' mode. There are 3 
types of build for STLport :

- release  : links against release C runtime (MSVCRT)
- debug    : links against debug C runtime (MSCVRTD)
- stldebug : links against debug C runtime, AND adds a wealth of sanity 
checking code

The NeL message makes the distinction between the release/debug and the 
stldebug versions. You'll notice NeL projects have four targets :

- Release (no mistery)
- ReleaseDebug: some debug code compiled in, but links against release CRT
- DebugFast : more debug code compiled in, links against debug CRT and 
debug STLport
- Debug : full debug code (huge and slow binaries), links against debug 
CRT and stldebug STLport

The switch between release and debug/stldebug is automatically done by 
STLport using the standard _DEBUG macro. Then, the distinction between 
debug and stldebug is made by the __STL_DEBUG macro.


> I think i'l stick with 4.5.3, seems to work well. maybe i have to compile
> STLport with the vc6.mak file instead of the vc6_unicode.mak file? or is
> this what you meant?

Unless you need Unicode and you know what you're doing, use the 
'vc6.mak' file.


> and those C4786 warnings? (identifier truncated to 255 chars in debug info)
> I still get a whole lot of those in debug builds. do those relate  to the
> unicode/normal stlport too? i didn't make that up in your answer.

It should disappear if you don't use the stldebug version of STLport. 
Extreme templatization makes symbol names grow pretty wildly, and VC6 
has a hard limit of 255 chars. This is not critical, since it means than 
you should expect strange behaviour in the debugger while debugging in 
STLport code (symbol not found or found multiple times), but anyway 
you're already braindead if you are debugging in STLport code :)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/C4786.asp



> L:\nevrax\nel\src\misc\system_info.cpp(463) : warning C4700: local variable
> 'p' used without having been initialized
> L:\nevrax\nel\src\misc\system_info.cpp(468) : warning C4700: local variable
> 'p' used without having been initialized
> L:\nevrax\nel\src\misc\system_info.cpp(473) : warning C4700: local variable
> 'p' used without having been initialized
>
> L:\nevrax\nel\src\net\service.cpp(1530) : warning C4700: local variable 'p'
> used without having been initialized

This pb belongs to acrobatic macroized code from ... Vianney :). Here's 
the faulty piece of code in nel/include/nel/misc/command.h :

  __type p;
  ls << p;

Which logically gives you an unitialized var when __type is a basic type 
(ie. not an object, lacks a constructor). This is what happens in the 
mentioned .cpp files. The warning basically shows that if reading from 
the 'ls' input stream fails, p content is undefined. And that it is not 
handled.


> ---Configuration: driver_dsound - Win32 Release---
> [...]
> Linking...
>    Creating library
> ../../../../obj/Release/driver_dsound/nel_drv_dsound_win_r.lib and object
> ../../../../obj/Release/driver_dsound/nel_drv_dsound_win_r.exp
> LINK : warning LNK4089: all references to "ADVAPI32.dll" discarded by
> /OPT:REF
> LINK : warning LNK4089: all references to "MSVCP60.dll" discarded by
> /OPT:REF
>
> what does it mean?

This is an optimization : if you explicitely link against a given 
library but your program happens to use none of its symbols, then it 
decides to remove the explicit DLL dependency. Here the generated 
library or executable won't claim the ADVAPI32 and MSVCP60 DLLs at 
runtime even it they were explicitely given in the link stage of the 
project. This can be a worry when those DLLs embed some init/cleanup 
code, ie. they need to be loaded even if you don't use their services. 
This is not the case here.