Re: Cross-compile problem (continued)

[gero@gkminix.han.de (Gero Kuhlmann)]

Hello,

Ross Golder <rossg@cpd.co.uk> wrote:
> Does anyone know why it's attempting to link in the inet_ntoa with two
> leading underscores.

Very likely because either you linked in a library routine which uses
__inet_ntoa, or a header file told the compiler to append two dashes at
the beginning of the name inet_ntoa. Both cases can result from a mis-
compiled library, or a left over header file from an older library version.

> I seem to remember something about using two
> leading underscores on assembler subroutines that are to be called from
> C programs, from when I used to do DOS development.

When using an a.out compiler under Unix or any DOS C compiler I know of,
the compiler itself appends _one_ underscore at the beginning of any public
name. Since assemblers don't do this, you have to append this one under-
score in assembler modules. Appending _two_ underscores in assembler modules
is IMHO just a convention, which is not necessary. If the name is __inet_ntoa
in the assembler module, the C compiler can access it as _inet_ntoa, e.g.
with one leading underscore. However, this only applies to a.out under UNIX
and most DOS compilers. The ELF format does NOT use leading underscores.
Therefore, if you define inet_ntoa in a module compiled with an ELF compiler,
it will appear exactly like this in the resulting object file. Again, even
with ELF it's still common practice to use two leading underscores in assem-
bler routines in a library.

> Is the actual problem to do with the linker not actually finding/using
> 'libc' for some reason? How would you find out?

If it's not linking in libc, this inet_ntoa would not be the only missing
external, but the linker would produce a whole bunch of other error
messages as well.

gero.

--
I'll say it again for the logic impaired.
  - Larry Wall <lwall@jpl-devvax.jpl.nasa.gov>
--
Gero Kuhlmann, Hannover     0511/6497525 (Voice)        gero@gkminix.han.de