Bug#324025: aqsis: FTBFS on 64 bit arches: error: cast from 'void*' to 'int' loses precision

[Peter Karbaliotis]

Package: aqsis
Version: 1.1.0.20050815-4
Followup-For: Bug #324025

It seems that 'papers over' is the preferred upstream solution for the
time being.

Applying the following changes from 1.2 allowed me to build a working
version on amd64:

http://aqsis.svn.sourceforge.net/viewvc/aqsis?view=rev&revision=870
http://aqsis.svn.sourceforge.net/viewvc/aqsis?view=rev&revision=866

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-p4-preempt
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#324025: [Fwd: Re: Bug#324025: aqsis: FTBFS on 64 bit arches: error: cast from 'void*' to 'int' loses precision]

[Ben Hutchings]

 Forwarded Message 
From: Tristan <[EMAIL PROTECTED]>
To: Ben Hutchings <[EMAIL PROTECTED]>
Subject: Re: Bug#324025: aqsis: FTBFS on 64 bit arches: error: cast from 
'void*' to 'int' loses precision
Date: Mon, 06 Mar 2006 03:39:13 -0800

Hi,

  Someone sent me a link to the post below, I am the author of the code
in question.

  re: Cloning of the IDs, I think this is spec compliant. The spec (the
doc you pointed two) specifies that the init function is called once
per renderer instance (or renderer thread), not once per shader
instance. In order to use per-shader initialization DSO authors will
normally add an additional DSO which lets them init a new invocation of
the DSO. There are a couple of example online of using this technique.
So basically you build a per-shader instance init on top of SL which
might end up looking like...

int callid = init_myshadeop("somestuff","otherstuff");
...
Cs = myshadeop(callid,P,,N,"whatever data");
...
shutdown_myshadeop(callid)

  It might not be pretty, but then there is alot about RiSpec that
isn't pretty.

  I'll see if there is anything we can do about the pointer conversion
issue.

  I noticed that people seemed to be suggesting keeping a patch local
to debian, is this the normal way of doing things? Is there a policy of
pushing bugs and/or patches upstream to the originating project?

  Cheers
  Tristan Colgate

[Quoted text omitted - Ben Hutchings.]


signature.asc
Description: This is a digitally signed message part

Bug#324025: aqsis: FTBFS on 64 bit arches: error: cast from 'void*' to 'int' loses precision

[Ben Hutchings]

Changing the definition of DSOInit is certainly wrong - it is part of
the RenderMan shader interface and should remain binary-compatible with
that.

There's a copy of the DSO interface documentation at
.
  This says that the first parameter to initialisation functions is some kind 
of thread identifier.  I don't see that this can mean an OS thread id, since 
the DSO can find that out itself.  I think it's only necessary that at any 
given time each instance of CqShaderVM has a distinct id to pass to DSO 
initialisation functions.

So the current code looks OK on platforms with 32-bit pointers (instance
addresses being obviously unique), and Andreas's patch would make it
work with 64-bit pointers *almost* all the time.  Assigning 32-bit
serial numbers to CqShaderVM instances might be more reliable, but still
leaves the theoretical possibility of collisions.  Off-hand, I can't
think of a method of assigning such identifiers that's both correct and
efficient, though I'm sure such methods exist.

However - I now notice that CqShaderVM::Clone copies the whole object,
including information about initialised DSOs, which means that there can
be multiple CqShaderVM instances sharing ids.  I really don't know what
Aqsis is playing at.  I think this needs some attention from upstream.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Bug#324025: aqsis: FTBFS on 64 bit arches: error: cast from 'void*' to 'int' loses precision

[Steve Langasek]

tags 324025 -patch
thanks

The patch in this bug is horribly wrong.

diff -urN ../tmp-orig/aqsis-1.1.0.20050815/libshadervm/shadervm.cpp
./libshadervm/shadervm.cpp
--- ../tmp-orig/aqsis-1.1.0.20050815/libshadervm/shadervm.cpp   2005-08-15 
09:04:44.0 +
+++ ./libshadervm/shadervm.cpp  2005-08-21 12:44:02.0 +
@@ -1092,7 +1092,7 @@
 // We have an initialiser we have not run yet
 if((*candidate)->init){
 (*candidate)->initData =
-
((*candidate)->init)((int)((void*)this),NULL);
+
((*candidate)->init)((long)((void*)this),NULL);
 };
 (*candidate)->initialised = true;
 };

The prototype of ((*candidate)->init) is

  typedef void* (*DSOInit)(int,void *);

Casting "this" to a long instead of an int does *not* fix this bug on 64-bit
systems, it just papers over it so that the compiler can't see it -- the
value of "this" will still be truncated to an int when passed to the
function!

Further investigation is needed here to determine a correct fix.  The
obvious one would be to promote the first arg of DSOInit to 'long', but this
isn't necessarily correct either.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#324025: aqsis: FTBFS on 64 bit arches: error: cast from 'void*' to 'int' loses precision

[Kurt Roeckx]

Package: aqsis
Version: 1.1.0.20050815-2
Severity: serious

Hi,

Your package is failing to build on 64 bit arches with the
following error:
g++ -DHAVE_CONFIG_H -I. -I. -I../libaqsistypes -I../libaqsistyp
es -I../libaqsistypes/posix -I../render -I../libshaderexecenv -I/usr/include -g
 -O2 -MT shadervm.lo -MD -MP -MF .deps/shadervm.Tpo -c shadervm.cpp  -fPIC -DPI
C -o .libs/shadervm.o
shadervm.cpp: In member function 'void Aqsis::CqShaderVM::LoadProgram(std::istr
eam*)':
shadervm.cpp:1095: error: cast from 'void*' to 'int' loses precision
make[2]: *** [shadervm.lo] Error 1



Kurt



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]