> 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

Reply via email to