Re: ghc 6.0.1 and Mac OS X 10.2.6 build

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