ghc 6.0.1 and Mac OS X 10.2.6 build

[Gregory Wright]

Hi Wolfgang,

Thanks again for the prompt reply.

I did exactly as you noted below (removed the framework support check 
from  configure.in,
ran autoconf and ./configure, then built. Everything works appears to 
work correctly but
ghci. (For example, I can build a network test program that queries a 
web server. It runs
correctly.)

I even did everything twice to make sure I hadn't done something 
foolish.

So now we are to the entirely strange problem. I'm running 
dlcompat-20030522.
It works as you mention below, calling NSIsSymbolDefined and 
NSLookupAndBindSymbol.

Now that I look at it, there are differences between the dlfcn.h 
headers. The dlsym prototypes
diff is

-extern void * dlsym(void * handle, const char *symbol);
+extern void * dlsym(void * dl_restrict handle, const char * 
dl_restrict symbol)

dl_restrict is just defined as the __restrict type qualifier. Perhaps a 
pointer aliasing
issue? I'll look into it some more later today.

Best Wishes,
Greg


On Thursday, August 7, 2003, at 03:46 AM, Wolfgang Thaller wrote:

>> I should note that I've done
>> the build without Wolfgang's HaskellSupportFramework, by setting the 
>> include
>> and library paths in build.mk. This is more compatible with the 
>> automated packing
>> scheme of DarwinPorts.
>
> Of course. The HaskellSupport.framework isn't necessary when the user 
> already has DarwinPorts installed; be sure to note somewhere that 
> GHC-compiled programs will require gmp and dlcompat.
>
>> by setting the include
>> and library paths in build.mk.
>
> The "official" way to disable the HaskellSupport.framework is to 
> modify configure.in (yes, I should really add a --configure option for 
> that):
>
> Lines 978 to 991 read:
> dnl ** (Mac OS X only: check for HaskellSupport.framework)
> HaveFrameworkHaskellSupport=NO
> if test $HostPlatform = "powerpc-apple-darwin"; then
>  AC_MSG_CHECKING([for HaskellSupport.framework])
>  save_libs="$LIBS"
>  LIBS="-framework HaskellSupport"
>  AC_TRY_LINK_FUNC(__gmpz_fdiv_qr, HaveFrameworkHaskellSupport=YES,)
>  if test $HaveFrameworkHaskellSupport = YES; then
>   AC_DEFINE(HAVE_FRAMEWORK_HASKELLSUPPORT)
>  fi;
>  LIBS="$save_libs"
>  AC_MSG_RESULT([$HaveFrameworkHaskellSupport])
> fi;
> AC_SUBST(HaveFrameworkHaskellSupport)
>
> Change that to just:
> HaveFrameworkHaskellSupport=NO
> AC_SUBST(HaveFrameworkHaskellSupport)
>
> Then rerun autoconf and ./configure.
>
>> The error message comes from ghc/rts/Linker.c. Apparently dlsym 
>> couldn't
>> find the symbol _free from libSystem.
>
> Which is entirely strange. I see no reason why that could possibly 
> happen.
>
>> I suspect that doing things this way I have to link HSbase_cbits.o 
>> (and its siblings)
>> with -lSystem, Is that correct, or is this a different problem?
>
> The ghci executable is already linked with -lSystem, otherwise it 
> wouldn't work at all. And Linker.c calls dlsym on the program handle, 
> which means that it just "has to" find _free.
> What version of dlcompat are you using? dlcompat's dlsym should just 
> call NSIsSymbolNameDefined and NSLookupAndBindSymbol when dlsym is 
> called with the program handle.
>
> Cheers,
>
> Wolfgang
>