[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 10 22:53:37 2003 
Subject:Re: Using 'varargs' vs 'stdargs' (also links to libXt.so etc.) 
From:A . Sloman 
Volume-ID:1031110.05 

Roger Evans wrote
>
> I don't know anything about 'stdargs' either, but a key quesiton is
> whether it is just a change to the syntax of  varargs handling or the
> way it is actually achieved (which I think for varargs was by passing a
> count of the number of args followed by the args themselves on the
> callstack, but I may be wrong - anyway it doesn't really matter, what
> matters is, has it changed?).

The main change, apart from specifying different .h files, seems to be
in $usepop/pop/x/Xpw/CallMethod.c

which now has
    XpwMethodRet XpwCallMethod(XpwCoreWidget gw, XpwMethodID method_id, ...)
    {
	    XpwCoreWidget w=(XpwCoreWidget)gw;
	    XpwCoreWidgetClass class =(XpwCoreWidgetClass)XtClass(w);
	    register XpwMethod *method;
	    register XpwAssocTable *methods_table;
	    XpwApplyProc apply_proc;
		etc....

replacing the old version:

    XpwMethodRet XpwCallMethod(gw, method_id, va_alist)
    XpwCoreWidget gw;
    XpwMethodID method_id;
    va_dcl
    {
	    XpwCoreWidget w=(XpwCoreWidget)gw;
	    XpwCoreWidgetClass class =(XpwCoreWidgetClass)XtClass(w);
	    register XpwMethod *method;
	    register XpwAssocTable *methods_table;
	    XpwApplyProc apply_proc;
		etc....


Then later on

	while (class != (XpwCoreWidgetClass)widgetClass) {
		/* for each class structure */
                va_start(ap, method_id);

replacing

	while (class != (XpwCoreWidgetClass)widgetClass) {
		/* for each class structure */
		va_start(ap);

All this looks like a minor syntactic change. If all method invocations
go through stuff defined here, then presumably everything will work.

> This is important because some native pop
> code in the Xt interface invokes external C procedures using the varargs
> protocol, but possibly not via an actual C wrapper, so it wouldn't have
> been caught by a global change to C files. If anyone thinks there's an
> issue here, I could try and rediscover whether/where it happens in more
> detail.

Having rebuilt the system using stdargs I've run quite a lot of tests of
X facilities (including XVed and rclib extensions, and some bits of
TEACH propsheet, and it all seems to work). I've used grep to search
for things that might use varargs. but without success.

> PS: Aaron, re your question about users of  x86 solaris. I do actually
> have an x86 solaris machine sitting in my office, and a while ago had
> the intention of trying to rebuild the x86 system (because I think in
> one of the system notices you comment that it would be nice i someone
> could do so). *BUT* this system has been switched off
>  for a good few months now, and is unlikely to ever be switched on again
> - we'd probably rebuild the system as linux instead.

Sounds reasonable. I have no reason to believe that Sun expect solaris
on PC to go anywhere.

The latest easy-install linux-poplog package is, and will remain for
some time:
	http://www.cs.bham.ac.uk/research/poplog/bham-linux-poplog.tar.gz

with 'easy' installation instructions here:
	http://www.cs.bham.ac.uk/research/poplog/linux-cd/SHORT-CUT-INSTALLATION.txt

I have now tried it on several configurations and it works on all of
them except our linux-cluster where the slave nodes for some reason
do not have
    /usr/X11R6/lib/libXt.so
    /usr/X11R6/lib/libXext.so
    /usr/X11R6/lib/libX11.so

which, on all our other machines are symbolic links to
    /usr/X11R6/lib/libXt.so.6
    /usr/X11R6/lib/libXext.so.6
    /usr/X11R6/lib/libX11.so.6
respectively.

I presume I could deal with this in the same way as I now deal with
motif, namely by installing the missing libraries in

	$usepop/pop/extern/lib

as symbolic links to the versions in /usr/X11R6/lib.

I'd have to make further changes to the file in $popsrc/syscomp
that generates the $popsys/poplink_cmnd file, so as to get things
inserted in a different order.

It depends on whether the missing links are missing by accident on our
cluster, or whether there's a recent change in the way XFree86 is
configured.

Aaron