discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OsiriX [Was: environment]


From: Philip G Batchelor
Subject: Re: OsiriX [Was: environment]
Date: Fri, 19 Aug 2011 18:45:43 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]