Does anybody know how to install the hugs graphics library with Mac OS X using XDarwin? I tried a couple of things that didn't work and figured that somebody has probably sorted this out. Thanks, Warren
Does anybody know how to install the hugs graphics library with Mac OS X using XDarwin? I tried a couple of things that didn't work and figured that somebody has probably sorted this out.
I'm afraid I don't know of anyone having done this but maybe it'd help if we narrowed down which bit is causing problems. 1) Is Hugs working ok? Probably yes or you'd have said. 2) Is the GreenCard processor working ok? Probably yes but probably irrelevant since the HGL ships with copies of the files generated by GreenCard. 3) Are the GreenCard-generated C files in the HGL compiling and linking ok? The answer to this is often "no". The instructions for building the object files vary a bit from one platform to another and we haven't got a complete list of the instructions for each. This is probably the problem though it can be confused with the next problem. 4) Is Hugs correctly loading the compiler and linked .c files from the HGL? IIRC, Hugs uses one of libdl, libdld, libshl or <some Win32 library whose name I forget> to load these files. Hugs also has to work around a curious feature of Unix compilers/linkers: some like to prefix C function names with underscores and some don't. Hugs tries to determine which to do when it is configured. If the configuration process can't detect the library Hugs needs or if it misdetects the need for an underscore, loading will not work. -- Alastair Reid ps In my spare time I'm trying to improve Hugs' foreign function interface (ffi). As part of this, I'm hoping to cleanup problems 3 and 4 by having Hugs distributions include a script which builds the .o correctly and by extending the test suite to check that this part of the ffi is working ok. The move towards the new hierarchial libraries will also help in a way - the libraries include so much ffi-dependent code that we simply won't be able to build a Hugs distribution without getting the ffi working either in dynamic linking mode (readily implemented on many platforms, what I describe above) or in the more rarely used static linking mode (less flexible but very portable, used in systems that lack dynamic linking).
On Sunday, June 9, 2002, at 11:31 , F. Warren Burton wrote:
Does anybody know how to install the hugs graphics library with Mac OS X using XDarwin? I tried a couple of things that didn't work and figured that somebody has probably sorted this out.
Thanks, Warren
I made a quick attempt at installing the graphics library with MacOS X in preparation for the Dec-2001 Hugs release, but I wasn't able to get past some DLL related problems. This is were I stopped: ERROR "lib/x11/Xlib_StdDIS.hs" - Error while importing DLL "/Users/nordland/src/graphics-2.0.4/lib/x11/Xlib_StdDIS.so": Not an recognisable object file BTW, getting this far requires replacing "-shared" with "-dynamic", and "ld" with "libtools" in the Makefile, as well as adding "-lSystem" to the definition of LDFLAGS. I haven't found the motivation to investigate this problem any further, though. Any thoughts, Alastair? -- Johan
I made a quick attempt at installing the graphics library with MacOS X in preparation for the Dec-2001 Hugs release, but I wasn't able to get past some DLL related problems. This is were I stopped:
ERROR "lib/x11/Xlib_StdDIS.hs" - Error while importing DLL "/Users/nordland/src/graphics-2.0.4/lib/x11/Xlib_StdDIS.so": Not an recognisable object file
BTW, getting this far requires replacing "-shared" with "-dynamic", and "ld" with "libtools" in the Makefile, as well as adding "-lSystem" to the definition of LDFLAGS.
One of two things is (I think) going on: 1) The generated .so file is invalid. My memory of libtools is that it acts in quite a different way from ld -r and friends. It could be that the result isn't quite compatible with dlopen and friends. Or it could be that the way you invoke libtools should be very different from ld. 2) The .so filename is invalid. This is entirely possible. IIRC, the object files generated by GreenCard are technically object files not shared object files so their name should end in .o not .so. (The reason for this confusion is that the fact that you use the -shared flag when building these files fooled me into thinking I was building a shared object file. Someone later told me I was wrong.) Or, maybe Mac OS X uses a different file suffix for object files (e.g., .dll) or doesn't use a file suffix at all? If so, it's possible that libtool might do the right thing if invoked right but that the current Makefile overrides this correct behaviour? -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Hi Alastair, I've gotten a bit further, I think. After replacing "-shared" with "-bundle", and setting "LD" to "cc" (which are the RIGHT values, and actually mentioned in the distributed ffi documentation -- blush!), the process fails at load time: Reading file "X.hs": ERROR "X.hs":3853 - Unknown primitive reference "prim_X_fontRightToLeft" However, running nm X.so | grep fontRightToLeft gives 0001408c t _prim_X_fontRightToLeft That is, we seem to have run into the leading underscore problem you mentioned. I don't have GreenCard installed, so I can't regenerate X.c the proper way. Is there a better way of making a MacOS X compatible distribution than requiring the user to run GreenCard? -- Johan On Monday, June 10, 2002, at 06:58 , Alastair Reid wrote:
I made a quick attempt at installing the graphics library with MacOS X in preparation for the Dec-2001 Hugs release, but I wasn't able to get past some DLL related problems. This is were I stopped:
ERROR "lib/x11/Xlib_StdDIS.hs" - Error while importing DLL "/Users/nordland/src/graphics-2.0.4/lib/x11/Xlib_StdDIS.so": Not an recognisable object file
BTW, getting this far requires replacing "-shared" with "-dynamic", and "ld" with "libtools" in the Makefile, as well as adding "-lSystem" to the definition of LDFLAGS.
One of two things is (I think) going on:
1) The generated .so file is invalid.
My memory of libtools is that it acts in quite a different way from ld -r and friends. It could be that the result isn't quite compatible with dlopen and friends. Or it could be that the way you invoke libtools should be very different from ld.
2) The .so filename is invalid.
This is entirely possible. IIRC, the object files generated by GreenCard are technically object files not shared object files so their name should end in .o not .so. (The reason for this confusion is that the fact that you use the -shared flag when building these files fooled me into thinking I was building a shared object file. Someone later told me I was wrong.)
Or, maybe Mac OS X uses a different file suffix for object files (e.g., .dll) or doesn't use a file suffix at all? If so, it's possible that libtool might do the right thing if invoked right but that the current Makefile overrides this correct behaviour?
-- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Reading file "X.hs": ERROR "X.hs":3853 - Unknown primitive reference "prim_X_fontRightToLeft"
However, running
nm X.so | grep fontRightToLeft
gives
0001408c t _prim_X_fontRightToLeft
That is, we seem to have run into the leading underscore problem you mentioned.
There must be something else going on here because... Because of issues like the leading underscore, Hugs only uses dlopen on the function initModule at the end of GreenCard generated files. The function initModule returns a lookup table that looks like this: static struct primitive primTable[] = { {"prim_X", 3, prim_X}, {"prim_Y", 3, prim_Y}, }; So the error message is not reporting problems finding a C symbol "prim_X_fontRightToLeft" but problems finding a Hugs symbol table entry "prim_X_fontRightToLeft". Looking at X.hs, prim_X_fontRightToLeft is the last primitive in the file so it is the first one that Hugs tries to resolve. This probably means that the entire symbol table is missing.
I don't have GreenCard installed, so I can't regenerate X.c the proper way. Is there a better way of making a MacOS X compatible distribution than requiring the user to run GreenCard?
Just do what we do with the standard HGL distribution: include the .c and .hs files in the distro and don't set rerun_GC=yes. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
On Wednesday, June 12, 2002, at 01:27 , Alastair Reid wrote:
Reading file "X.hs": ERROR "X.hs":3853 - Unknown primitive reference "prim_X_fontRightToLeft"
However, running
nm X.so | grep fontRightToLeft
gives
0001408c t _prim_X_fontRightToLeft
That is, we seem to have run into the leading underscore problem you mentioned.
There must be something else going on here because...
Because of issues like the leading underscore, Hugs only uses dlopen on the function initModule at the end of GreenCard generated files. The function initModule returns a lookup table that looks like this:
static struct primitive primTable[] = { {"prim_X", 3, prim_X}, {"prim_Y", 3, prim_Y}, };
So the error message is not reporting problems finding a C symbol "prim_X_fontRightToLeft" but problems finding a Hugs symbol table entry "prim_X_fontRightToLeft". Looking at X.hs, prim_X_fontRightToLeft is the last primitive in the file so it is the first one that Hugs tries to resolve.
This probably means that the entire symbol table is missing.
Sounds convincing. The odd thing is that Xlib_StdDIS seems to load ok, though. And small ffi examples also work as they should under MacOS X. I'll take some time to debug this to find out what happens. -- Johan
It looks like libSystem defines bzero. [localhost:/usr/lib] burton% nm -o libSystem* | grep bzero | grep T libSystem.B.dylib:bzero.o:70004bd0 T _bzero libSystem.B_debug.dylib:bzero.o:48da6160 T _bzero libSystem.B_profile.dylib:bzero.o:48da5010 T _bzero libSystem.dylib:bzero.o:70004bd0 T _bzero libSystem_debug.dylib:bzero.o:48da6160 T _bzero libSystem_profile.dylib:bzero.o:48da5010 T _bzero [localhost:/usr/lib] burton% When I make the changes Johan suggests, I get exactly the same problem:
Hi Alastair,
I've gotten a bit further, I think.
After replacing "-shared" with "-bundle", and setting "LD" to "cc" (which are the RIGHT values, and actually mentioned in the distributed ffi documentation -- blush!), the process fails at load time:
Reading file "X.hs": ERROR "X.hs":3853 - Unknown primitive reference "prim_X_fontRightToLeft"
However, running
nm X.so | grep fontRightToLeft
gives
0001408c t _prim_X_fontRightToLeft
That is, we seem to have run into the leading underscore problem you mentioned.
I don't have GreenCard installed, so I can't regenerate X.c the proper way. Is there a better way of making a MacOS X compatible distribution than requiring the user to run GreenCard?
-- Johan
My edited Makefile is as follows (so everybody is clear on what everybody else is doing): ############################################################################## # Makefile for Xlib with Hugs on Unix # # This makefile is for GNU Make ver. 3.76 or later. ############################################################################## ################################################################ # Configuration parameters. These may need slight modification. # # Rather than edit this file, you can override the settings when you # invoke Make. For example: # # make system=SunOS X_dir=/usr/local/X11R6 # ################################################################ # What OS are we using? Affects choice of linker flags. # Possible values: Linux, FreeBSD, NetBSD, SunOS and Unixlike # FWB changed # system=Linux # to system=FreeBSD # FWB end # Which directory contains lib/libX11.a and include/X11/X.h? X_dir=/usr/X11R6 # Which directory is Hugs installed in? # FWB changed # hugs_install=/usr/share/hugs # to hugs_install=/usr/local/share/hugs # FWB end # hugs_install=$(HOME)/local/share/hugs # Should we rerun GreenCard if GreenCard generated files are out of date? # (This will usually be set to "no" in distributions and "yes" in # development copies.) rerun_GC=no ################################################################ # Tools and how to run them. Nothing below this line should # need modified. ################################################################ SHELL = /bin/sh RM = rm -f # At least Sun's Workshop C Compiler 5.0 98/12/15 C 5.0 has trouble with # some of the generated C code. Insist on gcc for now. # FWB changed # CC = gcc # to CC = cc # FWB end INCLUDES = -I$(X_dir)/include -I$(hugs_install)/include # FWB changed # LD = ld # to LD = cc # and # LDFLAGS += -L$(X_dir)/lib -lX11 # to LDFLAGS += -L$(X_dir)/lib -lX11 -lSystem # FWB end # The following choices have been found to be appropriate for building # shared object files on various systems. # Please let us know if these don't work or if you know the appropriate # choice for other systems. LDFLAGS_MKSO.Linux = -shared # FWB changed # LDFLAGS_MKSO.FreeBSD = -shared # to LDFLAGS_MKSO.FreeBSD = -bundle # FWB end LDFLAGS_MKSO.NetBSD = -shared LDFLAGS_MKSO.SunOS = -G LDFLAGS_MKSO.Unixlike = -shared LDFLAGS_MKSO = $(LDFLAGS_MKSO.$(system)) GC = green-card GC_OPTS = --target=hugs ################################################################ # Implicit rules for GreenCard and shared objects ################################################################ ifeq ($(rerun_GC),yes) %.c %.hs: %.gc $(GC) $(GC_OPTS) $< endif %.o: %.c $(CC) -c $(CPPFLAGS) $(INCLUDES) $(CFLAGS) $< -o $@ %.so: %.o $(LD) $(LDFLAGS_MKSO) $(LDFLAGS) $^ -o $@ ################################################################ # Source and object files ################################################################ gc_sources = $(wildcard *.gc) c_sources = $(wildcard cbits/*.c) hs_gen_sources = $(gc_sources:.gc=.hs) all_hs_sources = $(hs_sources) $(hs_gen_sources) c_gen_sources = $(gc_sources:.gc=.c) all_c_sources = $(c_sources) $(c_gen_sources) all_c_objects = $(all_c_sources:.c=.o) shared_objects = $(gc_sources:.gc=.so) ################################################################ # Main targets ################################################################ .PHONY: all all: $(hs_gen_sources) $(shared_objects) ifeq ($(rerun_GC),yes) clean:: $(RM) $(hs_gen_sources) $(RM) $(c_gen_sources) endif clean:: $(RM) $(all_c_objects) $(RM) $(shared_objects) ################################################################ # Auxiliary targets ################################################################ .PRECIOUS: $(hs_gen_sources) $(shared_objects) .INTERMEDIATE: cbits/auxiliaries.o # Additional dependences. Xlib.so : cbits/auxiliaries.o Xlib.o X.o : cbits/HsXlib.h ################################################################ # End ################################################################
Alastair and Johan, I had one other thought on compiling the graphics library on Mac OS X. The standard C compiler is based on gcc 2.9.52. It looks like a gcc 3 compiler is available. Is this likely to make a difference? I did try gnumake in place of make and it didn't make any difference. Warren
Alastair and Johan, I had one other thought on compiling the graphics library on Mac OS X. The standard C compiler is based on gcc 2.9.52. It looks like a gcc 3 compiler is available. Is this likely to make a difference?
I wouldn't think so - the code is known to work with gcc 2.X compilers on other platforms as well as Microsoft Visual C compiler and I think Sun's compiler and HP's C compiler too. Pretty much all C compilers can build appropriate binaries - the only difference is in what command line you issue to make them do it. It's hard to figure out what's wrong remotely - what I really need is to run Hugs with a debugger and watch what it does or does not do when it loads files. Is there any chance you could give me an account on your machine for a few hours so that I can play with this directly? [If the answer is yes, don't forget to trim the reply-to line a bit] -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Does anybody know how to install the hugs graphics library with Mac OS X using XDarwin? I tried a couple of things that didn't work and figured that somebody has probably sorted this out.
Warren arranged access to his machine for me and we got it sorted out. Anyone else wanting to use HGL with Hugs on Darwin should: Fetch Hugs from the CVS repository and build/install in the normal way. (Small changes made in the dynamic loading code.) Fetch HGL from the webpage (http://haskell.org/graphics/). Add this line to graphics-2.0.4/lib/x11/Makefile: LDFLAGS_MKSO.MacOSX = -bundle -lc Build using the command: make system=MacOSX CC=cc LD=cc Enjoy! -- Alastair Reid Reid Consulting (UK) Ltd
In case anyone thinks my instructions for using HGL on Darwin sound a bit tricky, I've put together a current CVS snapshot and a patched copy of the HGL. You can get them from: http://haskell.org/graphics-darwin/ To install (assuming you put them in $HOME) cd $HOME mkdir local # or wherever you like to do this cd local tar zxvf ../hugs98-120602.tgz cd hugs98/src/unix ./configure --prefix=$HOME/local --with-readline cd .. make make install cd ../.. tar zxvf ../graphics-2.0.4.a.src.tar.gz cd graphics-2.0.4/lib/x11 make system=MacOSX CC=cc LD=cc cd ../../demos $HOME/local/bin/hugs -P$HOME/local/graphics-2.0.4/lib/x11: HelloWorld.hs main (On the machine I tested this on, readline wasn't installed. The install continued anyway but it'd be best to install readline and reinstall.) Enjoy! -- Alastair Reid Reid Consulting (UK) Ltd
On Wednesday, June 12, 2002, at 11:32 , Alastair Reid wrote:
Does anybody know how to install the hugs graphics library with Mac OS X using XDarwin? I tried a couple of things that didn't work and figured that somebody has probably sorted this out.
Warren arranged access to his machine for me and we got it sorted out.
Anyone else wanting to use HGL with Hugs on Darwin should:
Fetch Hugs from the CVS repository and build/install in the normal way. (Small changes made in the dynamic loading code.)
Fetch HGL from the webpage (http://haskell.org/graphics/).
Add this line to graphics-2.0.4/lib/x11/Makefile:
LDFLAGS_MKSO.MacOSX = -bundle -lc
Build using the command:
make system=MacOSX CC=cc LD=cc
Enjoy!
-- Alastair Reid Reid Consulting (UK) Ltd
Hi guys, Sorry about my silence lately, but I'm currently involved in an urgent digging up the drainage system around the basement of my house :-( I'll check out the recent commits as soon as I'm able. -- Johan
participants (3)
-
Alastair Reid -
F. Warren Burton -
Johan Nordlander