On 2011-08-14, at 11:08 AM, Philip G Batchelor wrote:
Yes, you're right. I replaced OSByteOrder.h by NSByteOrder.h:
compilation did indeed go further, although with the message
'Papyrus3/PapyPrivFunctionDef3.h:122:3: warning: implicit
declaration of function ‘OSSwapLittleToHostInt64’
gcc: apps: linker input file unused because linking not done'
which suggests potential trouble.
Apple's NSByteOrder.h lacks functions for working with c99 types like int64_t. You can replace OSSwapLittleToHostInt64 with the GNUstep function GSSwapLittleI64ToHost which we declare in NSByteOrder.h. Other byte order functions should be similarly easy to substitute.
In the long run you might want to introduce a header like this:
#define OSSwapLittleToHostInt64 GSSwapLittleI64ToHost
… other swap functions ….
But in any case, another attempt at 'make' went further but brought
another problem: it tries to find
'Accelerate.h' which is OSX specific, and contains stuff about
hardware acceleration (seems to be vectorisation and BLAS etc
related). I tried to avoid the problem by commenting some stuff out,
but this causes error as the type 'vFloat' is undefined, so I guess
if there is a workaround, it will require defining a type 'vFloat'
in a linux specific way. Along the lines of
I'll try having a closer look when I have time--I need to read
(I guess these are the library issues mentioned by Fred Kiefer?)
For this kind of thing, you may want to ask the Osirix community. Hopefully they have fallback portable code, and not a hard dependency on this vector library.
One more suggestion, I've found using a version control website like github can be really handy for porting open source apps, since it helps you keep track of what changes you needed to make, and lets others easily check out your progress.
Thanks again for the suggestions
On 14/08/11 13:52, Ivan Vučica wrote:
Copypasting a header from a wrong OS can only mean
problems. I recommend you don't do that.
Best route would be trying to use just libraries natively
available on your target platform (such as Linux). In any case,
it would be best if you convinced upstream authors to maintain a
GNUstep build officially, either by contributing patches they
would accept or by convincing them GNUstep is a good target.
On Sun, Aug 14, 2011 at 13:19, Philip G
Thanks for the suggestions,
inbetween I had googled a bit, and I was considering two
Option 1: somebody tried and had that problem
so maybe try the suggested solution (although apparently it
led to further problems down the line--and it's a while
Option 2: I found libkern/OSByteOrder.h online, as part of
Chameleon which seems to be abooloader?
I check it out, in case of.
So I'll add the two suggested Options to that of:
Option 3: trying to replace with NSByteOrder
Option 4: asking OsiriX developers, and indeed the problem
is now more of an OsiriX one.
I guess I'll try them all, maybe starting with 2 (although
typing 'make' just nearly froze my PC...) as it shouldn't
require changing the actual code. (But NSByteOrder sounds
better in long term).
On 14/08/11 11:44, David Chisnall wrote:
On 14 Aug 2011, at 11:05, Philip G Batchelor wrote:
(For the moment, Osirix compilation fails at
'libkern/OSByteOrder.h: No such file or directory'
but that was a first attempt,
The OSByteOrder stuff is more or less the same as the
NSByteOrder stuff, so it should be relatively simple
to rewrite it to use NSByteOrder. No idea why they'd
use the libkern interfaces - they're only meant to be
used for low-level things that can't link against
I'll try more).
-- Sent from my Difference Engine
Discuss-gnustep mailing list
Ivan Vučica - address@hidden
Discuss-gnustep mailing list