From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,7ef560cb7b30bfe1 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,7ef560cb7b30bfe1 X-Google-Attributes: gid103376,public From: Keith Thompson Subject: Re: Bizarre link errors Date: 1999/04/27 Message-ID: #1/1 X-Deja-AN: 471755722 References: <7g27hl$93f$1@whatsit.aston.ac.uk> X-Complaints-To: usenet@nusku.cts.com X-Trace: nusku.cts.com 925275689 6768 198.68.168.21 (28 Apr 1999 05:01:29 GMT) Organization: CTS Network Services NNTP-Posting-Date: 28 Apr 1999 05:01:29 GMT Newsgroups: comp.lang.c++,comp.lang.ada Date: 1999-04-28T05:01:29+00:00 List-Id: "Daniel Clarke" writes: > I'm working on a project involving C and Ada, ada executables importing > functions from C libraries. When we try to build the executable we're > getting a series of bizarre link errors ( included below ). The unresolved > externals are mostly coming from one file which does have a lot of casting > going on which may explain the references to rtti in the linker output. > Beyond that the errors mean nothing to me. I think the problem is arising > from the ada linker not linking in some core C++ library but how to solve it > is another matter. I've tried removing sections of code but the symbol > references occur all over the place. > > Platform is SunOs 5.6 on a sparc ultra Interesting. I just ran into a linking problem yesterday that involved some of the same symbols, though I wasn't using Ada, so it may not be exactly the same problem. I was trying to build a large C++ software package using g++ version 2.8.1, and g++ died with an internal error while compiling one of the source files. I ran switched to version 2.7.2.2 and ran "make" again. I got a linker error very similar to the one you ran into. The problem was that I was trying to link together object files created by two different versions of g++. Apparently some of the symbols changed. When I deleted the objects ("make clean") and ran "make" again, it was ok. Your problem may be a bit different, but I suspect it's also a problem with two different versions of gcc. The current release of GNAT is based on a specific version of gcc (I don't remember which one). I suspect you're using a different version of gcc, probably a newer one, to compile your C++ code. (I presume you're using g++ and not Sun's CC.) Ideally, you should use the same version of gcc for both your Ada and your C++ sources. Unfortunately, the GNAT binary distribution includes the C front end, but not the C++ front end -- and later versions of g++ are significantly closer to complying with the C++ standard. Whatever version of g++ you're using to compile the C++ code, you might try invoking it on a C++ main program with the "-v" option. This will tell you what arguments it's passing to the linker. Manually invoking GNAT's linker with the same arguments *might* solve your problem -- or it might silently mask a more serious one. You might also consider writing your main program in C++ instead of Ada, and linking with g++ rather than with GNAT's gcc (adding calls to adainit and adafinal as appropriate). Unlike Ada, C++ doesn't provide a good way to allow calls from a main program in a foreign language while guaranteeing proper initialization. (Some Unix linkers handle this; others don't.) If this doesn't help, the chat@gnat.com mailing list might be more helpful than comp.lang.ada. Be sure to specify what version of GNAT and of g++ you're using. Finally, check the GNAT documentation (which I don't have handy) for information about mixing Ada and C++. -- Keith Thompson (The_Other_Keith) kst@cts.com San Diego Supercomputer Center <*> Techno-geek. Mouse bigger than phone. Bites heads off virtual chickens.