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

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

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

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

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

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

 occur.

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

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

 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

 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

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

 Symantec application wizard.

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

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

 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

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

 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

 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

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


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


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


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

 stlp45dm_static.lib; and when I remove the original libraries

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

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

 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

 makefile.txt > makefile_out.txt":

 REM Output to .

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

=1
 -oaboutdlg.obj aboutdlg.cpp

=1
 -oDLGAPP.obj DLGAPP.cpp

=1
 -omaindlg.obj maindlg.cpp

=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:

 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

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

 *))
 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

 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"

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

 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

 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\

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_

 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

 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

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

 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

 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

 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

 these three different possible definitions (that is: normal environment

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

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

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

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

 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"

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

 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

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

 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

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

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

 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



 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,

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

 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

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

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

 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

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

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

 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

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

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

 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

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


Then don't use make. See if you still get c:\sc.
 According to online documentation OPLINK simply accepts the first

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

 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

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

 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


explicitly.


 satisfy all of the public symbols uniformly throughout a given object

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

 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

 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

 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

 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

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

 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

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

 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