> I'm going to start from the man page: 8c(1)
>
> -T Pass type signatures on all external and global enti-
> ties. The signature is based on the C signof opera-
> tor. See dynld(2).
>
> There is no dynld(2), I do wish the reference could be to some useful
> documentation!
>
> I tried to compile the most recent version of CVS I could find
> (1.11.23), something I did successfully a long time ago, and before
> that the OpenLDAP clients/tools sources and both compilations
> concluded with link time errors on the APE libraries (the culprits
> seem to be _sock_findrock, ntohl and ntohs).
>
> What I'm looking for is an explanation of these "incompatible type
> signature" errors that can be usefully employed to track them down and
> fix them. Rebuilding and re-installing the entirety of the
> /sys/src/ape directory didn't make any diference (the sugnatures may
> be different, I'm not sure).
i would rewrite -T informally like the following:
-T Pass type signatures on entities to the linker. When type
signatures are set, the linkers will not link symbols
with mismatched signatures. The signature is based on
the C signof operator, rather than the machine implementation.
Thus "ulong" and "u32int" are not type-compatable,
even though on 32-bit machines, the machine code
would be.
that is, if you seperately compile type files to create .$Os and the compiler
thinks the signature for some symbol is X in the first, and Y in the second,
then the linker will not link it. this is usually caused by header files that
are
inconsistent. a culprit in the unix world are functions that gain extra
arguments
whenever certain #defines are defined.
i believe all the type signature problems in 9atom's ape have been sorted out.
if you find something that does not work, it will be fixed.
- erik