Re: OT: compile problem--where 2 look 4 cause? (short story, long info)
On Thu, Apr 26, 2001 at 11:54:31PM -0700, Kenward Vaughan wrote:
> I hope someone can give me clues about what's screwing up the compilation of
> a molecular docking app I'm trying to assemble for my classes... It is
> supposed to compile on a number of *nix platforms including Linux, but my
> attempts die at the linking stage.
>
> (...)
>
> Can someone suggest places to look for the cause of this? Is there other
> information I could find to help? I have tried the nm command with the
> three functions referenced below, and the only consistent difference I can
> see is the lack of a bunch of alphanumerics after the name shown on the last
> line of that listing.
this small difference in the symbolnames _could_ be an indication that
there's some kind of prototype mismatch. You might want to use nm's -C
option to demangle those cryptic alphanumerics. This will give you a more
human-readable output, though I'm not sure whether it'll help you beyond
that... (see 'man c++filt' for a short intro on what mangling is about).
I would try to locate the implementation of the 'get_atom_type(char *, char *)'
function in the source code (most probably in get_atom_type.cc) and see
whether it has the required prototype (the one that the linker's "undefined
reference" message complains about).
Somehow, however, I doubt that some bug like this would have made it
into the AutoDock distribution. Or is this a brand new release, that no
one else has yet tried to compile?
Too bad this isn't open source -- otherwise I could have given it a
quick try myself... Anyway, good luck!
Erdmut
> (...)
>
> readPDBQ.o(.text+0x465): undefined reference to `get_atom_type(char *, char
> *)'
> collect2: ld returned 1 exit status
> make: *** [autodock3] Error 1
>
> ---end of run--next is a listing by nm of libad.a for get_atom_type
>
> daddy:/home/local/src/autodock/dist305/src/autodock# nm libad.a|grep -i
> get_atom_type
> U get_atom_type__FPcT0
> U get_atom_type__FPcT0
> U get_atom_type__FPcT0
> get_atom_type.o:
> 00000000 T get_atom_type
--
Erdmut Pfeifer
science+computing ag
-- Bugs come in through open windows. Keep Windows shut! --
Reply to: