I have a problem linking code with the AIX xlC Compiler/Linker.
The result of the link step is as follows:
0706-317 ERROR: Unresolved or undefined symbols detected:
Symbols in error (followed by references) are
dumped to the load map.
The -bloadmap: option will create a load map
.List::~List()
.Listiter::Listiter(List&)
.Const_listiter::next()
.Listiter::~Listiter()
.List::List()
.List::put(const Path&)
.List::List(const List&)
I use C++ Standard Components (a class library from UNIX Sys labs)
List and Listiter is on (templated) class of this library. Also Path
which I am not using at all.
I got a template instantiation file tempinc/List.C, which looks as
follows:
/*0780858105*/#include "/usr/Hirschmann/version1.0/../USL/List.h"
/*0000000000*/#include "/usr/Hirschmann/version1.0/../USL/List.c"
/*0781453702*/#include "/usr/Hirschmann/version1.0/mibobject.h"
/*0781453701*/#include "/usr/Hirschmann/version1.0/mibattribute.h"
/*0781559342*/#include "/usr/Hirschmann/version1.0/logentry.h"
/*0781562233*/#include "/usr/Hirschmann/version1.0/oid.h"
/*0780865676*/#include "/usr/lpp/xlC/include/OV/OVsnmpApi.h"
/*0781453703*/#include "/usr/Hirschmann/version1.0/optionmenu.h"
/*0781210265*/#include
"/usr/Hirschmann/version1.0/../Motif++1.2/headers/XMSeparator.hh"
class OptionMenu;
class LogEntry;
#pragma define(List_of_p)
#pragma define(List_of_p)
#pragma define(List_of_p)
#pragma define(List)
#pragma define(List)
#pragma define(List)
#pragma define(List_of_p)
#pragma define(List_of_p)
#pragma define(List_of_piter)
#pragma define(Const_list_of_piter)
#pragma define(Listiter)
#pragma define(Const_listiter)
#pragma define(List_of_piter)
#pragma define(Const_list_of_piter)
#pragma define(List_of_p)
#pragma define(List_of_piter)
#pragma define(Const_list_of_piter)
#pragma define(List_of_piter)
#pragma define(Const_list_of_piter)
#pragma define(Listiter)
#pragma define(List)
#pragma define(Const_listiter)
#pragma define(Listiter)
#pragma define(Const_listiter)
#pragma define(Listiter)
#pragma define(Const_listiter)
#pragma define(List_of_piter)
#pragma define(Const_list_of_piter)
#pragma define(List_of_p)
#pragma define(List_of_piter)
#pragma define(Const_list_of_piter)
#pragma define(lnnk_ATTLC)
#pragma define(lnnk_ATTLC)
#pragma define(lnnk_ATTLC)
#pragma define(lnnk_ATTLC)
#pragma undeclared
This file doesn't contain any e.g. List lines.
I don't know why the unresolved external
error occurs. I think it can't be a name demangling problem,
because List is a C++ source.
ANSWER
Please try the "-qlanglvl=compat" option on the compiler command
line. If this does not work we will have to recreate the problem
in our lab.
In its current form, we cannot recreate this problem because we
do not have the C++ Standards Components List class library. In
order to comment further on this item, we will have to attempt to
compile a test case and follow the output of the compiler and
linker to help us narrow down our search through the test case
for the cause of the problem. This leaves you with the
following options:
1) Develop a test case which we can use to recreate the problem
in our lab. I will explain how to do this later.
2) Contact UNIX Sys Labs support group for C++ Standard
Components List class library. Typically, if a developer
claims support for a hardware platform, they have tested
their product on that platform, and therefore they may be
more familiar with how to set up their product on our
hardware.
One important question you may want to ask them is whether
or not they support the RISC System/6000 AIX platform and
C Set ++ or XL C++.
Please note that there are differences between our compiler
and other C++ compilers. IBM bases its C++ compilers on the
latest proposed ANSI C++ language working paper. This allows
our C++ to be compliant with industry standards. Since other
compilers may not be compliant, it is not our intention to be
compatible with all other compilers. We do, however, provide
the "-qlanglvl=compat" option which makes it easier to port
code from other C++ compilers to our compiler.
If you decide that you would like to send us a test case so
that we can pursue this issue further, then you will need to
follow some guidelines. Attempt to recreate the problem in
a way that does not depend on the product. If you suspect
that a section of code in the product is responsible for the
problem (for example, if you suspect the code which you sent
in your first append), then copy the code to a module and
make a driver for it. The driver plus the copied code should
constitute a stand-alone test case - that is, you should be
able to send us a package which includes only the copied
code, the driver, and instructions for reproducing the
problem, and from this alone we should be able to recreate
the problem. Test your test case on your own machine to make
certain that it does reproduce the problem.
In addition to the above, the information you send should
comply with the following:
1) The test case can contain no more than 2 pages of code.
Test cases with more than 2 pages of code are considered
debugging cases and are not appropriate for this line of
support. If you need this kind of support, then you may
be able to set up a consulting contract with an IBM
support facility in your area.
2) The test case should contain no bugs other than the one
which we are trying to exhibit. If we detect any other
bugs, we will reject the test case without further
analysis.
3) The test case should include all instructions necessary
to reproduce the problem.
4) The test case should include information on the customer
configuration, including your level of AIX, you computer's
model number, whether you are using XL C++ or C Set ++,
the exact level of the compiler, and all PTFs relevant to
your AIX level and to the compiler.
S e a r c h - k e y w o r d s:
C++
WWQA: ITEM: RTA000065210 ITEM: RTA000065210
Dated: 10/1995 Category: ITSAI6000LA
This HTML file was generated 99/06/24~12:43:24
Comments or suggestions?
Contact us