- Glasgow-haskell-users

ghc --make with .o files
by Andre Pang 29 Jun '03

29 Jun '03

Hi all, If you pass a list of .o files---and only .o files (i.e. no .hs files)---to GHC, and --make is specified, nothing happens. Is it possible to change this behaviour so that GHC will link the .o files together into an executable? The reason I'm asking for this is because --make is more intelligent than just using ghc without --make to perform the linking. In particular, it is intelligent enough to figure out what packages to link in, and will also automatically link in _stub.o files generated by "foreign import wrapper" statements. I'm working on GHC integration with Apple's Project Builder and Xcode IDEs, and having a more intelligent linking process would be really useful :). -- % Andre Pang : just.your.average.bounty.hunter

1 0

Bom dia glasgow-haskell-users
by Marta 28 Jun '03

28 Jun '03

1 0

RE: Win32 dlls -- how to do it?
by Andy Serpa 27 Jun '03

27 Jun '03

> ac> New to Haskell, new to GHC. My initial intention in picking > up ac> Haskell is to be able to write some functions in Haskell > and > then > ac> compile them into .dlls for Win32 that I can call from > programs ac> written in other languages. So before I get too > deeply > invested I > ac> want to make sure that is possible. > > It's certainly possible. I do it here all the time on a commercial > project. I even volunteered a few months ago to write some better > documentation, but I sadly have not had the time to do it. > > As Sigbjorn says, adding -package base when linking the DLL with ghc > will silence those errors from the linker. > Ok, "-package base" did the trick, and I was able to call the function from my other program. > The warning given when compiling the C code in dllMain.c comes from > the declaration of __stginit_Adder as > > EXTFUN(__stginit_Adder) > > Which is not really the type that startupHaskell expects. Declare > it instead as > > extern void __stginit_Adder(void); > > and the warning will be silenced. > Ok. > The much bigger gotcha is that the code in dllMain.c from Sect 11 of > the user's guide will probably not work, because Windows forbids > certain things from happening in dllMain (basically, anything that > could possibly cause one to reattach to the DLL). That includes > creating new threads, and that includes creating timers, and > startupHaskell tries to do that. I don't remember at the moment if > it is a problem when the GHC runtime is in a separate DLL, but it is > certainly a problem when linking the GHC runtime into the same DLL. > I did not try statically linking all into a single dll yet. We'll see. > My typical solution is to provide entry points to explicitly startup > and shutdown the Haskell runtime, outside of a call to dllMain. > Here is an example, calling Adder from Java: > > 1. Write some Haskell code to implement the add function in the DLL. > > Note > that Java will expect a mangled name, which we supply manually: > > ==== Adder.hs > module Adder (add) where > > import Foreign (Ptr, Int32) > > data JNIEnv > data JClass > > foreign export stdcall "Java_Adder_add" > add :: Ptr JNIEnv -> Ptr JClass -> Int32 -> Int32 -> IO Int32 > > add :: Ptr JNIEnv -> Ptr JClass -> Int32 -> Int32 -> IO Int32 > add _ _ m n = return (m + n) > ==================== > > 2. Compile. Don't forget -fglasgow-exts: > > ghc -fglasgow-exts -c Adder.hs > > 3. Write C functions that can be called by Java (mangling the names > again) > and that can be used to startup and shutdown the Haskell runtime. > > You > can't do this directly from Java, because the FFI functions don't > have > the mangled names that Java expects, and you can't do it from > Haskell > code for obvious reasons. > > ==== ccode.c > #include <jni.h> > #include <HsFFI.h> > > extern void __stginit_Adder(void); > > static char *args[] = { "ghcDll", 0 }; > static int argc = 1; > static char **argv = args; > > JNIEXPORT void JNICALL Java_Adder_haskellInit(JNIEnv *e, jclass c) { > hs_init(&argc, &argv); > hs_add_root(__stginit_Adder); > } > > JNIEXPORT void JNICALL Java_Adder_haskellExit(JNIEnv *e, jclass c) { > hs_exit(); > } > ==================== > > 4. Compile it. JAVAHOME is presumed to be set to the root of your > Java > install (the directory containing the "include" subdirectory): > > ghc -I$JAVAHOME/include -I$JAVAHOME/include/win32 -optc > -mno-cygwin > -c ccode.c > > 5. Link into DLL, using ghc (I generally call dllwrap directly, > because it > gives me finer (actually, just less verbose) control over DLL > options): > > ghc --mk-dll -optdll --add-stdcall-alias -o adder.dll Adder.o > Adder_stub.o ccode.o -package base > > "-optdll --add-stdcall-alias" is important, because Java can't > find > > the > entries otherwise. > > 6. Write a Java driver that loads the native library (the DLL), > initializes > the Haskell runtime, calls our simple DLL function, and then > shutdowns > the Haskell runtime: > > ==== Adder.java > public class Adder { > static { > System.loadLibrary("adder"); > haskellInit(); } > > public static native void haskellInit(); > public static native void haskellExit(); > > public static native int add(int m, int n); > > public static void main(String[] args) { > try { > System.out.println("Answer is: " + Adder.add(32, 10)); } > finally { > haskellExit(); }}} > ==================== > > 7. Compile the Java code: > > javac -classpath . Adder.java > > 8. Enjoy: > > java -classpath . Adder > > ---- Aha. I'll see if I can adapt that to my system. Thanks for all the help... Andy Serpa ac(a)onehorseshy.com

