Hello,
I've fixed it in the darwinports version. I patched the linker to try to find symbols
with and without a leading underscore. I thought I had sent a note to the list
but perhaps I overlooked doing so.
The underlying issue is that there are versions of dlcompat using both conventions.
Darwinports uses the port-fink convention (dlcompat adds a leading underscore),
Wolfgang's package uses the fink convention (dlcompat does not add a leading underscore).
Ah yes, that explains everything. Thanks for finding that out.
I changed Linker.c to look up symbols with the GHC prefixed leading underscore removed.
If the lookup fails, it trys the unmodified symbol.
For reference, rebuilding dlcompat with debugging caught the error immediately,
showing the stray underscore.
The patch is a simple and should allow Linker.c to work on systems that use either
convention. I've attached it in case it's useful to add it to the repository. If not,
I'm content to patch the downloaded source.
Sorry for my silence in the past week.
While your patch should work, I remember seeing C code that uses function names like "foo" and "_foo" in the same way that a Haskell programmer might use foo and foo', so I had a bad feeling about automatically trying both.
I've just commited a patch (rev 1.129 on the head and 1.128.2.1 on the 6.2 branch) that just bypasses dlcompat for lookupSymbol only. It uses NSLookupAndBindSymbol directly, so we don't need to worry about differences between dlcompat versions any more.
Cheers,
Wolfgang
_______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
