[9fans] incompatible type signature

[9fans] incompatible type signature

[lucio]

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).

So, what do those in the know suggest?

++L

Re: [9fans] incompatible type signature

[erik quanstrom]

> 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

Re: [9fans] incompatible type signature

[erik quanstrom]

it appears that there are mistakes in ntohl and ntohs.
for obvious reasons int is valid for both "unsigned long" and
"unsigned short" due to the usual conversions (and the local,
temporary conventions on amd64), but remember, type
signatures are based on C types, and may differ from the
implementation.

- erik

; 9diff ntohl.c
/n/sources/plan9/sys/src/ape/lib/bsd/ntohl.c:1,5 - ntohl.c:1,5
  unsigned long
- ntohl(int x)
+ ntohl(unsigned long x)
  {
  	unsigned long n;
  	unsigned char *p;
/n/sources/plan9/sys/src/ape/lib/bsd/ntohl.c:24,30 - ntohl.c:24,30
  }

  unsigned short
- ntohs(int x)
+ ntohs(unsigned short x)
  {
  	unsigned short n;
  	unsigned char *p;

Re: [9fans] incompatible type signature

[lucio]

> it appears that there are mistakes in ntohl and ntohs.
> for obvious reasons int is valid for both "unsigned long" and
> "unsigned short" due to the usual conversions (and the local,
> temporary conventions on amd64), but remember, type
> signatures are based on C types, and may differ from the
> implementation.

I presumed I missed the obvious errors because I didn't know what to
look for.  I'll see if I can internalise this for future use.  With
the CVS sources, turning on "T" creates an avalanche of errors.  I
suspect the same goes for OpenLDAP.

++L

Re: [9fans] incompatible type signature

[erik quanstrom]

> I presumed I missed the obvious errors because I didn't know what to
> look for.  I'll see if I can internalise this for future use.  With
> the CVS sources, turning on "T" creates an avalanche of errors.  I
> suspect the same goes for OpenLDAP.

it's surprising how many large projects rely on vigilance rather than
typechecking.

personally, if i have to cunningly outwit a c compiler, i'd rather it be something
the compiler can't actually do itself.

fwiw, cpython didn't have these problems, though it did expect more
up-to-date posix compliance.

speaking of which....

if anyone has an itch to contribute, and doesn't mind getting dirty,
it sure would be nice to bring APE in line with POSIX.1-2008.
contact me offline if interested.

- erik

Re: [9fans] incompatible type signature

[lucio]

> it appears that there are mistakes in ntohl and ntohs.

The problem with _sock_findrock() is that in

	/sys/src/ape/lib/bsd/connect.c

the

	#include	<sys/stat.h>

is missing.  Took me a while to figure that one out.

I rearranged the #includes to match socket.c, now that the entries are
the same.  I'm not (yet) going to work my way through each module.

++L

Re: [9fans] incompatible type signature

[erik quanstrom]

On Thu Sep 12 02:27:31 EDT 2013, lucio@proxima.alt.za wrote:
> > it appears that there are mistakes in ntohl and ntohs.
>
> The problem with _sock_findrock() is that in
>
> 	/sys/src/ape/lib/bsd/connect.c
>
> the
>
> 	#include	<sys/stat.h>
>
> is missing.  Took me a while to figure that one out.

just for the record, 9atom hasn't had this problem since feb.

- erik

Re: [9fans] incompatible type signature

[lucio]

> 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.

I'll see if I can sync my APE libraries and headers with 9atom's, this
is getting beyond annoying.  Off the cuff, do you have a 9-mountable
link for 9atom, save me searching the archives, please?

++L

Re: [9fans] incompatible type signature

[erik quanstrom]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

attached.  sorry for the violence to the 9fans standard of no attachments.

- erik

[-- Attachment #2: 9fs --]
[-- Type: text/plain, Size: 2401 bytes --]

#!/bin/rc
# 9fs filesystem [mountpoint] - srv & mount filesystem, usually from plan 9

rfork e
nflag=-n
if(~ $1 -a){
	shift
	nflag=()
}

switch($1){
case ''
	echo usage: 9fs service '[mountpoint]' >[1=2]
	exit usage
case kfs
	if(! test -f /srv/kfs)
		disk/kfs
	mount -c /srv/kfs /n/kfs
case dump
	mount /srv/boot /n/dump dump >[2]/dev/null ||
		mount /srv/boot /n/dump main/archive ||
		mount /srv/boot /n/dump dump	# again to print error
case snap
	mount /srv/boot /n/snap main/snapshot
case other
	mount -C /srv/boot /n/other other
case juke					# ye olde file server
	srv -q il!jukefs && mount /srv/il!jukefs /n/juke
case sources
	srv $nflag -q tcp!sources.cs.bell-labs.com sources /n/sources
case sourcesdump
	9fs sources
	mount $nflag /srv/sources /n/sourcesdump main/archive
case sourcessnap
	9fs sources
	mount $nflag /srv/sources /n/sourcessnap main/snapshot
# arbitrary venti archives
case vac:*
	vacfs <{echo $1}
case *.vac
	if (test -e $1)
		score=$1
	if not if (! ~ $1 /* && test -e $home/lib/vac/$1)
		score=$home/lib/vac/$1
	if not if (! ~ $1 /* && test -e /lib/vac/$1)
		score=/lib/vac/$1
	if not {
		echo $0: $1: no such score file >[1=2]
		exit 'no score file'
	}
	vacfs -m /n/`{basename $1 .vac} `{cat $score}
case wiki
	srv -m 'net!plan9.bell-labs.com!wiki' wiki /mnt/wiki
case cwiki
	srv -m 'net!wiki.coraid.com!wiki' wiki /mnt/wiki
case coraid
	import -E ssl minooka.coraid.com / /n/coraid
	bind -q /n/coraid/n/other/quanstro /n/other/quanstro
	# if(! ~ $sysname ladd && ! test -f /net.alt/arp)
	# 	import -p ladd /net.alt /net.alt
	# import -p -E ssl /net.alt/tcp!minooka.coraid.com / /n/coraid
case quanstro
	mount /srv/boot /n/quanstro
case quanstrodump
	mount /srv/boot /n/quanstrodump dump
case leffe
	import -E ssl leffe.cs.bell-labs.com / /n/leffe
case nix
	srv -m sources.lsub.org nix.$user && mount /srv/nix.$user /n/nix &&
		bind /n/nix/nix /n/nix
case nixpatch
	srv -m patches.lsub.org nixpatch.$user && mount /srv/nixpatch.$user /n/nixpatch
case atta
	import -E ssl atom.9atom.org / /n/atta
case atom
	# import -E ssl atom.9atom.org /n/atom /n/atom
	srv $nflag -q tcp!atom.9atom.org atom &&
		mount $nflag /srv/atom /n/atom atom
case atomdump
	# mount $nflag
	9fs atom && mount /srv/atom /n/atomdump atomdump
case *
	switch($#*){
	case 1
		srv -m $1
	case *
		srv -m $1 $1 $2
	}
}

Re: [9fans] incompatible type signature

[Jens Staal]

On Thursday 12 September 2013 01:21:38 erik quanstrom wrote:

>
> 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

On 9atom 1 out of two type signature conflicts got resolved when I tried to
build GNU nano (using FGB's PDcurses, rebuilt on 9atom to avoid that character
width or something might be an issue).

The resolved issue was some sort of internal conflict in libbsd bind. The
remaining issue gives the following linking error (for nano) and is a conflict
between libbsd and libdraw:

??none??: incompatible type signatures 50220469
(/386/lib/ape/libdraw.a(screen)) and 9bbe58(/386/lib/ape/libbsd.a(bind)) for
bind

Re: [9fans] incompatible type signature

[erik quanstrom]

> On 9atom 1 out of two type signature conflicts got resolved when I tried to
> build GNU nano (using FGB's PDcurses, rebuilt on 9atom to avoid that character
> width or something might be an issue).
>
> The resolved issue was some sort of internal conflict in libbsd bind. The
> remaining issue gives the following linking error (for nano) and is a conflict
> between libbsd and libdraw:
>
> ??none??: incompatible type signatures 50220469
> (/386/lib/ape/libdraw.a(screen)) and 9bbe58(/386/lib/ape/libbsd.a(bind)) for
> bind

when did you last sync your source?  i believe this has been fixed:

minooka; nm (/386/lib/ape /n/atom/plan9`{pwd})^/libdraw.a | grep bind

i just applied the patch "9diff" to 9atom which includes adiff (see 9diff(1))
which should make tracking differences easier.

- erik

Re: [9fans] incompatible type signature

[Jens Staal]

On Thu, 12 Sep 2013 11:16:31 -0400
erik quanstrom <quanstro@quanstro.net> wrote:

> > On 9atom 1 out of two type signature conflicts got resolved when I
> > tried to build GNU nano (using FGB's PDcurses, rebuilt on 9atom to
> > avoid that character width or something might be an issue).
> >
> > The resolved issue was some sort of internal conflict in libbsd
> > bind. The remaining issue gives the following linking error (for
> > nano) and is a conflict between libbsd and libdraw:
> >
> > ??none??: incompatible type signatures 50220469
> > (/386/lib/ape/libdraw.a(screen)) and
> > 9bbe58(/386/lib/ape/libbsd.a(bind)) for bind
>
> when did you last sync your source?  i believe this has been fixed:
>
> minooka; nm (/386/lib/ape /n/atom/plan9`{pwd})^/libdraw.a | grep bind
>
> i just applied the patch "9diff" to 9atom which includes adiff (see
> 9diff(1)) which should make tracking differences easier.
>
> - erik
>

This was indeed the issue: I had done a recent pull but not rebuilt the
libraries.

Now nano builds on APE with PDCurses and sort of "works" : can open
text files and fast commands work.
what does not work:
- line change by enter
- saving a file (related to my mkstemp hack?)

... however it was just a test to see whether I could build stuff with
the pdcurses so not critical as such :) Now I can at least try to
figure out what goes wrong with the rest :)

Re: [9fans] incompatible type signature

[Jens Staal]

On Fri, 13 Sep 2013 14:30:37 +0200
Jens Staal <staal1978@gmail.com> wrote:

> Now nano builds on APE with PDCurses and sort of "works" : can open
> text files and fast commands work.
> what does not work:
> - line change by enter
> - saving a file (related to my mkstemp hack?)

scratch that... everything works. Just a very weird behavior that
"enter" = ctrl+M

will upload it to contrib later if anyone is interested

sorry for the noise...