c++ - Environment issue with STLPort?

Berin Loritsch (14/14) May 17 2005 I am trying to compile using STLPort with the CD version of Digital Mars...

Walter (4/4) May 17 2005 Try cutting the context.cpp file down to the minimum that generates the

Berin Loritsch (7/14) May 18 2005 __stl_new is defined in the #include file. It is externally

Berin Loritsch (3/20) May 18 2005 They (__stl_new and __stl_delete) are used in stl/_alloc.h lines 135 and...
Berin Loritsch (4/21) May 18 2005 Ok, I paired it down...

Berin Loritsch (9/16) May 18 2005 Here is the problem:

Jonathan Ludwig (6/20) Jun 18 2005 I was having this same problem, but I figured it out. I was assuming th...

Walter (6/11) Jul 31 2005 that, like

tiwag (76/77) Aug 01 2005 some investigations regarding the include-path for stlport bug:

Walter (5/6) Aug 01 2005 No, since there's another iostream in \dm\include which is there for leg...

Berin Loritsch <bloritsch d-haven.org> writes:

I am trying to compile using STLPort with the CD version of Digital Mars 
Compiler, and I am using the proper command line options:

dmc -w -cpp -I/dm/stlport/stlport -Iinclude src\context.cpp 
-obuild\context.obj -mn

But I still get two errors:

C:\dm\bin\..\stlport\stlport\stl/_alloc.h(134) : Error: undefined 
identifier '__stl_new'
C:\dm\bin\..\stlport\stlport\stl/_alloc.h(135) : Error: undefined 
identifier '__stl_delete'


My code was working with the GCC compiler without issues before, so this 
is something unique to the DMC setup.  The /dm/include doesn't have any 
STL references, and I killed the %INCLUDE% environment variable, all to 
no effect.

Any ideas what is going on?

May 17 2005

"Walter" <newshound digitalmars.com> writes:

Try cutting the context.cpp file down to the minimum that generates the
error.

You can also try grepping for where __stl_new is defined in the stlport
code.

May 17 2005

Berin Loritsch <bloritsch d-haven.org> writes:

Walter wrote:
 Try cutting the context.cpp file down to the minimum that generates the
 error.
 
 You can also try grepping for where __stl_new is defined in the stlport
 code.
 
 

__stl_new is defined in the #include<new> file.  It is externally 
guarded with the #ifdef structure, and the include is through the source 
file for allocators.

I'll try and pair down the context.cpp file by commenting out everything 
that is enough to get it reproduced--I'm hoping it is a silly config 
setting or something of that nature.

May 18 2005

Berin Loritsch <bloritsch d-haven.org> writes:

Berin Loritsch wrote:
 Walter wrote:
 
 Try cutting the context.cpp file down to the minimum that generates the
 error.

 You can also try grepping for where __stl_new is defined in the stlport
 code.

 
 __stl_new is defined in the #include<new> file.  It is externally 
 guarded with the #ifdef structure, and the include is through the source 
 file for allocators.
 
 I'll try and pair down the context.cpp file by commenting out everything 
 that is enough to get it reproduced--I'm hoping it is a silly config 
 setting or something of that nature.

They (__stl_new and __stl_delete) are used in stl/_alloc.h lines 135 and 
136 respectively.  Still messing with context.h

May 18 2005

Berin Loritsch <bloritsch d-haven.org> writes:

Berin Loritsch wrote:
 Walter wrote:
 
 Try cutting the context.cpp file down to the minimum that generates the
 error.

 You can also try grepping for where __stl_new is defined in the stlport
 code.

 
 __stl_new is defined in the #include<new> file.  It is externally 
 guarded with the #ifdef structure, and the include is through the source 
 file for allocators.
 
 I'll try and pair down the context.cpp file by commenting out everything 
 that is enough to get it reproduced--I'm hoping it is a silly config 
 setting or something of that nature.

Ok, I paired it down...

As soon as I include <vector> or <memory> I run into the problem.
I tried explicitly including <new> and it did not work.

May 18 2005

Berin Loritsch <bloritsch d-haven.org> writes:

Walter wrote:
 Try cutting the context.cpp file down to the minimum that generates the
 error.
 
 You can also try grepping for where __stl_new is defined in the stlport
 code.
 
 

Here is the problem:

There is a file called <new> that is included in a few headers. 
According to the C++ language spec, "new" is a keyword and the DMC 
compiler is getting confused in the #include directive and not importing 
the file <new>--nor is it giving me an error warning either.

I am using Digital Mars Compiler Version 8.42n (from the dmc command).


I grepped the include files for all #include <new> calls and replaced 
them with #include <_new> and renamed the one file.  My issues went away.

May 18 2005

Jonathan Ludwig <Jonathan_member pathlink.com> writes:

