This project has several dir with sources and each one of them I have
made as a lib. I could build and produce these lib files also.
I wrote an app to test these and in the app using SOURCELIBS i'm linking
all these lib files - But they seem to be interdependent and generating
lots of unresolved external... My app sources has SOURCELIBS like this :-
SOURCELIBS=\
$(_SYSGENSDKROOT)\lib\$(_CUINDPATH)\acpi_hardware.lib\
$(_SYSGENSDKROOT)\lib\$(_CUINDPATH)\acpi_utilities.lib\
$(_SYSGENSDKROOT)\lib\$(_CUINDPATH)\acpi_tables.lib\
$(_SYSGENSDKROOT)\lib\$(_CUINDPATH)\acpi_events.lib\
$(_SYSGENSDKROOT)\lib\$(_CUINDPATH)\acpi_namespace.lib
The above list is grown from bottom up as i compiled and tried to
resolve the unresolved externals. but now after adding
acpi_hardware.lib, this lib file is generating unresolved externals
which are actually present in acpi_utilities.lib .....
Is there any better way of doing things to avoid this dead lock ?
Regards
Esha
--
Luca Calligaris (MVP-Windows Embedded)
l.calliga...@eurotech.it.nospam
www.eurotech.it
"Esha" <iimean...@yahoo.com> ha scritto nel messaggio
news:eNFF357h...@TK2MSFTNGP05.phx.gbl...
"Luca Calligaris [eMVP]" wrote:
> .
>
I'm not able to link these lib files to the app. App still gives
unresolved symbols.
The over all development I have done is,
1. There are 8 directories each of with creates their .lib files -
successful
2. Added and app to test these libs hence in the sources, added
TARGETLIBS with all the 8 libs - unsuccessful.
I had thought that these libs need not have to be in a sequence when
being added in the TARGETLIBS since they are static libraries and also
because of the very fact that they are statically linked libraries,
there is no need to have a .def file with the export functions....
Should I have to create a DLL linking with all these libs and then
exporting the required functions in the .def file so that that this dll
can be used by the application ?
Its all confusing... Please suggest
Regards
Esha
So is the confusion about which way to go ?
Regards
Esha
According to me, you should
1. Include the required header files (Which have the declarations of the
functions you are calling in the LIB files) and mention their paths in the
sources file.
2. Include the LIB files and their paths in the sources file.
Header File paths should be mentioned under "INCLUDES=" section and LIB
files under "TARGETLIBS="section in the sources file.
Hope this helps.
-R.Gurusamy
"Esha" wrote:
> .
>
For example, if you compile the library as a C Static Library but
include the header (or function declarations) from C++ source without
explicitly stating they are C they will be used as C++ Symbols.
e.g.
--- Start mylibfile.c, this is used in mylib.lib --
BOOL CoolFunc(int value)
{
if (value > 0)
return TRUE;
else
return FALSE;
}
-- End mylibfile.c
-- Start mylib.h, could also just be a function prototype in the
callers file --
BOOL CoolFunc(int value);
-- End mylib.h --
-- Start mycaller.cpp, this is either part of a different static
library, DLL or EXE --
#include "mylibfile.h"
BOOL OtherFunc(int value)
{
return CoolFunc(value); <- this will be unresolved.
}
-- End mycaller.cpp --
The problem is that mycaller.cpp will get compiled as C++ code, and
the function declaration BOOL CoolFunc(int value); will get pulled
into that C++ code as a C++ Function which means it will have all that
wonderful mangling and stuff. The problem is that BOOL CoolFunc(int
value) that is present in mylib.lib is actually a C Function and
doesn't have the mangling that the C++ version should.
So when the compiler looks for CoolFuncABDX$%#X in mylib.lib it cannot
find it (even though CoolFunc is present.)
If this is not the problem, I think you will need to post more
information such as the offending functions, along with the the use,
and declarations of them.
Regards,
Brad.
On Jan 5, 12:17 am, Gurusamy <Gurus...@discussions.microsoft.com>
wrote: