• Richard (60/60) Oct 24 2002 Hi
• Walter (28/84) Oct 24 2002 Hmm. Try removing -C.
• Richard (14/15) Oct 29 2002 Tried that, but lib still refused to compile. Also tried in my project a...
• Walter (9/25) Oct 29 2002 I'm glad you were able to solve the problem.

Richard <fractal clark.net> writes:

Hi

Am having trouble with latest download update for CD version and stlport.

The compile of stlport dies immediatly in "c_local.c". And this is with latest
8.30 update. The only way it would compile was *with* support for stl iostream
enabled in stlport\src\config (_STLP_NO_NEW_IOSTREAMS undefined).

After it compiled, I started getting some errors, so reinstalled from CD to
8.29n, installed 8.30 upgrade, and recompiled stlport with iostream enabled.
Changed my path to point to stlport as per readme by mod of sc.ini and
environment. Still no luck on stl lib compile with iostreams turned off. But
libs compiled with iostream support enabled.

Ok.. so what.. the libs compiled right..

Well, I started getting some odd behavior in compiling a program using <string>
and <vector>. When #include <string> appeared first, the project compiled fine..
but with #include <vector> before <string> the messages following this note
appeared.

And.. so what.. just put <string> first..

Yeah, but then I started getting some funky deallocation related access
violations when allowing a <map> to destroy some strings with erase() and
pop_back(). And the problems reported below are related to basic_string
character trait allocation.

So I did a search in stlport to see if there was some easy define or something
to help, and it was like a jungle with no clear exit strategy. After a while, it
seemed clear that I am not qualified to modify STL source files. 

I noticed there was a post that suggested a workaround for the problem, and then
Walter said he posted fix on download site. BUT I download CD upgrade with stl
stuff and get problem noted earlier..

Please help.

Richard

sc Appliance.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oAppliance.obj 
sc Connection.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oConnection.obj 
sc Exception.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oException.obj 
sc FDsets.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oFDsets.obj 
sc Main.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1 -oMain.obj 
sc Proxy.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1 -oProxy.obj

sc Socket.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oSocket.obj 
sc Thread.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oThread.obj 
sc WinsockBase.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
-oWinsockBase.obj 
link /CO /NOI /DE /NOPACKF /XN /NT /ENTRY:mainCRTStartup /BAS:4194304 /A:512
 auditor.LNK 
Error: D:\apps\digital_mars\auditor\Connection.OBJ(Connection)  (6826083):
Previous Definition Different :
??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_string DV?$char_traits D  V?$
Error: D:\apps\digital_mars\auditor\Main.OBJ(Main)  (6826083): Previous
Definition Different :
??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_string DV?$char_traits D  V?$
Error: D:\apps\digital_mars\auditor\Proxy.OBJ(Proxy)  (6826083): Previous
Definition Different :
??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_string DV?$char_traits D  V?$
Error: D:\apps\digital_mars\auditor\Socket.OBJ(Socket)  (6826083): Previous
Definition Different :
??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_string DV?$char_traits D  V?$
Lines Processed: 1115770  Errors: 4  Warnings: 0
Build failed

"Walter" <walter digitalmars.com> writes:

Hmm. Try removing -C.

"Richard" <fractal clark.net> wrote in message
news:ap9skg$1090$1 digitaldaemon.com...
 Hi

 Am having trouble with latest download update for CD version and stlport.

 The compile of stlport dies immediatly in "c_local.c". And this is with

latest
 8.30 update. The only way it would compile was *with* support for stl

iostream
 enabled in stlport\src\config (_STLP_NO_NEW_IOSTREAMS undefined).

 After it compiled, I started getting some errors, so reinstalled from CD

to
 8.29n, installed 8.30 upgrade, and recompiled stlport with iostream

enabled.
 Changed my path to point to stlport as per readme by mod of sc.ini and
 environment. Still no luck on stl lib compile with iostreams turned off.

But
 libs compiled with iostream support enabled.

 Ok.. so what.. the libs compiled right..

 Well, I started getting some odd behavior in compiling a program using

<string>
 and <vector>. When #include <string> appeared first, the project compiled

fine..
 but with #include <vector> before <string> the messages following this

note
 appeared.

 And.. so what.. just put <string> first..

 Yeah, but then I started getting some funky deallocation related access
 violations when allowing a <map> to destroy some strings with erase() and
 pop_back(). And the problems reported below are related to basic_string
 character trait allocation.

 So I did a search in stlport to see if there was some easy define or

something
 to help, and it was like a jungle with no clear exit strategy. After a

while, it
 seemed clear that I am not qualified to modify STL source files.

 I noticed there was a post that suggested a workaround for the problem,

and then
 Walter said he posted fix on download site. BUT I download CD upgrade with

stl
 stuff and get problem noted earlier..

 Please help.

 Richard

 sc Appliance.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oAppliance.obj
 sc Connection.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oConnection.obj
 sc Exception.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oException.obj
 sc FDsets.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oFDsets.obj
 sc

Main.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1 -oMain.obj
 sc

Proxy.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1 -oProxy.ob
j
 sc Socket.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oSocket.obj
 sc Thread.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oThread.obj
 sc WinsockBase.cpp -Ae -r -mn -C -WA -S -3 -a8 -c -gf -D_CONSOLE=1 -D_MT=1
 -oWinsockBase.obj
 link /CO /NOI /DE /NOPACKF /XN /NT /ENTRY:mainCRTStartup /BAS:4194304

/A:512
  auditor.LNK
 Error: D:\apps\digital_mars\auditor\Connection.OBJ(Connection)  (6826083):
 Previous Definition Different :

??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_strin
g DV?$char_traits D  V?$
 Error: D:\apps\digital_mars\auditor\Main.OBJ(Main)  (6826083): Previous
 Definition Different :

??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_strin
g DV?$char_traits D  V?$
 Error: D:\apps\digital_mars\auditor\Proxy.OBJ(Proxy)  (6826083): Previous
 Definition Different :

??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_strin
g DV?$char_traits D  V?$
 Error: D:\apps\digital_mars\auditor\Socket.OBJ(Socket)  (6826083):

Previous
 Definition Different :

??$__get_c_string DV?$char_traits D  V?$allocator D    YAPBDABV?$basic_strin
g DV?$char_traits D  V?$
 Lines Processed: 1115770  Errors: 4  Warnings: 0
 Build failed

Richard <fractal clark.net> writes:

In article <apaiej$1ms8$2 digitaldaemon.com>, Walter says...
Hmm. Try removing -C.

Tried that, but lib still refused to compile. Also tried in my project after
using lib compiled with stream support to see if odd memory behavior evaporated.
No diff. But the problem did go away..

The problem was header mismanagement in my code. After a complete review of
header insertion the problem evaporated. My guess is that I was include
iostream.h in a few places before <vector> or other stl and caused ambiguity in
defines or structs.

So now I do:

#include stl headers
#include windows headers
#include c runtime headers
#include my headers

Richard

"Walter" <walter digitalmars.com> writes:

I'm glad you were able to solve the problem.

I try to make all the headers on my own projects independent of include
order, I suppose the stlport designers didn't do that.

"Richard" <fractal clark.net> wrote in message
news:aplri8$28g0$1 digitaldaemon.com...
 In article <apaiej$1ms8$2 digitaldaemon.com>, Walter says...
Hmm. Try removing -C.

 Tried that, but lib still refused to compile. Also tried in my project

after
 using lib compiled with stream support to see if odd memory behavior

evaporated.
 No diff. But the problem did go away..

 The problem was header mismanagement in my code. After a complete review

of
 header insertion the problem evaporated. My guess is that I was include
 iostream.h in a few places before <vector> or other stl and caused

ambiguity in
 defines or structs.

 So now I do:

 #include stl headers
 #include windows headers
 #include c runtime headers
 #include my headers

 Richard