Delimcc.0 OPAM Package Difficulty on Mac OS X

[paulfs...@gmail.com]

Hi Camlers!

I was so excited to see the inclusion of Delimcc in OPAM. I have big plans for it and set about trying to use it right away. However, I ran into difficulties finding symbols in some code I'm trying to build, and decided to try to track the issue down to its narrowest expression before asking for help. I now think I have. I should mention that I'm on Mac OS X 10.6.8 using OPAM 1.0.0 with the 4.00.1 toolset.

First, clone the opam-repository from github. Then:

$ cd opam-repository/packages/delimcc.0
$ curl -LO http://okmij.org/ftp/continuations/caml-shift.tar.gz
$ tar -xvzf caml-shift.tar.gz
$ cd caml-shift
$ patch -p1 < ../files/makefile_fix.patch
$ make all opt testd0
...

This should result in successful test output, with the last two lines reading:

test_t2
5 4 3 2 1

Now:

$ make findlib-install

Edit the testd0 entry in Makefile:

testd0: testd0.ml
ocamlfind ocamlc -package delimcc -linkpkg -o $@ $@.ml
./testd0

Now:

$ make clean
$ make testd0

I get...

ocamlfind ocamlc -package delimcc -linkpkg -o testd0 testd0.ml
File "testd0.ml", line 1:
Error: Error on dynamically loaded library: /Users/psnively/.opam/4.00.1/lib/stublibs/dlldelimcc.so: dlopen(/Users/psnively/.opam/4.00.1/lib/stublibs/dlldelimcc.so, 138): Symbol not found: _caml_realloc_stack
Referenced from: /Users/psnively/.opam/4.00.1/lib/stublibs/dlldelimcc.so
Expected in: flat namespace
in /Users/psnively/.opam/4.00.1/lib/stublibs/dlldelimcc.so
make: *** [testd0] Error 2

That is, dlldelimcc.so is loading, but it refers to _caml_realloc_stack, which it can't find.

This seems very much to be wrapped up in some distinction between using ocamlc straight and ocamlfind ocamlc with the package selection, but I'm having difficulty noodling out how. Any help would be greatly appreciated.

Thanks!
Paul

[paulfs...@gmail.com]

On Tuesday, April 9, 2013 4:12:13 AM UTC-7, ol...@okmij.org wrote:
> If your ocamlc
> is natively compiled, it does not use ocamlrun. And natively compiled
> ocamlc does _not_ export caml_realloc_stack. So, the premature, too
> helpful check really goes wrong here: caml_realloc_stack will be found
> at run-time but cannot be found at link time (where it is not really
> needed).
...
> The weak reference should never cause an error (even if it remains
> unresolved) -- according to my man pages. Apparently MacOS thinks
> different.

Thanks, Oleg! These were the two key insights.

1) Yes, ld on Darwin does apparently require the symbol to exist, even weakly. I interpret this to be due to a hard distinction on Darwin between ld and dyld—the static and dynamic linking regimes really are different, and it's not clear what "weakly linked" would even mean in the static case.

2) It occurred to me that ocamlfind might be interpreting "ocamlfind ocamlc" as "ocamlc.opt," so I did a little digging, and sure enough, there's a "findlib.conf" file in my library. Editing it revealed that that was precisely the case.

So on Mac OS X, changing findlib.conf's definition of "ocamlc" from "ocamlc.opt" to just "ocamlc" solves that problem.

Unfortunately, testd0opt is my next headache: it crashes with a Bus Error on Darwin, but not on Debian Wheezy running in VirtualBox. VirtualBox doesn't do processor emulation, so the issue once again seems to be differences in the Darwin runtime environment from the Linux runtime environment. In the native context, my initial guess is that it may have something to do with stack alignment issues, but this is merely a guess.

Thanks again!
Paul

[paulfs...@gmail.com]

On Friday, April 12, 2013 1:57:40 AM UTC-7, ol...@okmij.org wrote:
> I think Darwin and Ubuntu might be using different compilers (I think
> Apple bet on LLVM/clang). Even when both system use GCC, chances are
> they are of different versions, and some are more aggressive than
> others (at optimization). The first thing to try is to compile
> testd0opt without optimization (set -O0 or something like
> that). Second, if there is a way to get a stack trace on seg fault
> (e.g., via GDB) that could be helpful.
>
> BTW, it helps to compile stacks-native.c with the DEBUG
> option. One can use either -DDEBUG or change
>
> #define DEBUG 0
>
> at the beginning of the file so it reads "#define DEBUG 1". Now when
> running the tesd0opt we should see more output. It would be good to
> get the whole output of running tesd0opt.
>
> And another thing: for native delimcc we don't have to use dynamic
> linking. One may link in delimcc.cmx along with stacks-native.o
> statically. Perhaps that might help.

Once again, spot on, and this is a little disturbing: I got almost-correct output with -O0 and -DDEBUG=1, but there was still a message about "can't happen" at the very end, still using Apple's GCC 4.2.1 for Mac OS X 10.6.8. I got similarly incorrect results using the current release, 3.2, of clang. I then remembered that, some time ago, I'd installed a binary of a much more recent GCC—4.6.2—that I could optionally use. Using it, I get correct results from testd0opt, even without using -O0!

So stacks-native seems to throw both Apple's old GCC and _current_ clang for a loop, but even a minor dot-revision old GCC deals with it just fine. I find this surprising.

In any case, it's not delimcc.0's issue, so I have no patch to put into a pull request. I just need to be careful in choosing what tools to build with on my platform. :-)

Thanks for the help!
Paul

[paulfs...@gmail.com]

Hi again Oleg!

OK, new problem. I have testd0 and testd0opt passing wonderfully. However, I'm now trying to build HANSEI and test it. test_exactInfM passes, but:

./test_samplingM
rejection_sample: done 100 worlds
Fatal error: exception Assert_failure("samplingM.ml", 16, 9)
make: *** [test_samplingM] Error 2

This doesn't appear to be due to odd Mac OS X compiler optimization/linking issues, as I can consistently reproduce this under either Mac OS X 10.6.8 or CentOS 6.4 on OCaml 4.00.1 on x86_64. Any further advice would be greatly appreciated.

Many thanks and best regards,
Paul