Sorry to post here, but the idde group is sort of silent. I have observed a small but annoying issue when linking programs from w/in the 8.49 idde.

This occurs when using the stlport includes. I have not tested it any other way.

Specifically, UNLESS the libpath c:\dm\lib is explicitly set in the project
settings in Library Directories, the link cannot complete and reports
the error:

link /NOI /DE /E /PACKF /XN /NT /ENTRY:mainCRTStartup /BAS:4194304 /A:512 @hello.LNK
Warning: C:\tmp\KERNEL32.LIB (12361600): File Not Found KERNEL32.LIB
Warning: C:\tmp\GDI32.LIB (65568): File Not Found GDI32.LIB
Warning: C:\tmp\USER32.LIB (65568): File Not Found USER32.LIB
Warning: C:\tmp\stlp45dm.lib (3459476): File Not Found stlp45dm.lib
Warning: C:\tmp\SNN.lib (12620356): File Not Found SNN.lib
Error: No Match Found for Export/ENTRY -  : mainCRTStartup
Error: C:\tmp\hello.OBJ(hello)  (3459468): Symbol Undefined __acrtused_con
Error: C:\tmp\hello.OBJ(hello)  (31): Symbol Undefined ?sbumpc@?
$basic_streambuf@std@DV?$char_traits@std@D@1@@std@@QAEHXZ
Error: C:\tmp\hello.OBJ(hello)  (7451597): Symbol Undefined ?
rdstate@ios_base@std@@QBEHXZ (int syscall std::ios_base::rdstate(void )
const )
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ?
_M_clear_nothrow@ios_base@std@@IAEXH@Z (void syscall
std::ios_base::_M_clear_nothrow(int ))
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ?
_M_check_exception_mask@ios_base@std@@IAEXXZ (void syscall
std::ios_base::_M_check_exception_mask(void ))
Error: C:\tmp\hello.OBJ(hello)  (8972012): Symbol Undefined ?
good@ios_base@std@@QBE_NXZ
Error: C:\tmp\hello.OBJ(hello)  (1): Symbol Undefined ?pubsync@?
$basic_streambuf@std@DV?$char_traits@std@D@1@@std@@QAEHXZ
Error: C:\tmp\hello.OBJ(hello)  (1): Symbol Undefined ?to_int_type@?
$char_traits@std@D@std@@SAHABD@Z (int cdecl
std::D::d::char_traits<>::to_int_type(char const &))
Error: C:\tmp\hello.OBJ(hello)  (6825758): Symbol Undefined ??3@YAXPAX@Z
(void cdecl delete(void *))
Error: C:\tmp\hello.OBJ(hello)  (3553698): Symbol Undefined ??
1ios_base@std@@UAE@XZ (syscall std::ios_base::~ios_base(void ))
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ?
flags@ios_base@std@@QBEHXZ (int syscall std::ios_base::flags(void )const )
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ?length@?
$char_traits@std@D@std@@SAIPBD@Z (unsigned cdecl
std::D::d::char_traits<>::length(char const *))
Error: C:\tmp\hello.OBJ(hello)  (3459400): Symbol Undefined ?
width@ios_base@std@@QBEHXZ (int syscall std::ios_base::width(void )const )
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ?sputn@?
$basic_streambuf@std@DV?$char_traits@std@D@1@@std@@QAEHPBDH@Z
Error: C:\tmp\hello.OBJ(hello)  (3459408): Symbol Undefined ?_M_sputnc@?
$basic_streambuf@std@DV?$char_traits@std@D@1@@std@@QAEHDH@Z
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ?
width@ios_base@std@@QAEHH@Z (int syscall std::ios_base::width(int ))
Error: C:\tmp\hello.OBJ(hello)  (8972012): Symbol Undefined __fatexit
Error: C:\tmp\hello.OBJ(hello)  (1826572): Symbol Undefined ??
0Init@ios_base@std@@QAE@XZ (syscall std::ios_base::Init::Init(void ))
Error: C:\tmp\hello.OBJ(hello)  : Symbol Undefined ??
0_Loc_init@ios_base@std@@QAE@XZ (syscall std::ios_base::_Loc_init::_Loc_init
(void ))
Error: C:\tmp\hello.OBJ(hello)  (3459392): Symbol Undefined ??
1_Loc_init@ios_base@std@@QAE@XZ (syscall std::ios_base::_Loc_init::~_Loc_init
(void ))
Error: C:\tmp\hello.OBJ(hello)  (7942676): Symbol Undefined ??
1Init@ios_base@std@@QAE@XZ (syscall std::ios_base::Init::~Init(void ))
Error: C:\tmp\hello.OBJ(hello)  (11342776): Symbol Undefined ?cin@std@@3V?
$basic_istream@std@DV?$char_traits@std@D@1@@1@A
Error: C:\tmp\hello.OBJ(hello)  (11342776): Symbol Undefined ?cout@std@@3V?
$basic_ostream@std@DV?$char_traits@std@D@1@@1@A
Errors: 24  Warnings: 5
Build failed

HOWEVER, when I add c:\dm\lib to the Library Directories, the link completes
with no errors:
link /NOI /DE /E /PACKF /XN /NT /ENTRY:mainCRTStartup /BAS:4194304 /A:512 @hello.LNK
ren .\$SCW$.EXE hello.EXE
Errors: 0  Warnings: 0
Successful build

Now, looking at the Makefile, you will see the only difference between
success and failure. The first block was when I tested debug WITH
the libpath set. The second was with RELEASE and no path set. The
error occurs only when c:\dm\lib is absent before KERNEL32....It has
nothing to do with DEBUG or RELEASE. I can reverse it and repeat
the error.

# this block links
hello.OBJ
$$SCW$$.EXE
NUL
c:\dm\lib\ KERNEL32.LIB GDI32.LIB USER32.LIB
hello.DEF;
<<

