www.digitalmars.com         C & C++   DMDScript  

c++.stl.port - undefined: (syscall std::exception::~exception(void ))

reply Richard Haney <Richard_member pathlink.com> writes:
I get two error messages from OPLINK:

e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer) 
Error 42: Symbol Undefined ??1exception std  UAE XZ (syscall
std::exception::~exception(void ))

e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer) 
Error 42: Symbol Undefined ?what exception std  UBEPBDXZ (char const *syscall
std::exception::what(void )const )

This is without an explicit lib directory in the LIB path defined in "sc.ini".

Alternatively, if I specify the the dm\lib directory in the LIB path in "sc.ini"
as I normally expect to, I get a great many multiple definition errors, but
snn.lib is the only .lib or .obj where those "multiple definition" definitions
occur.

So in this alternative case, I figure that OPLINK is probably reading snn.lib
twice and loosing track of the fact that it has already read it once before
reading it a second time; hence the multiple definitions (somehow).

I also suppose that the object modules must contain the LIB directory
information somehow.

Also, it seems from the two error messages listed at the beginning of this
message that the two undefined symbols must me references to symbols in system
DLLs, but I don't have the fogiest idea how to get OPLINK to find the
appropriate .DLLs.

Note this project was first created with Symantec's IDDE because I want to
create a MFC dialog application.  The "e-mail_heading_analyzer.cpp" does some
symbolic analysis, but I have not yet linked it to the files generated by the
Symantec application wizard.

I don't even know whether the Symantec C++ 7.5 MFC libraries are compatable with
the dm v838 compiler, but I'm hoping that it is since I need the STLport for the
symbolic analysis in "e-mail_heading_analyzer.cpp".

Can anyone help me with this?  I am using "smake -f makefile.txt" where
"makefile.txt" is the makefile produced by the Symantec IDDE and adjusted for
the new compiler and linker.  "smake" is the smake from the Symantec C++ 7.5
package.

Richard Haney

Richard Haney
rfhaney yahoo.com
Jan 17 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Richard Haney" <Richard_member pathlink.com> wrote in message
news:bud63h$1o8f$1 digitaldaemon.com...

 I get two error messages from OPLINK:

 e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer)
 Error 42: Symbol Undefined ??1exception std  UAE XZ (syscall
 std::exception::~exception(void ))

 e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer)
 Error 42: Symbol Undefined ?what exception std  UBEPBDXZ (char const


*syscall

 std::exception::what(void )const )

 This is without an explicit lib directory in the LIB path defined in


"sc.ini".

What I'd do is go into \dm\lib and do a grep for the two names, to see what
.lib file they are defined in. Then, make sure that library is added to the
linker command.


 Alternatively, if I specify the the dm\lib directory in the LIB path in


"sc.ini"

 as I normally expect to, I get a great many multiple definition errors,


but

 snn.lib is the only .lib or .obj where those "multiple definition"


definitions

 occur.

 So in this alternative case, I figure that OPLINK is probably reading


snn.lib

 twice and loosing track of the fact that it has already read it once


before

 reading it a second time; hence the multiple definitions (somehow).


Optlink won't read the same library file twice. What library are you linking
in?



 I also suppose that the object modules must contain the LIB directory
 information somehow.


No. (You can see exactly what they contain by running obj2asm on them, or
dumpobj.)
.obj files do frequently contain a specific reference to a library name,
though.


 Also, it seems from the two error messages listed at the beginning of this
 message that the two undefined symbols must me references to symbols in


system

 DLLs, but I don't have the fogiest idea how to get OPLINK to find the
 appropriate .DLLs.


Optlink does not read DLLs. Undefined symbols get resolved from .obj files
or .lib files.


 Note this project was first created with Symantec's IDDE because I want to
 create a MFC dialog application.  The "e-mail_heading_analyzer.cpp" does


some

 symbolic analysis, but I have not yet linked it to the files generated by


the

 Symantec application wizard.

 I don't even know whether the Symantec C++ 7.5 MFC libraries are


compatable with

 the dm v838 compiler, but I'm hoping that it is since I need the STLport


for the

 symbolic analysis in "e-mail_heading_analyzer.cpp".

 Can anyone help me with this?  I am using "smake -f makefile.txt" where
 "makefile.txt" is the makefile produced by the Symantec IDDE and adjusted


for

 the new compiler and linker.  "smake" is the smake from the Symantec C++


7.5

 package.

 Richard Haney

 Richard Haney
 rfhaney yahoo.com
Jan 18 2004
parent reply Richard Haney <Richard_member pathlink.com> writes:
In article <bufqo1$2usu$2 digitaldaemon.com>, Walter says...

"Richard Haney" <Richard_member pathlink.com> wrote in message
news:bud63h$1o8f$1 digitaldaemon.com...

 I get two error messages from OPLINK:

 e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer)
 Error 42: Symbol Undefined ??1exception std  UAE XZ (syscall
 std::exception::~exception(void ))

 e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer)
 Error 42: Symbol Undefined ?what exception std  UBEPBDXZ (char const


*syscall

 std::exception::what(void )const )




..


What I'd do is go into \dm\lib and do a grep for the two names, to see what
.lib file they are defined in. Then, make sure that library is added to the
linker command.


There seems to be conflicting information in the documentation and the way
OPLINK actually functions.

grep shows that the mangled public symbols above each occur in both snn.lib and
stlp45dm_static.lib; and when I remove the original libraries (KERNEL32.LIB
GDI32.LIB USER32.LIB) from the OPLINK response file (defined in the makefile for
smake) and put the complete pathname for either stlp45dm_static.lib or snn.lib
in place of the original library names, I get more "Previous Definition
Different" error messages in each case.

In particular, in the case when the only library specified is the complete
pathname for snn.lib, I get this puzzling (redirected) output from "smake -f
makefile.txt > makefile_out.txt":

REM Output to .
C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG=1
-HF.\stdafx.SYM -o.\stdafx.PCO stdafx.h
C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG=1
-oaboutdlg.obj aboutdlg.cpp
C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG=1
-oDLGAPP.obj DLGAPP.cpp
C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG=1
-omaindlg.obj maindlg.cpp
C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG=1
-oe-mail_heading_analyzer.obj e-mail_heading_analyzer.cpp
RCC  -32  DLGAPP.rc -oDLGAPP.res
#endif
^
C:\SC\BIN\..\mfc\include\32-bit\winres.h(588) : Preprocessor warning: 'IDHELP'
is already defined
rem LIBINFO = C:\z\dm\lib\SNN.lib
rem LIB = 
C:\z\dm\bin\LINK /CO /NOI /DE /NOPACKF /XN /NT /ENTRY:WinMainCRTStartup
/BAS:4194304 /A:512 /RC   :DLGAPP.RES  DLGAPP.LNK

OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

C:\SC\bin\..\mfc\lib\nafxcwd.lib(afxmem)  Offset 04033H Record Type 0091 
Error 1: Previous Definition Different : ??2 YAPAXI Z (void *cdecl new(unsigned
))
C:\SC\bin\..\mfc\lib\nafxcwd.lib(afxmem)  Offset 04045H Record Type 0091 
Error 1: Previous Definition Different : ??3 YAXPAX Z (void cdecl delete(void
*))
C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 000BCH Record Type 0091 
Error 1: Previous Definition Different : _malloc
C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 00537H Record Type 0091 
Error 1: Previous Definition Different : _calloc
C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 00557H Record Type 0091 
Error 1: Previous Definition Different : _realloc
C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 00595H Record Type 0091 
Error 1: Previous Definition Different : _free

==== end of smake output ====

What is strange is that the linker is looking in the "C:\SC" hierarchy for
libraries.  AND MOREOVER:  The linker is looking at libraries I haven't even
specified by name.