1 0

RE: Win32 dlls -- how to do it?
by Kevin S. Millikin 27 Jun '03

27 Jun '03

ac> New to Haskell, new to GHC. My initial intention in picking up ac> Haskell is to be able to write some functions in Haskell and then ac> compile them into .dlls for Win32 that I can call from programs ac> written in other languages. So before I get too deeply invested I ac> want to make sure that is possible. It's certainly possible. I do it here all the time on a commercial project. I even volunteered a few months ago to write some better documentation, but I sadly have not had the time to do it. As Sigbjorn says, adding -package base when linking the DLL with ghc will silence those errors from the linker. The warning given when compiling the C code in dllMain.c comes from the declaration of __stginit_Adder as EXTFUN(__stginit_Adder) Which is not really the type that startupHaskell expects. Declare it instead as extern void __stginit_Adder(void); and the warning will be silenced. The much bigger gotcha is that the code in dllMain.c from Sect 11 of the user's guide will probably not work, because Windows forbids certain things from happening in dllMain (basically, anything that could possibly cause one to reattach to the DLL). That includes creating new threads, and that includes creating timers, and startupHaskell tries to do that. I don't remember at the moment if it is a problem when the GHC runtime is in a separate DLL, but it is certainly a problem when linking the GHC runtime into the same DLL. My typical solution is to provide entry points to explicitly startup and shutdown the Haskell runtime, outside of a call to dllMain. Here is an example, calling Adder from Java: 1. Write some Haskell code to implement the add function in the DLL. Note that Java will expect a mangled name, which we supply manually: ==== Adder.hs module Adder (add) where import Foreign (Ptr, Int32) data JNIEnv data JClass foreign export stdcall "Java_Adder_add" add :: Ptr JNIEnv -> Ptr JClass -> Int32 -> Int32 -> IO Int32 add :: Ptr JNIEnv -> Ptr JClass -> Int32 -> Int32 -> IO Int32 add _ _ m n = return (m + n) ==================== 2. Compile. Don't forget -fglasgow-exts: ghc -fglasgow-exts -c Adder.hs 3. Write C functions that can be called by Java (mangling the names again) and that can be used to startup and shutdown the Haskell runtime. You can't do this directly from Java, because the FFI functions don't have the mangled names that Java expects, and you can't do it from Haskell code for obvious reasons. ==== ccode.c #include <jni.h> #include <HsFFI.h> extern void __stginit_Adder(void); static char *args[] = { "ghcDll", 0 }; static int argc = 1; static char **argv = args; JNIEXPORT void JNICALL Java_Adder_haskellInit(JNIEnv *e, jclass c) { hs_init(&argc, &argv); hs_add_root(__stginit_Adder); } JNIEXPORT void JNICALL Java_Adder_haskellExit(JNIEnv *e, jclass c) { hs_exit(); } ==================== 4. Compile it. JAVAHOME is presumed to be set to the root of your Java install (the directory containing the "include" subdirectory): ghc -I$JAVAHOME/include -I$JAVAHOME/include/win32 -optc -mno-cygwin -c ccode.c 5. Link into DLL, using ghc (I generally call dllwrap directly, because it gives me finer (actually, just less verbose) control over DLL options): ghc --mk-dll -optdll --add-stdcall-alias -o adder.dll Adder.o Adder_stub.o ccode.o -package base "-optdll --add-stdcall-alias" is important, because Java can't find the entries otherwise. 6. Write a Java driver that loads the native library (the DLL), initializes the Haskell runtime, calls our simple DLL function, and then shutdowns the Haskell runtime: ==== Adder.java public class Adder { static { System.loadLibrary("adder"); haskellInit(); } public static native void haskellInit(); public static native void haskellExit(); public static native int add(int m, int n); public static void main(String[] args) { try { System.out.println("Answer is: " + Adder.add(32, 10)); } finally { haskellExit(); }}} ==================== 7. Compile the Java code: javac -classpath . Adder.java 8. Enjoy: java -classpath . Adder ---- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x162 http://www.atcorp.com

