Re: [Aqsis-development] shared vs static libraries; building on amd64 - bug 1456902
Brought to you by:
ltatkinson,
pgregory
From: Chris F. <fo...@ph...> - 2006-05-23 03:33:06
|
On Tue, May 23, 2006 at 01:00:21PM +1000, Chris Foster wrote: > On Sun, May 21, 2006 at 11:22:50AM +0200, Anteru wrote: > > Hi, > > > > I've also tried to get Aqsis running under AMD64 and I had similar issues. To make > > it link, I added the -fPIC option which does the job but there are still some more > > serious issues. > > > > The ri2rib output library is writing out handles which are actually pointers. This > > is fine on 32bit architectures, but it's wrong on 64bit. According to the spec, the > > type should be RtPointer which is a typedef for void*. However, at the moment, > > they're written out using the PI macro (print integer). The obvious solution would > > be to introduce a PP (print pointer) macro for this cases - but what happens if I > > output a RIB on a 64bit machine and try to load it on a 32bit machine? As I don't > > know a solution for this, I'm truncating currently to 32bit in my local build. Any > > suggestions how to handle this properly are welcome! > > Hmm, yes this would be decidedly non-portable. Isn't the real issue > that each object handles output in a RIB stream be unique (rather than > being valid pointers or anything on the originating machine)? In that > case, we could simply write code to map unique pointers to unique 32-bit > ints. Each pointer-integer pair written out to the RIB could be stored > in a std::map and future pointers checked against it. What do people > think? Hmm, thinking about this again, this proposal sounds rather inefficient if there are large numbers of object handles being used... I hate to suggest it, but perhaps some judicious #ifdefs and a ARCH_X86_64 preprocessor symbol would be in order. Then only the 64-bit version would have the mapping inefficiencies. ~Chris. |