Note that I have specified the -NL flag for the compiler.  So no directory
libraries should be specified in the object modules I create.  Note also that
I've put remark statements in the commands for linking to show the LIB variable
and the specified libraries (LIBINFO variable) explicitly.

My "C:\z\dm\bin\sc.ini" file is:

[Version]
version=7.51 Build 020

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

=== end of sc.ini ===

So it looks like OPLINK is getting the path information for libraries from my
PATH variable in the sc.ini file.  

(Incidentally, the C:\SC hierarchy is the Symantec C++ 7.5 installation with the
Digital Mars "drop-in" update.)


So there are five questions that come to mind:

(1) Why is OPLINK looking for more libraries outside of the C:\z\dm\ hierarchy?

(2) Is there a clear, concise statement somewhere for the _complete_ algorithm
that OPLINK uses to satisfy public symbols?

(3) Why is OPLINK treating "Previous Definition Different" as an error rather
than as a warning as the documentation says it should?  Even when I try using
the NODEL[executable] option to OPLINK to preserve the executable, trying to
execute the resulting executable only results in the message "$SCW$.EXE is not a
valid win32 application".  Why is the resulting executable not executable?

(4) Do the compiler and OPLINK assume effective definitions for environment
variables different than those in effect in the makefile?  When is the
information in sc.ini assumed by the compiler (and by OPLINK)?  Are the
variables (e.g., LIB) specified in the smake makefile effectively the same as
the environment variables by the same name?  If LIB is not previously defined in
the makefile, will $(LIB) in the makefile result in evaluation of the LIB
environment variable?  Is there a clear, concise statement somewhere as to how
these three different possible definitions (that is: normal environment variable
definition; sc.ini definition; LIB= definition in the makefile) of LIB interact?

(5) Can I control linking at the level of specifying exactly the libraries or
object modules to use for each public symbol?  Ideally, it would be desirable to
be able to write some flexible, generic script that specifies how public symbols
will be satisfied.  Is that possible?


Richard Haney
rfhaney yahoo.com
Jan 24 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Richard Haney" <Richard_member pathlink.com> wrote in message
news:buvcvh$nij$1 digitaldaemon.com...

 In article <bufqo1$2usu$2 digitaldaemon.com>, Walter says...

"Richard Haney" <Richard_member pathlink.com> wrote in message
news:bud63h$1o8f$1 digitaldaemon.com...

 I get two error messages from OPLINK:

 e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer)
 Error 42: Symbol Undefined ??1exception std  UAE XZ (syscall
 std::exception::~exception(void ))

 e-mail_heading_analyzer.OBJ(e-mail_heading_analyzer)
 Error 42: Symbol Undefined ?what exception std  UBEPBDXZ (char const


*syscall

 std::exception::what(void )const )




 ..


What I'd do is go into \dm\lib and do a grep for the two names, to see




what

.lib file they are defined in. Then, make sure that library is added to




the

linker command.


 There seems to be conflicting information in the documentation and the way
 OPLINK actually functions.

 grep shows that the mangled public symbols above each occur in both


snn.lib and

 stlp45dm_static.lib; and when I remove the original libraries


(KERNEL32.LIB

 GDI32.LIB USER32.LIB) from the OPLINK response file (defined in the


makefile for

 smake) and put the complete pathname for either stlp45dm_static.lib or


snn.lib

 in place of the original library names, I get more "Previous Definition
 Different" error messages in each case.

 In particular, in the case when the only library specified is the complete
 pathname for snn.lib, I get this puzzling (redirected) output from


"smake -f

 makefile.txt > makefile_out.txt":

 REM Output to .


C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG
=1

 -HF.\stdafx.SYM -o.\stdafx.PCO stdafx.h


C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG
=1

 -oaboutdlg.obj aboutdlg.cpp


C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG
=1

 -oDLGAPP.obj DLGAPP.cpp


C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG
=1

 -omaindlg.obj maindlg.cpp