1 0

Win32 dlls -- how to do it?
by Andy Serpa 27 Jun '03

27 Jun '03

Hello, New to Haskell, new to GHC. My initial intention in picking up Haskell is to be able to write some functions in Haskell and then compile them into .dlls for Win32 that I can call from programs written in other languages. So before I get too deeply invested I want to make sure that is possible. So I tried following the example in the GHC docs about generating a .dll to be called from external programs in another language, but it does not compile correctly. I tried using the *EXACT* files specified in section 11.4.4. of the GHC manual. The Adder module compiles fine (& produces the extra stub), but "DllMain.c" gives a (single) warning, and the final step: ghc mk-dll -o adder.dll adder.o adder_stub.o dllMain.o fails with a whole slew of errors. I'm using GHC 6.0. Andy Serpa ac(a)onehorseshy.com

2 1

PLEASE HELP!!!
by Jonas savimbi jr 26 Jun '03

26 Jun '03

From:Jonas Savimbi Jr, Johannesburg, South Africa Email: jonassjr(a)phantomemail.com June 25th, 2003. Dear Sir, It is my humble pleasure to write you this letter irrespective of the fact that you do not know me. However, I got your name through your country business directory here in my search for a reliable and trustworthy person that can assist me confidently. My name is Mr.Jonas Savimbi Jr.I am the son of Late Dr. Jonas Savimbi from Angola. I am 29 years old and I have got two younger sisters of same blood. Our mother died almost a year ago. We are all fighting for political asylum in South Africa. We cannot find a home in Angola anymore because of the war that our late father fought with the government of Angola until he died in that war. The government of Angola is now mad at us because our late father also wanted to be president and caused the people to fight the war for him because he was the president of UNITA political movement of Angola. So now we are in South Africa and we are suffering too much because we don't have money and the government of South Africa will not give jobs to asylum seekers. I am much concerned about my younger sisters who are finding it very difficult to manage in the situation. But I know that we should not suffer this way. I know that I must not let my younger sisters get into trouble because of money. So after consideration I am hereby begging for your assistance to help me to recover the sum of USD $29 Million which is my inheritance from my late mother. My late mother had taken this money with her to Spain in a diplomatic metal box marked (Precious Stones). Subsequently she lodged the metal box (As precious Stones) with a Securities and Valuables Protection company in Spain. I am supposed to be the beneficiary in the event of her death. However, all effort I made to go Spain to claim was refused by the Spainish embassy. And this was while it was still possible for me to travel. Now I cannot travel anywhere anymore. So in the situation that we are facing now,I must find somebody who can go to Spain on my behalf. I understand that I will have to transfer my beneficiary rights unto you. I am willing to do so in the hope that you are a God fearing person who will not abandon us after you have the money. So from the bottom of my heart I am giving you 20% of the all the money. Once we have enough to sustain us sufficiently, you may be come our fund manager and invest the rest wisely for us. If you will be kind to assist us, please inform me urgently. Kind regards to you and your family. Sincerely, Jonas savimbi Jr.

