From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] incompatible type signature
Date: Thu, 12 Sep 2013 01:21:38 -0400 [thread overview]
Message-ID: <94594e360af74d88545fc8c2358c4c44@brasstown.quanstro.net> (raw)
In-Reply-To: <56b14cb05fe9efa2d1c1ee474b6434c7@proxima.alt.za>
> 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
next prev parent reply other threads:[~2013-09-12 5:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 5:11 lucio
2013-09-12 5:21 ` erik quanstrom [this message]
2013-09-12 5:30 ` erik quanstrom
2013-09-12 5:39 ` lucio
2013-09-12 5:49 ` erik quanstrom
2013-09-12 6:27 ` lucio
2013-09-12 13:47 ` erik quanstrom
2013-09-12 5:36 ` lucio
2013-09-12 5:37 ` erik quanstrom
2013-09-12 7:42 ` Jens Staal
2013-09-12 15:16 ` erik quanstrom
2013-09-13 12:30 ` Jens Staal
2013-09-13 13:02 ` Jens Staal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94594e360af74d88545fc8c2358c4c44@brasstown.quanstro.net \
--to=quanstro@quanstro.net \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).