On Monday, May 6, 2002, at 10:44 AM, Marcus H. Mendenhall wrote:
Since many people have asked for my MacOSX openDX binaries, I just
took the ones I am currently using, rolled a tarball, and posted
them. They work for me, which is all I can say for them. I have
run all the nets that I had previously used under LinuxPPC and
Linux Mandrake PPC, and they all seem to work.
The binary is on my Macintosh. Connect to
afp://mendenhall.fel.vanderbilt.edu as guest, look in directory marcus
for the tarball opendx.4.1.3.20020506.macosx.tar.gz.
It works well for me (at least so far). Can you explain how, or if,
the source was patched, what flags were passed to configure, and
what versions of the apple development tools were used?
Jeremy Erwin
Approximately... (there are some messy steps which I am not _sure_ I
can document easily)
make sure you have at least the December 2001 Dev Tools
make sure you have fink with all the autoconf/automake/flex/bison and
many more (you will have to just look at what fails to see what to
add... I didn't keep record, unfortunately)
Make sure you have lesstif _including the header files_. I don't
think the fink lesstif package includes them. I rebuilts lesstif
from the lesstif.org master tree (it's very easy), with --prefix=/sw
and let it install itself.
from the stock tarball snapshots, extract a full tree onto a UFS
formatted disk (I suspect everything will melt on an HFS partition
because of case-sensitive file-name collisions, but I haven't tried
it).
setenv CPP "cc -E -traditional-cpp -I/sw/include"
setenv CFLAGS "-traditional-cpp"
setenv CXXFLAGS "-traditional-cpp"
setenv LDFLAGS "-L/sw/lib -ldl"
./CVSMake (to do the autoconf stuff)
./configure --prefix=/sw
this should result in a successful configure. Then
make
and wait (and wait). It will either complete successfully (20%
chance) or fail. If it fails with something missing, install it and
start over. If it fails linking dxui (I think) with a strange
message about a relocation offset being too large, you have to do a
little messing around.
cd src/uipp/base
rm DXType.o
make
(this will recompile DXType.C)
copy the line which recompiled DXType.C into the clipboard.
rm DXType.o
paste the compile line from the clipboard back into a command line,
and edit somewhere rational into it the switch -fno-eh-cleanup-section
and execute the line. It should now rebuild DXType.o with this
mysterious option which only David Thompson understands. Then, re-do
make
and it should relink the library with this new, fixed object module.
Then, back out to the top-level makefile ane make again, which will
relink dxui with the fixed module, and everything should work (>50%
chance, now).
Good luck. This is terrible documentation, since I didn't record the
work I did as well as I should have, and it took a lot of hacking
(especially to find the -fno-eh-cleanup-section switch, which I
tracked down via a Google search where David Thompson suggested it to
someone else to fix a build in some other large project).
Marcus
