www.digitalmars.com         C & C++   DMDScript  

c++ - Environment issue with STLPort?

reply 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
next sibling parent reply "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
next sibling parent reply 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
next sibling parent 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
prev sibling parent 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
prev sibling parent 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
prev sibling parent reply 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
parent reply "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

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

 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

 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
parent reply 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
parent "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