#819 i386-apple-darwin9.8.0 does not compile.

[Martin Krischik]

Hello,

sadly the compile on Mac OS X fails with the following error:

Command output: /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I/opt/local/include -DORX_VER=4 -DORX_REL=0 -DORX_MOD=0 -DORX_FIX=0 -DORX_SYS_STR=\"MACOSX\" -DORX_CATDIR=\"/opt/local/bin\" -DORX_SHARED_LIBRARY_EXT=\".dylib\" -I./lib -I./api -I./api/platform/unix -O2 -arch i386 -O2 -arch i386 -DNOOPT -DPTHREAD_KERNEL -D_POSIX_THREAD -D_REENTRANT -D_GNU_SOURCE -DLINUX -DOPSYS_LINUX -MT rexximage-rexximage.o -MD -MP -MF .deps/rexximage-rexximage.Tpo -c -o rexximage-rexximage.o test -f './utilities/rexximage/rexximage.cpp' || echo './'./utilities/rexximage/rexximage.cpp
./lib/RexxInternalApis.h:49: error: expected initializer before 'RexxResolveExit'
./lib/RexxInternalApis.h:50: error: expected initializer before 'RexxResolveRoutine'
./lib/RexxInternalApis.h:52: error: 'RexxReturnCode' does not name a type
./lib/RexxInternalApis.h:53: error: expected initializer before 'RexxCreateInterpreterImage'
./lib/RexxInternalApis.h:55: error: 'RexxReturnCode' does not name a type
./lib/RexxInternalApis.h:56: error: 'RexxReturnCode' does not name a type
./lib/RexxInternalApis.h:57: error: 'RexxReturnCode' does not name a type
./lib/RexxInternalApis.h:58: error: 'RexxReturnCode' does not name a type
./utilities/rexximage/rexximage.cpp: In function 'int main(int, char)':
./utilities/rexximage/rexximage.cpp:44: error: 'RexxCreateInterpreterImage' was not declared in this scope
make: * [rexximage-rexximage.o] Error 1

Any ideas?

Martin

[Martin Krischik]

Same result with SnowLeopard

[Martin Krischik]

Still not even assigned to somebody? Nobody working on it?

[Mark Miesfeld]

Hi Martin,

I knew from personal experience how frustrating it can be to open a bug in an open source project and not get any repsonse. So, I'm just going to respond so that you at least know we see this.

Unfortunately, none of the active participants in the project seem to have the skill set or the desire to do anything about this at this point in time. The active developers don't have access to Apple hardware and don't have any experience on the platform.

We would of course welcome any patches to fix this.

[Anonymous]

my two cents...
on jan 18 I downloaded the then current svn and I succeeded in building under snow leopard all 64bits mode

I had to change all the .....64 calls to normal calls
open64 to open
lseek64 to lseek
fstat64cto fstat

for consistency I changed also the declation of stat64 to stat

apart that everything seems top work

regards
e.s

[Martin Krischik]

Download from svn - yes macports could do that. And patch file which replace the 64 calls should not be to difficult either. I might give it a go. You remember which version you downloaded?

Apart from that: maybe one of us should apply to joint the team to get things fixed at the root ;-) .

[Mark Miesfeld]

"Download from svn - yes macports could do that. And patch file which
replace the 64 calls should not be to difficult either. I might give it a
go. You remember which version you downloaded?"

You should just check out from trunk, whatever revision it is. Patches would need to be against the latest revision anyway. <grin></grin>

"Apart from that: maybe one of us should apply to joint the team to get
things fixed at the root ;-) ."

Submit some patches that work, contribute some to the discussion(s) on the developer list, we'd love to add a committer with both access to and knowledge of Apple hardware.

[Anonymous]

to be sure I just pulled svn version 5514 half an hour ago

I changed the ....64 stuff to the unsuffixed one ( fstat,open,fseek,stat)

and everything went smoothly afterwards

./bootstrap
./configure
make
make install

I appreciate that oorexx installs to /opt/oorexx !

let me know if I can help for the mac platform

I am currently running on
mac boom pro
SNOW LEOPARD with the 64bits kernel booted by default

I have another mac,
I will check if a simple tar gzipped/bzipped archive will be enough to install
on a barebones machine, it could be the quick and dirty solution,
with a small script, if needed, to create the links from and usr/lib

regards
enrico

[Anonymous]

I forgot ( for clarity ) to post the name of the files I had to change here they are

common/platform/unix/SysFile.cpp
extensions/rexxutil/platform/unix/rexxutil.cpp

I was going to post also a diff result, from the 18th jan pull
for sysfile.cpp the 64 stuff was the only change
but for rexxuti.cpp there were also other changes involved

since the changes are simple no need for the diff
for sysfile You must watch out for an int64_t so You must change for each occurrence
for rexxutil it was enough to change the 64 to a null string

regards
enrico

[Mark Miesfeld]

We, meaning the ooRexx developers, believe that the upcoming bug release builds okay on a current version of OS X.

[Mark Miesfeld]

The fix for this item was in the 4.1.1 or 4.1.0 release.