I was having this same problem, but I figured it out.  I was assuming that, like
other compilers I've used before, I could set the INCLUDE environment variable
to the right paths.  I then tried adding -Ii:\dm\stlport\stlport to my dm
command to explicitly set the include path.  Then it worked great.  I guess this
means tha dmc doesn't use the INCLUDE environment variable?

In article <d6dfsq$h6g$1 digitaldaemon.com>, Berin Loritsch says...
I am trying to compile using STLPort with the CD version of Digital Mars 
Compiler, and I am using the proper command line options:

dmc -w -cpp -I/dm/stlport/stlport -Iinclude src\context.cpp 
-obuild\context.obj -mn

But I still get two errors:

C:\dm\bin\..\stlport\stlport\stl/_alloc.h(134) : Error: undefirned 
identifier '__stl_new'
C:\dm\bin\..\stlport\stlport\stl/_alloc.h(135) : Error: undefined 
identifier '__stl_delete'


My code was working with the GCC compiler without issues before, so this 
is something unique to the DMC setup.  The /dm/include doesn't have any 
STL references, and I killed the %INCLUDE% environment variable, all to 
no effect.

Any ideas what is going on?

Jun 18 2005

"Walter" <newshound digitalmars.com> writes:

"Jonathan Ludwig" <Jonathan_member pathlink.com> wrote in message
news:d932iv$1pf9$1 digitaldaemon.com...
 I was having this same problem, but I figured it out.  I was assuming

that, like
 other compilers I've used before, I could set the INCLUDE environment

variable
 to the right paths.  I then tried adding -Ii:\dm\stlport\stlport to my dm
 command to explicitly set the include path.  Then it worked great.  I

guess this
 means tha dmc doesn't use the INCLUDE environment variable?

It does, but the INCLUDE setting in the \dm\bin\sc.ini file overrides it.

Jul 31 2005

tiwag <tiwag_member pathlink.com> writes:

It does, but the INCLUDE setting in the \dm\bin\sc.ini file overrides it.

some investigations regarding the include-path for stlport bug:

i use dmc 8.43 CD-version
dmc - Digital Mars Compiler Version 8.42n
installed in "d:\dm"

using this ini config file
-------------------------------------------------
D:\dm\bin\sc.ini
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Version]
version=7.51 Build 020

[Environment]
PATH=%PATH%;"% P%\..\bin"
BIN="% P%\..\bin"
INCLUDE="D:\dm\stlport\stlport";"% P%\..\include";"% P%\..\mfc\include";%INCLUDE%
LIB="% P%\..\lib";"% P%\..\mfc\lib";%LIB%
HELP="% P%\..\help"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

test code
-------------------------------------------------
D:\cpp\_projects\dm\hello_stlport\hello.cpp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <iostream>
using namespace std;
int main (int argc, char *argv[])
{
cout << "Hello World!" << endl;
return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------------------------------------------
builds OK, 
if "D:\dm\stlport\stlport" is the 
VERY FIRST include path
(this time from sc.ini)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

D:\cpp\_projects\dm\hello_stlport>dmc hello
link hello,,,user32+kernel32/noi;

D:\cpp\_projects\dm\hello_stlport>hello
Hello World!

D:\cpp\_projects\dm\hello_stlport>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------------------------------------------
but fails to build
if "D:\dm\stlport\stlport" is 
NOT the VERY FIRST include path
(given the valid include dir "D:\dm\include" 
from the commandline switch -I)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:\cpp\_projects\dm\hello_stlport>dmc -ID:\dm\include hello
D:\dm\stlport\stlport\stl/_alloc.h(134) : Error: undefined identifier
'__stl_new'
D:\dm\stlport\stlport\stl/_alloc.h(135) : Error: undefined identifier
'__stl_delete'
class _STLP_CLASS_DECLSPEC __Named_exception : public _STLP_EXCEPTION_BASE {
^
D:\dm\stlport\stlport\stdexcept(56) : Error: identifier expected --- errorlevel
1

D:\cpp\_projects\dm\hello_stlport>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------------------------------------------
but works again, if we give "D:\dm\stlport\stlport" 
as VERY FIRST include path again
(given from the commandline switch -I)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:\cpp\_projects\dm\hello_stlport>dmc -ID:\dm\stlport\stlport -ID:\dm\include
hello
link hello,,,user32+kernel32/noi;

D:\cpp\_projects\dm\hello_stlport>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------------------------------------------
conclusion:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i consider this behaviour as bug, isn't it ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

HTH 
-tiwag

Aug 01 2005

"Walter" <newshound digitalmars.com> writes:

"tiwag" <tiwag_member pathlink.com> wrote in message
news:dclaj0$2org$1 digitaldaemon.com...
 i consider this behaviour as bug, isn't it ?

No, since there's another iostream in \dm\include which is there for legacy
compatibility. To use the new iostream, have it search \dm\stlport\stlport
first.

Aug 01 2005

D Programming

C/C++ Programming

Other

c++ - Environment issue with STLPort?