C:\z\dm\bin\SC -cpp -Ae -mn -C -WA -S -3 -a8 -c -H -HO- -gf -Ab -NL -D_DEBUG
=1

 -oe-mail_heading_analyzer.obj e-mail_heading_analyzer.cpp
 RCC  -32  DLGAPP.rc -oDLGAPP.res
 #endif
 ^
 C:\SC\BIN\..\mfc\include\32-bit\winres.h(588) : Preprocessor warning:


'IDHELP'

 is already defined
 rem LIBINFO = C:\z\dm\lib\SNN.lib
 rem LIB =
 C:\z\dm\bin\LINK /CO /NOI /DE /NOPACKF /XN /NT /ENTRY:WinMainCRTStartup
 /BAS:4194304 /A:512 /RC   :DLGAPP.RES  DLGAPP.LNK

 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 C:\SC\bin\..\mfc\lib\nafxcwd.lib(afxmem)  Offset 04033H Record Type 0091
 Error 1: Previous Definition Different : ??2 YAPAXI Z (void *cdecl


new(unsigned

 ))
 C:\SC\bin\..\mfc\lib\nafxcwd.lib(afxmem)  Offset 04045H Record Type 0091
 Error 1: Previous Definition Different : ??3 YAXPAX Z (void cdecl


delete(void

 *))
 C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 000BCH Record Type 0091
 Error 1: Previous Definition Different : _malloc
 C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 00537H Record Type 0091
 Error 1: Previous Definition Different : _calloc
 C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 00557H Record Type 0091
 Error 1: Previous Definition Different : _realloc
 C:\SC\bin\..\lib\snnd.lib(dbgheap)  Offset 00595H Record Type 0091
 Error 1: Previous Definition Different : _free

 ==== end of smake output ====



All the "Previous Definition Different" error means is that the symbol is
multiply defined. That means it's defined in more than one .obj file.



 What is strange is that the linker is looking in the "C:\SC" hierarchy for
 libraries.


It looks in any directories specified by LIB in sc.ini.


 AND MOREOVER:  The linker is looking at libraries I haven't even
 specified by name.


If you run obj2asm on a .obj file, you'll see an 'includelib' statement. The
includelib statement says which library should be looked in.


 Note that I have specified the -NL flag for the compiler.  So no directory
 libraries should be specified in the object modules I create.


They'll be there in any .obj modules linked in from a library.


 Note also that
 I've put remark statements in the commands for linking to show the LIB


variable

 and the specified libraries (LIBINFO variable) explicitly.

 My "C:\z\dm\bin\sc.ini" file is:

 [Version]
 version=7.51 Build 020

 [Environment]
 PATH=%PATH%;"% P%\..\bin"
 BIN="% P%\..\bin"


INCLUDE="% P%\..\stlport\stlport";"% P%\..\include";"% P%\..\mfc\include";%I
NCLUDE%

 LIB="% P%\..\lib";"% P%\..\mfc\lib";%LIB%
 HELP="% P%\..\help"

 === end of sc.ini ===

 So it looks like OPLINK is getting the path information for libraries from


my

 PATH variable in the sc.ini file.


No, your LIB setting in your sc.ini is not referencing %PATH%. It is
referencing %LIB%, which means your environment variable LIB setting.


 (Incidentally, the C:\SC hierarchy is the Symantec C++ 7.5 installation


with the

 Digital Mars "drop-in" update.)


That's no longer supported.


 So there are five questions that come to mind:

 (1) Why is OPLINK looking for more libraries outside of the C:\z\dm\


hierarchy?

It looks in your current directory and the directory in your LIB setting
from sc.ini. Also, you said you were using C:\sc, not C:\z\dm?


 (2) Is there a clear, concise statement somewhere for the _complete_


algorithm

 that OPLINK uses to satisfy public symbols?


All it does is go down the list of libraries sequentially.


 (3) Why is OPLINK treating "Previous Definition Different" as an error


