[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 :)

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---
   Creating library
../../../../obj/Release/driver_dsound/nel_drv_dsound_win_r.lib and object
LINK : warning LNK4089: all references to "ADVAPI32.dll" discarded by
LINK : warning LNK4089: all references to "MSVCP60.dll" discarded by
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]