Of course I'll change it if you want.
I picked Darwin (actually darwin) because that is the name that the
operating system identifies itself with. The output of uname -a is:
Darwin BookWormMac.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE
On Thu, Apr 1, 2010 at 4:05 PM, Rick McGuire wrote:
> On Thu, Apr 1, 2010 at 7:00 PM, CVBruce wrote:
>>
>> I'm also working on building the install package from the command line
>> so that build a new package from a make file. So far I've put the
>> scripts that are required and other bits and p
On Thu, Apr 1, 2010 at 7:00 PM, CVBruce wrote:
> Ok, that sounds good to me.
>
> I can see in the makefile.in where it tests to see if it is making an
> AIX system, and if not it copies rxapid into /opt/ooRexx/bin. I would
> also like rxapid NOT to be copied if we are making an OSX system, and
>
Ok, that sounds good to me.
I can see in the makefile.in where it tests to see if it is making an
AIX system, and if not it copies rxapid into /opt/ooRexx/bin. I would
also like rxapid NOT to be copied if we are making an OSX system, and
instead copy the plist.
Is makefile.in the correct p
On Thu, Apr 1, 2010 at 11:45 AM, CVBruce wrote:
> I need more advice now.
>
> After I run make install, all of the necessary files are moved to
> /opt/ooRexx
> /opt/ooRexx/bin
...
> I then run a post installation script that symlinks these files into
> the "correct" Mac OS directories,
> /usr/bin
Mark,
This worked. My MACOSX didn't work, perhaps it didn't evaluate as
true or false?
I need more advice now.
After I run make install, all of the necessary files are moved to
/opt/ooRexx
/opt/ooRexx/bin
/opt/ooRexx/include
/opt/ooRexx/lib
/opt/ooRexx/lib/ooRexx
/opt/ooRexx/share
/opt/ooRexx
It seems that in the generic case, that testing to determine the size
of off_t is the key. If off_t is 4 and one wants to support large
filesystems, then the 64 variants of the file functions are
needed. If on the other hand off_t is 8 then they are not needed.
I chose MACOSX, because
On Thu, Apr 1, 2010 at 10:42 AM, Rick McGuire wrote:
> I don't have a problem with adding those defines as long as they going
> in a platform-specific file. SysFile.hpp seems like a likely place to
> put this.
Okay, so there you go Bruce. Try adding the defines to the
common/platform/unix/SysF
I don't have a problem with adding those defines as long as they going
in a platform-specific file. SysFile.hpp seems like a likely place to
put this.
Rick
On Thu, Apr 1, 2010 at 1:40 PM, Mark Miesfeld wrote:
> On Thu, Apr 1, 2010 at 9:53 AM, CVBruce wrote:
>
>> Also, open64() is not supported
On Thu, Apr 1, 2010 at 9:53 AM, CVBruce wrote:
> Also, open64() is not supported because open() supports 64 bit
> operating systems.
>
> My quick and dirty #define lseek64 lseek didn't work. It looks like I
> have some more work to do.
This looks like it works for other people:
#ifdef __APPLE_
Also, open64() is not supported because open() supports 64 bit
operating systems.
My quick and dirty #define lseek64 lseek didn't work. It looks like I
have some more work to do.
Bruce
--
Download Intel® Parallel S
11 matches
Mail list logo