rather

 than as a warning as the documentation says it should?


Being a warning still doesn't guarantee a correct executable will be
generated. All it means is optlink will make a guess at how to fix it and
soldier on.


  Even when I try using
 the NODEL[executable] option to OPLINK to preserve the executable, trying


to

 execute the resulting executable only results in the message "$SCW$.EXE is


not a

 valid win32 application".  Why is the resulting executable not executable?


It's not executable if the linker failed to link the application.


 (4) Do the compiler and OPLINK assume effective definitions for


environment

 variables different than those in effect in the makefile?


All they do is read whatever environment variable settings that are present.


  When is the
 information in sc.ini assumed by the compiler (and by OPLINK)?


At program startup.


  Are the
 variables (e.g., LIB) specified in the smake makefile effectively the same


as

 the environment variables by the same name?


You cannot set environment variables from within make.


 If LIB is not previously defined in
 the makefile, will $(LIB) in the makefile result in evaluation of the LIB
 environment variable?  Is there a clear, concise statement somewhere as to


how

 these three different possible definitions (that is: normal environment


variable

 definition; sc.ini definition; LIB= definition in the makefile) of LIB


interact?

makefile macro names are not environment variables. Macro name expansions
are looked for by make (see www.digitalmars.com/ctg/lib.html):

  1.. Definitions from the command line.
  2.. Definitions in the makefile.
  3.. Definitions from the environment.
  4.. The macro is expanded to nothing.
I suggest that you do not use LIB in your makefile, delete LIB from your
environment, and delete the LIB line from sc.ini. Explicitly specify
libraries to the linker, and see how that goes.



 (5) Can I control linking at the level of specifying exactly the libraries


or

 object modules to use for each public symbol?  Ideally, it would be


desirable to

 be able to write some flexible, generic script that specifies how public


symbols

 will be satisfied.  Is that possible?


You can use lib to pull specific modules out of a library and link them in
explicitly.
Jan 25 2004
parent reply Richard Haney <Richard_member pathlink.com> writes:
In article <bv18ie$gfn$1 digitaldaemon.com>, Walter says...

"Richard Haney" <Richard_member pathlink.com> wrote in message
news:buvcvh$nij$1 digitaldaemon.com...

 ...




..

 What is strange is that the linker is looking in the "C:\SC" hierarchy for
 libraries.


It looks in any directories specified by LIB in sc.ini.


When I execute "set" at the MS-DOS command prompt, I get a long, alphabetized
list of environment variables with their values, but LIB is not among them.  So
it still looks like OPLINK must be getting the C:\SC info from the PATH
variable.  Note that the pathnames for the compiler, linker, and sc.ini are
Digital Mars pathnames C:\z\dm\bin\SC, C:\z\dm\bin\LINK, and C:\z\dm\bin\sc.ini,
respectively.  I only used C:\SC tools to create source modules, the original,
unmodified makefile, DLGAPP.rc, and DLGAPP.DEF -- the only input files to the
Digital Mars compiler and linker, but a search through those files yields no
relevant reference in those files explicitly to the C:\SC hierarchy.  (Note that
the makefile has been modified to use the Digital Mars compiler and linker.)  So
it looks like OPLINK must be getting "C:\SC" from my PATH environment variable.

The only minor exception to the above was the use of RCC (in C:\SC\bin per PATH
default), which I've now changed to the Digital Mars C:\z\dm\bin\RCC in the
makefile.  The result is exactly the same in the smake standard output, except
that in the "preprocessor" warning message the "BIN" in
C:\SC\BIN\..\mfc\include\32-bit\winres.h is now lower case and RCC now has the
complete dm pathname "C:\z\dm\bin\RCC".  So the only other possibility that
comes to mind is that somehow the binary .RES file might have had that
information and that OPLINK was using that information to guess at directory
information for libraries.  But there is no reference to C:\SC in the DLGAPP.rc
that RCC compiles to create DLGAPP.res; so could RCC be putting the C:\SC
information into DLGAPP.res from RCC's built-in information?  And then could
OPLINK be using that information to create conjectured library directories?  The
C:\SC information certainly isn't in the short DLGAPP.DEF file, which is input
to OPLINK (See response file definition below).  And the (Digital Mars)
C:\z\dm\lib libraries shouldn't have the "C:\SC" information; or do they?

