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?

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.

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.

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

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.

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.

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?

"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.

>
>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

"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.