[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nel] stl port problem remains, only a few warnings left otherwise
From: |
Vincent Caron |
Subject: |
Re: [Nel] stl port problem remains, only a few warnings left otherwise |
Date: |
Sun, 24 Nov 2002 16:50:47 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 |
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.