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

"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

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

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

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?

"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