1 0

RE: @-bindings broken in 6.0?
by Simon Marlow 26 Jun '03

26 Jun '03

> > I think lumping all these extensions under one switch is the > > problem. > > Yep, I agree. Would it be hard to split `-fglasgow-exts' > up? I'd greatly appreciate a more fine-grained control > here. The only difficulty is that we don't have an easy way to parameterise the parser, since it's generated from a fixed grammar. It might be possible to do it by having multiple entry points to the parser, sharing as much of the grammar as possible, but I haven't tried (it sounds a bit sledgehammerish). We can often do optional syntax by parameterising the lexer, however: in fact there are already four switches that affect the syntax (-fglasgow-exts, -farrows, -fwith, -fffi). These generally work by turning on or off certain keywords (eg. -fffi turns on the 'foreign' keyword), which is usually all you need. Bottom line: yes in most cases you can give separate extensions their own flags. We're starting to move in that direction for new extensions, and if we get around to it we might separate some of the existing extensions. Cheers, Simon

2 1

Re: FW: how and where to {-# specialize #-} ?
by Alan Mycroft 26 Jun '03

26 Jun '03

> Something similar was proposed by the gcc folk at their recent > conference. The idea is that when you gcc -O4 your .c files, you get .o > files containing an intermediate typed SSA form. Upon linking the > program, gcc invokes a 'smart linker' which runs another pass on the > whole program. This allows for all kinds of cross-module inlining, > specialisation etc. It's interesting that they are just *proposing* this. From the dagstuhl presentation http://www.dagstuhl.de/00381 in 2000, I understood that the SGI Pro64 compiler infrastructure already did this (i.e. stored a similar intermediate code structure in the .o files). I also understood that the Pro64 compiler sources were to be GPL'd. Cheers, Alan

1 0

RE: how and where to {-# specialize #-} ?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

| > The only workaround is to define T early, | > import it into A, and specialise A.f there. | | What if A is a pre-defined module, say FiniteMap? | Then I can't change its source text. (Which isn't even there.) | (Of course, I can grab it from the source distribution.) | | It is sad that the usage of libraries containing polymorphic code | (which is a good thing, for obvious software engineering reasons) | seems to imply runtime overheads, by preventing specialisation. | I agree that it is sad. The only way around it is to ship libraries with *all* their source code (perhaps hidden in the interface file). That could be done, but it'd be Real Work s

3 2

RE: @-bindings broken in 6.0?
by Simon Peyton-Jones 25 Jun '03

25 Jun '03

There's support for more fine-grained distinctions now. We hav -fffi -fglasgow-exts -farrows -fparr (Manuel's parallel array stuff) We could add -fth (or -fTH?) if that seemed better S | -----Original Message----- | From: Ralf Hinze [mailto:ralf@informatik.uni-bonn.de] | Sent: 24 June 2003 13:42 | To: Ketil Z. Malde; Simon Peyton-Jones | Cc: John Meacham; glasgow-haskell-users(a)haskell.org | Subject: Re: @-bindings broken in 6.0? | | > I think lumping all these extensions under one switch is the | > problem. | | Yep, I agree. Would it be hard to split `-fglasgow-exts' | up? I'd greatly appreciate a more fine-grained control | here. | | Cheers, Ralf |

6 5