Re: OsiriX [Was: environment]

[Philip G Batchelor]

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