# this block does NOT link
!ELSE
.OBJ.EXE:
                $(LNK) $(LFLAGS) @$(PROJ).LNK<<
hello.OBJ
$$SCW$$.EXE
NUL
KERNEL32.LIB GDI32.LIB USER32.LIB
hello.DEF;
<<

Now, from the command line, dmc ...hello.cpp works fine with no error. I can only guess the problem is somewhere w/in the IDDE.

Here is sc.ini
[Version]
version=7.51 Build 020

[Environment]
PATH=%PATH%;%@P%
BIN=%@P%
INCLUDE=%@P%\..\stlport\stlport;%@P%\..\include;%@P%\..\mfc\include;%INCLUDE%
LIB=%@P%\..\lib;%@P%\..\mfc\lib;%LIB%
HELP=%@P%\..\help

To me, it seems to be redundant and unnecessary to have to manually add the library path to each project! Is this a problem with the IDDE? A bug possibly?

I use wine, but have been able to duplicate the problem exactly on XP as well.

--
Peter

On Mon, 19 Feb 2007 11:29:16 +0000, Peter wrote:

> Sorry to post here, but the idde group is sort of silent. I have observed a small but annoying issue when linking programs from w/in the 8.49 idde.
>
> This occurs when using the stlport includes. I have not tested it any other way.
snip...

I now tried it with several of the tutorial files, and the same error occurs. It is mandatory to include the library path in the Project. The projects provided in the tutorials will have compile failures if you try and build them.

--
Peter

Is DMC in the default location on your hard disk?

Does it work if you set the LIB environment variable to point to where the library files are?

On Mon, 19 Feb 2007 12:29:06 -0800, Walter Bright wrote:

> Is DMC in the default location on your hard disk?
>
Yes, and PATH includes c:\dm\bin

> Does it work if you set the LIB environment variable to point to where the library files are?

NO. I did set LIB=c:\dm\lib, but the error remains.

All works fine from the command line. It's just when a project is being built from w/in the IDDE.

HTH
--
Peter

Peter wrote:
> On Mon, 19 Feb 2007 12:29:06 -0800, Walter Bright wrote:
> 
>> Is DMC in the default location on your hard disk?
>>
> Yes, and PATH includes c:\dm\bin
> 
>> Does it work if you set the LIB environment variable to point to where
>> the library files are?
> 
> NO. I did set LIB=c:\dm\lib, but the error remains.
> 
> All works fine from the command line. It's just when a project is being
> built from w/in the IDDE.

Try editting \dm\bin\sc.ini to set LIB.

On Tue, 20 Feb 2007 01:14:17 -0800, Walter Bright wrote:

> Peter wrote:
>> On Mon, 19 Feb 2007 12:29:06 -0800, Walter Bright wrote:
>>
>>> Is DMC in the default location on your hard disk?
>>>
>> Yes, and PATH includes c:\dm\bin
>>
>>> Does it work if you set the LIB environment variable to point to where the library files are?
>>
>> NO. I did set LIB=c:\dm\lib, but the error remains.
>>
>> All works fine from the command line. It's just when a project is being built from w/in the IDDE.
>
> Try editting \dm\bin\sc.ini to set LIB.

This is the way sc.ini is when the problem occurs. I also tried hard-coding the LIB and all paths e.g. c:\dm\....

Problem persists.


Here is sc.ini
[Version]
version=7.51 Build 020

[Environment]
PATH=%PATH%;%@P%
BIN=%@P%
INCLUDE=%@P%\..\stlport\stlport;%@P%\..\include;%@P%\..\mfc\include;%INCLUDE%
LIB=%@P%\..\lib;%@P%\..\mfc\lib;%LIB%
HELP=%@P%\..\help
--
Peter

Peter wrote:
> Problem persists.

Beats me, it works when I try it.

On Tue, 20 Feb 2007 02:56:52 -0800, Walter Bright wrote:

> Peter wrote:
>> Problem persists.
>
> Beats me, it works when I try it.

I'll try and get more information. Will report if I get anything. Frustrating.
--
Peter

On Tue, 20 Feb 2007 02:56:52 -0800, Walter Bright wrote:

> Peter wrote:
>> Problem persists.
>
> Beats me, it works when I try it.

Well, on further review....It appears to be a wine problem, not a DMC problem or IDDE one. Apparently, even though the system PATH is set, and LIB is set in sc.ini, apparently when the IDDE spawns a child process to compile, it may not be inheriting the proper environment settings and thus not able to look in the right places. INCLUDE seems to work, and so does PATH, but not LIB.

Running the identical test under true WinXP is now OK. The XP problem I had noted before was because I had not set the PATH in the environment. Now, with that set, builds work.

Sorry to have troubled you. If I can figure out a nice workaround for wine, I'll post it.
--
Peter

Peter wrote:
> On Tue, 20 Feb 2007 02:56:52 -0800, Walter Bright wrote:
> 
>> Peter wrote:
>>> Problem persists.
>> Beats me, it works when I try it.
> 
> Well, on further review....It appears to be a wine problem, not a DMC
> problem or IDDE one. Apparently, even though the system PATH is set, and LIB
> is set in sc.ini, apparently when the IDDE spawns a child process to
> compile, it may not be inheriting the proper environment settings and thus
> not able to look in the right places. INCLUDE seems to work, and so does
> PATH, but not LIB.
> 
> Running the identical test under true WinXP is now OK. The XP problem I had
> noted before was because I had not set the PATH in the environment. Now,
> with that set, builds work.
> 
> Sorry to have troubled you. If I can figure out a nice workaround for wine,
> I'll post it.

Similar problems crop up when running the gnu shell under Windows.