↑ ↓ ← → 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?
↑ ↓ ← → "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.
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓
← → 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.
↑ ↓
← → 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.
↑ ↓
← → 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?
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next