Hi Eric and others
thanks again for the diverse suggestions, been busy with few other
things but I finally managed to try it.
I did as suggested below, i.e. #if defined(GNUSTEP) with a few #defines
which for the moment use standard float and int instead of vFloat and
UInt8 (and a few other details, I indeed need to use something to keep
track of changes). The compilation went through, which is good, until a
long list of linking messages such as
'linker input file unused because linking not done' so somehow something
went wrong in the pbxbuild generated Makefiles I guess...
It's not just a redundant flag, as it then hits an error:
No rule to make target `obj/OsiriX.obj/Binaries/openjpeg/bio.c.o'
I'm trying to look at the Makefiles for linking info, but they're ratehr
long. I notice lots of
ADDITIONAL_NATIVE_LIBS+= AppKit
[...other libs...]
so, am stuck again.
By the way, I get the warning:
''/usr/local/share/GNUstep/Makefiles/Instance/Shared/strings.make:69:
target `Preference.lproj' given more than once in the same rule.''
Ph
Hi Philip,
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:
ByteOrder.h
#if defined(GNUSTEP)
#import <Foundation/NSByteOrder.h>
#define OSSwapLittleToHostInt64 GSSwapLittleI64ToHost
… other swap functions ….
#else
#include <OSByteOrder.h>
#endif
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
http://lists.apple.com/archives/perfoptimization-dev/2009/Mar/msg00006.html
I'll try having a closer look when I have time--I need to read about
VFP.
(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.
Cheers,
Eric
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