(Note: I have known gnu make, per examination of the its source, to use
otherwise undocumented, built-in, "standard-guess" default directories when all
other directories fail.  So I suspect such things might be common practice in
development tools and that there could be some "legacy" code in the Digital Mars
RCC or OPLINK that could be supplying "C:\SC" as an undocumented "standard
guess".  One other possibility comes to mind: Since I am using Symantec's smake
to run the makefile, perhaps smake is putting "C:\SC" into the process in some
underhanded, undocumented way, as, for example, a default directory or search
path of some sort.)

It is also a puzzle why, even before OPLINK executes, the Digital Mars RCC seems
to be producing the warning message ostensibly from a "preprocessor" with these
puzzling facts: (1) No preprocessor command line appears before the warning
message in the smake output; (2) Even this warning message has "C:\SC"
information in it even though there seems to be no Symantec tools (or files with
"C:\SC" information) invoked in the makefile.

So it looks like C:\z\dm\bin\RCC might be introducing the C:\SC information from
its internal information or perhaps the PATH variable.


Incidentally, the relevant response file definition is:

$(LNK) $(LFLAGS)  <<$(PROJ).LNK
\stdafx.PCO+
aboutdlg.OBJ+
DLGAPP.OBJ+
maindlg.OBJ+
e-mail_heading_analyzer.OBJ
$$SCW$$.EXE
NUL
$(LIBINFO)
DLGAPP.DEF;
<<

(This is where DLGAPP.DEF figures as input to OPLINK.)

and LIBINFO in this case is defined as

LIBINFO = C:\z\dm\lib\SNN.lib


..


 My "C:\z\dm\bin\sc.ini" file is:

 [Version]
 version=7.51 Build 020

 [Environment]
 PATH=%PATH%;"% P%\..\bin"
 BIN="% P%\..\bin"


INCLUDE="% P%\..\stlport\stlport";"% P%\..\include";"% P%\..\mfc\include";%I
NCLUDE%

 LIB="% P%\..\lib";"% P%\..\mfc\lib";%LIB%
 HELP="% P%\..\help"

 === end of sc.ini ===




..


It looks in your current directory and the directory in your LIB setting
from sc.ini. Also, you said you were using C:\sc, not C:\z\dm?



No, as far as I know I am not using C:\sc in the make.


..


 (3) Why is OPLINK treating "Previous Definition Different" as an error


rather

 than as a warning as the documentation says it should?


Being a warning still doesn't guarantee a correct executable will be
generated. All it means is optlink will make a guess at how to fix it and
soldier on.


According to online documentation OPLINK simply accepts the first definition it
finds for any given public symbol.  Yet, OPLINK output calls subsequent
definitions of the same public symbol each an "Error", and the /DE switch seems
to treat them as errors, not simply warnings.  If it turns out that any first
definition of a public symbol is not the correct one, I would think that some
other type of error message (such as a "page fault" message) or other
misbehavior from the executable might occur rather than the message "$SCW$.EXE
is not a valid win32 application".  I would think that if OPLINK uses the first
usable definition for each public symbol and no other error messages are
generated (that is, other than the "Previous Definition Different" messages),
OPLINK would not have any "knowledge" that any of those links are incorrect, and
thus would not have any reason to effectively "mark" or create the executable as
"not a valid win32 application" and to leave it as such.  If there really is
some serious defect in the executable that OPLINK could know about (such as not
being a valid win32 application), why doesn't OPLINK report an error message to
that effect and provide as specific diagnostic information as possible as to how
the executable is defective?  As soon as it becomes clear to OPLINK that a valid
win32 application cannot be created, I would hope that OPLINK would immediately
report that fact and provide as specific diagnostic information  as possible as
to how and where the linking has failed.  The mere fact that there are multiple
definitions for public symbols is no indication of a failure to correctly link
the modules to create the executable, and so it seems such a list of messages
suggesting potential defects should not be considered a sufficient diagnostic
when OPLINK has definite information as to fatal defects.


  Even when I try using
 the NODEL[executable] option to OPLINK to preserve the executable, trying


