[omniORB] Linking problems in MSVC++ 5.0
Dee Jay Randall
randal@cs.uregina.ca
Mon, 9 Nov 1998 09:45:07 -0600 (CST)
I did manage to build the echo example, and it worked fine.
Yes, in eg1.obj, the external symbol name of CORBA::string_free
is ?string_free@CORBA@@YAXPAD@Z
Here is what I get when I do a dumpbin on eg1.obj and server.obj
(server.obj is my file that is causing the trouble):
eg1.obj:
024 00000000 UNDEF notype () External | ?string_free@CORBA@@YAXPAD@Z
(void __cdecl CORBA::string_free(char *))
server.obj:
051 00000000 UNDEF notype () External | ?string_free@CORBA@@SAXPAD@Z
(public: static void __cdecl CORBA::string_free(char *))
The "public: static" part is obviously the problem (right?), but how
do I get rid of it?
My compiler command line options (copied from Project-Settings):
/nologo /MD /W3 /GX /O2 /D "NDEBUG" /D "ODBCVERSION" /D "WIN32"
/D "_CONSOLE" /D "_MBCS" /D "_MSC_VER" /D "__WIN32__" /D "__x86__"
/D "__NT__" /D __OSVERSION__=4 /Fp"dbd50__2/dbd50.pch" /YX
/Fo"dbd50__2/" /Fd"dbd50__2/" /FD /c
From what I can tell these do not differ in a way that would account for
my problems. MD and GX are there. W3 == warning level 3, O2 == optimize,
some extra defines, /Fx"" options to set directories, /YX to do precompiled
headers (should I turn this off?), /c == don't link yet.
I don't know what the /FD is for. It does not appear in the help, and
removing it didn't change any of the link errors.
Finally, the correct libraries are specified, and the include and
library directories are also specified appropriately.
As for the string.h problem. I don't think it exists. The problem
would be the conflicts that appear when you try to use stl header
files and the wrong string.h/string file. One works, one chokes out
lots of errors. But, I don't think it is a problem with omniORB (it is
a problem with Inprise/Visibroker though, which is why I'm trying
omniORB).
I really appreciate your efforts to aid me.
Dee Jay Randall _-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_
randal@cs.uregina.ca | "While reality is neither black and white nor |
{ } right and wrong, those are the only ideals { }
_-__-_ ouch, { } against which we can evaluate our decisions." { }
> < that hurt | -me |
_) chomp (___________ ~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~-_-~
On 9 Nov 1998, Sai-Lai Lo wrote:
> I want to understand why you are getting these unresolved external symbol.
>
> 1. Did you manage to build the echo example (src/examples/echo) using
> nmake?
>
> Try in the directory
> nmake /f dir.mk
>
> If all goes well, you will get all the binaries compiled.
> If you do a DUMPBIN.EXE /SYMBOLS eg1.o, you will see that the external
> symbol name of CORBA::string_free is ?string_free@CORBA@YAXPAD@Z.
>
> 2. If you succeed with step 1, have a look at the dir.mak file and compare
> the compiler flags and libraries used in the file.
> The most relevant part is:
>
> CORBA_CPPFLAGS = -D__WIN32__ -D__x86__ -D__NT__ -D__OSVERSION__=4
> CORBA_LIB = omniORB260_rt.lib omnithread2_rt.lib wsock32.lib \
> advapi32.lib \
> -libpath:$(TOP)\lib\x86_win32
> CXXFLAGS = -O2 -MD -GX $(CORBA_CPPFLAGS) $(DIR_CPPFLAGS)
>
> Notice the -MD and -GX flag.
>
> 3. In the same dir.mak file, there is an equilvalent set of the above to
> build debug executables. Have a look and use that as a guide.
>
> 4. I do not know the use of string.h is a problem. James, could you tell me
> more about this?
>
>
> If you still have problems, do drop me a line. I think the instructions in
> README.win32 file may be unclear. Please drop me a few lines as to how the
> instructions can be improved.
>
>
> Regards,
>
> Sai-Lai
>
>
> >>>>> Dee Jay Randall writes:
>
> > With Dominic's comments, I got my libc* problem solved. He was
> > right on.
>
> > Would you recommend I compile multithreaded with static omni libs?
> > I think I will need to do that anyway, in case we want to run the
> > executable elsewhere, it would simplify installation requirements.
>
> > omni uses <string.h>, so I need to use the 'old' versions. Does this
> > mean I won't be able to use the STL stuff? That would be bad, since
> > the whole application that I'm trying to corba-ize is built on stuff
> > in the STL. The link errors do not seem to be related to stl stuff.
>
> > My first three errors are now:
> >>
> >> Linking...
> >> server.obj : error LNK2001: unresolved external symbol "public: static void __cdecl CORBA::string_free(char *)" (?string_free@CORBA@@SAXPAD@Z)
> >> dmvi.obj : error LNK2001: unresolved external symbol "public: static void __cdecl CORBA::string_free(char *)" (?string_free@CORBA@@SAXPAD@Z)
> >> dmvi.obj : error LNK2001: unresolved external symbol "void __cdecl _CORBA_null_string_ptr(unsigned char)" (?_CORBA_null_string_ptr@@YAXE@Z)
> >>
>
> > grepping the runtime debug omni libraries for the functions
> > gives me this:
> >> C:\omniORB_2.6.1\lib\x86_win32>find "string_free" *rtd.lib
> >> ---------- OMNILC22_RTD.LIB
> >> ---------- OMNIORB260_RTD.LIB
> >> ?string_free@CORBA@@YAXPAD@Z
> >> __imp_?string_free@CORBA@@YAXPAD@Z
> >> ?string_free@CORBA@@YAXPAD@Z
> >> __imp_?string_free@CORBA@@YAXPAD@Z
> >> ?string_free@CORBA@@YAXPAD@Z
> >> __imp_?string_free@CORBA@@YAXPAD@Z
> >> ---------- OMNITHREAD2_RTD.LIB
> >> C:\omniORB_2.6.1\lib\x86_win32>find "null_string_ptr" *rtd.lib
> >> ---------- OMNILC22_RTD.LIB
> >> ---------- OMNIORB260_RTD.LIB
> >> ?_CORBA_null_string_ptr@@YAX_N@Z
> >> __imp_?_CORBA_null_string_ptr@@YAX_N@Z
> >> ?_CORBA_null_string_ptr@@YAX_N@Z
> >> __imp_?_CORBA_null_string_ptr@@YAX_N@Z
> >> _??_CORBA_null_string_ptr@@YAX_N@Z
> >> __imp_?_CORBA_null_string_ptr@@YAX_N@Z
> >> ---------- OMNITHREAD2_RTD.LIB
> >> C:\omniORB_2.6.1\lib\x86_win32>
> >>
>
> > So the functions are in there, but their symbols are not
> > matched... ie: for string_free (omnilib) the mangled symbol is
> > this "?string_free@CORBA@@YAXPAD@Z", but VC is looking for
> > "?string_free@CORBA@@SAXPAD@Z". Likewise with CORBA_null_string_ptr.
> > What on earth does this mean? And how do I fix it...
>
> --
> Dr. Sai-Lai Lo | Research Scientist
> |
> E-mail: S.Lo@orl.co.uk | Olivetti & Oracle Research Lab
> | 24a Trumpington Street
> Tel: +44 223 343000 | Cambridge CB2 1QA
> Fax: +44 223 313542 | ENGLAND
>