to

 execute the resulting executable only results in the message "$SCW$.EXE is


not a

 valid win32 application".  Why is the resulting executable not executable?


It's not executable if the linker failed to link the application.


But the only error (or "warning"?)  messages from OPLINK are the "Previous
Definition Different" messages.  That means that OPLINK already has satisfied
all public symbols.  Yes?
So that seems to say that OPLINK has not failed to link the application.  Yes?
So then why is the executable not executable?




 (5) Can I control linking at the level of specifying exactly the libraries


or

 object modules to use for each public symbol?  Ideally, it would be


desirable to

 be able to write some flexible, generic script that specifies how public


symbols

 will be satisfied.  Is that possible?


You can use lib to pull specific modules out of a library and link them in
explicitly.


Do I have to use the same set of input object modules in the same sequence to
satisfy all of the public symbols uniformly throughout a given object module A?
Is it possible to key a separate list of input modules to each public symbol in
module A so that each public symbol in module A has its own list of object
modules to search independently of the input lists for the other public symbols
in module A?

It seems that the possibilities here could get quite complicated; hence my
question above about (ultimately) the possibility of some sort of flexible
script language to control the correspondence between public symbols and the
ordered lists of object modules to search to satisfy those public symbols.
Ultimately, one would like to be able to provide a separate list of object
modules for each public symbol; but in many cases that level of (potentially
tedious) detail in control might not be necessary; so more generic ways of
defining such lists would also be of interest; hence, the idea of some sort of
script language (with compound statements: if, while, for, etc.) to control the
details of linking.

Also, is it possible in a link command line or response file to refer to an
object module xx.obj in a library yy.lib as something like yy.lib(xx.obj) so
that no extraction is needed using lib?
Jan 26 2004
parent "Walter" <walter digitalmars.com> writes:
"Richard Haney" <Richard_member pathlink.com> wrote in message
news:bv464v$29p2$1 digitaldaemon.com...

 What is strange is that the linker is looking in the "C:\SC" hierarchy






for

 libraries.


It looks in any directories specified by LIB in sc.ini.


 When I execute "set" at the MS-DOS command prompt, I get a long,


alphabetized

 list of environment variables with their values, but LIB is not among


them.  So

 it still looks like OPLINK must be getting the C:\SC info from the PATH
 variable.


If you suspect that, then take c:\sc out of the PATH. Simplify, simplify,
simplify is the only way to solve these kinds of problems.


 (Note: I have known gnu make, per examination of the its source, to use
 otherwise undocumented, built-in, "standard-guess" default directories


when all

 other directories fail.  So I suspect such things might be common practice


in

 development tools and that there could be some "legacy" code in the


Digital Mars

 RCC or OPLINK that could be supplying "C:\SC" as an undocumented "standard
 guess".  One other possibility comes to mind: Since I am using Symantec's


smake

 to run the makefile, perhaps smake is putting "C:\SC" into the process in


some

 underhanded, undocumented way, as, for example, a default directory or


search

 path of some sort.)


You can test your assumption by running:

    grep -r c:\sc link.exe

(I just ran it, the string does not exist in link.exe.) grep is a
spectacularly useful tool <g>. No need to guess about things with it. You
should also be familiar with obj2asm and dumpobj, they'll give you much help
about what is actually in an object file. Also, generate .lst files using
lib. That will tell you exactly what modules and publics are in a .lib.



 It is also a puzzle why, even before OPLINK executes, the Digital Mars RCC


seems

 to be producing the warning message ostensibly from a "preprocessor" with


these

 puzzling facts: (1) No preprocessor command line appears before the


warning

 message in the smake output; (2) Even this warning message has "C:\SC"
 information in it even though there seems to be no Symantec tools (or


files with

 "C:\SC" information) invoked in the makefile.


RCC has absolutely nothing to do with object files and libraries.


 Incidentally, the relevant response file definition is:

 $(LNK) $(LFLAGS)  <<$(PROJ).LNK
 \stdafx.PCO+
 aboutdlg.OBJ+
 DLGAPP.OBJ+
 maindlg.OBJ+
 e-mail_heading_analyzer.OBJ
 $$SCW$$.EXE
 NUL
 $(LIBINFO)
 DLGAPP.DEF;
 <<

 (This is where DLGAPP.DEF figures as input to OPLINK.)

 and LIBINFO in this case is defined as

 LIBINFO = C:\z\dm\lib\SNN.lib



I once again recommend simplify, simplify, simplify your build process.
Replace your makefile and make with a simple command line .bat file. That
way, you will be guaranteed that no underhanded effects of make will be
happening.


It looks in your current directory and the directory in your LIB setting
from sc.ini. Also, you said you were using C:\sc, not C:\z\dm?


 No, as far as I know I am not using C:\sc in the make.


Then don't use make. See if you still get c:\sc.


 According to online documentation OPLINK simply accepts the first


definition it

 finds for any given public symbol.  Yet, OPLINK output calls subsequent
 definitions of the same public symbol each an "Error", and the /DE switch


seems

 to treat them as errors, not simply warnings.


I suggest reverting to using the command line tools until you get a
successful link. That is a much simpler process.


 But the only error (or "warning"?)  messages from OPLINK are the "Previous
 Definition Different" messages.  That means that OPLINK already has


satisfied

 all public symbols.  Yes?
 So that seems to say that OPLINK has not failed to link the application.


Yes?

 So then why is the executable not executable?


What matters is there are multiple definitions pulled in. That problem needs
to be solved. What happens afterwards is not important.



You can use lib to pull specific modules out of a library and link them




in

explicitly.


 Do I have to use the same set of input object modules in the same sequence


to

 satisfy all of the public symbols uniformly throughout a given object


module A?

It does not matter what order they are in as far as resolving symbols goes.


 Is it possible to key a separate list of input modules to each public


symbol in

 module A so that each public symbol in module A has its own list of object
 modules to search independently of the input lists for the other public


symbols

 in module A?


No.


 It seems that the possibilities here could get quite complicated; hence my
 question above about (ultimately) the possibility of some sort of flexible
 script language to control the correspondence between public symbols and


the

 ordered lists of object modules to search to satisfy those public symbols.
 Ultimately, one would like to be able to provide a separate list of object
 modules for each public symbol; but in many cases that level of


(potentially

 tedious) detail in control might not be necessary; so more generic ways of
 defining such lists would also be of interest; hence, the idea of some


sort of

 script language (with compound statements: if, while, for, etc.) to


control the

 details of linking.


It doesn't need to be complicated at all. What is complicated is your
current build process. That's what needs to be simplified. Once that is
done, I suggest yanking out of the libraries the modules that contain the
multiply defined symbols, which will then tell you why those modules were
referenced in the first place (they'll show up as undefined symbols by the
link step).



 Also, is it possible in a link command line or response file to refer to


an

 object module xx.obj in a library yy.lib as something like yy.lib(xx.obj)


so

 that no extraction is needed using lib?


No need. lib is a trivial program to run, just use:

    lib mylib -foo;            deletes foo.obj from mylib.lib
    lib mylib *foo;            extracts foo.obj from mylib.lib
    lib mylib +foo;            adds foo.obj to mylib.lib
    lib mylib -+foo;        replaces foo.obj in mylib.lib
Jan 27 2004