
I'm using the GHC api to run a little REPL for my app. This involves linking in some compiled C, and as long as it's in a library it's fine, I just pass -lwhatever to parseDynamicFlags and it's happy. However, I also have a plain .o file, and from poking at the ghci source, it looks like that works by consing onto v_Ld, which is not exported from StaticFlags. I was just about to go verify this, but it looks like it just changed! So maybe .o files can now be passed to parseStaticFlags? Or even better, parseDynamicFlags? However, it seems to have happened very recently, and 7.6.1 is still using the v_Ld global. Does this mean that there's no way to link in an arbitrary .o? I suppose I can work around it by packing the .o into a libx.a and then passing -lx. Relatedly, I've noticed that OS X is forgiving when you don't link in a needed object. It will let me run code, but if I call a function that's not linked in I get a crash. However, linux immediately prints "unknown symbol `etc.'". The OS X behaviour is more convenient because it's easy to avoid calling the missing functions, and difficult to figure out how to cut all the dependencies so they're not needed, but the linux way is certainly safer. Does anyone know why this difference exists? Just curious. As an aside, I recently upgraded to 7.6.1 from 7.0.3 and the API changed in a numer of ways. Is there any documentation for those changes? I'm guessing not, since there's not much documentation for the API itself, except of course the code. I noticed that GHC.getWarnings disappeared, and seems to have been replaced with either printing directly to stderr or throwing an exception, e.g. HscTypes.handleFlagWarnings. Other than the expected hassles from depending on an internal API, 7.6.1 has been great so far, except of course hackage had to go down as soon as it was time to cabal install everything. thanks!

On Thu, Sep 13, 2012 at 10:31 PM, Evan Laforge
I was just about to go verify this, but it looks like it just changed! So maybe .o files can now be passed to parseStaticFlags? Or even better, parseDynamicFlags?
Aha:
commit 61d41b90bde303d356540a8df44a2fffdd715aa5
Author: Ian Lynagh

I also would like to see an API change document when a new version of
GHC is released! Now a few libraries use the API, so I don't know if
it can be considered "internal".
JP
On Fri, Sep 14, 2012 at 7:31 AM, Evan Laforge
I'm using the GHC api to run a little REPL for my app. This involves linking in some compiled C, and as long as it's in a library it's fine, I just pass -lwhatever to parseDynamicFlags and it's happy. However, I also have a plain .o file, and from poking at the ghci source, it looks like that works by consing onto v_Ld, which is not exported from StaticFlags.
I was just about to go verify this, but it looks like it just changed! So maybe .o files can now be passed to parseStaticFlags? Or even better, parseDynamicFlags?
However, it seems to have happened very recently, and 7.6.1 is still using the v_Ld global. Does this mean that there's no way to link in an arbitrary .o? I suppose I can work around it by packing the .o into a libx.a and then passing -lx.
Relatedly, I've noticed that OS X is forgiving when you don't link in a needed object. It will let me run code, but if I call a function that's not linked in I get a crash. However, linux immediately prints "unknown symbol `etc.'". The OS X behaviour is more convenient because it's easy to avoid calling the missing functions, and difficult to figure out how to cut all the dependencies so they're not needed, but the linux way is certainly safer. Does anyone know why this difference exists? Just curious.
As an aside, I recently upgraded to 7.6.1 from 7.0.3 and the API changed in a numer of ways. Is there any documentation for those changes? I'm guessing not, since there's not much documentation for the API itself, except of course the code. I noticed that GHC.getWarnings disappeared, and seems to have been replaced with either printing directly to stderr or throwing an exception, e.g. HscTypes.handleFlagWarnings.
Other than the expected hassles from depending on an internal API, 7.6.1 has been great so far, except of course hackage had to go down as soon as it was time to cabal install everything.
thanks!
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- JP Moresmau http://jpmoresmau.blogspot.com/

On Fri, Sep 14, 2012 at 1:31 AM, Evan Laforge
Relatedly, I've noticed that OS X is forgiving when you don't link in a needed object. It will let me run code, but if I call a function that's not linked in I get a crash. However, linux immediately prints "unknown symbol `etc.'". The OS X behaviour is more convenient because it's easy to avoid calling the missing functions, and difficult to figure out how to cut all the dependencies so they're not needed, but the linux way is certainly safer. Does anyone know why this difference exists? Just curious.
Because the system dynamic loader has different defaults. OS X defaults to a lazier lookup than Linux does; Linux is actually somewhat lazy about it, just not as lazy as OS X. Unfortunately I only know how to make them both stricter, not lazier. ("man ld.so" on Linux, "man dyld" on OS X, for the details) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Fri, Sep 14, 2012 at 6:22 PM, Brandon Allbery
On Fri, Sep 14, 2012 at 1:31 AM, Evan Laforge
wrote: Relatedly, I've noticed that OS X is forgiving when you don't link in a needed object. It will let me run code, but if I call a function that's not linked in I get a crash. However, linux immediately prints "unknown symbol `etc.'". The OS X behaviour is more convenient because it's easy to avoid calling the missing functions, and difficult to figure out how to cut all the dependencies so they're not needed, but the linux way is certainly safer. Does anyone know why this difference exists? Just curious.
Because the system dynamic loader has different defaults. OS X defaults to a lazier lookup than Linux does; Linux is actually somewhat lazy about it, just not as lazy as OS X. Unfortunately I only know how to make them both stricter, not lazier.
("man ld.so" on Linux, "man dyld" on OS X, for the details)
I thought ghc uses its own homegrown loader, not the system one? I.e. ghci loads .o files, not .dyld or .so.

On Mon, Sep 24, 2012 at 8:39 PM, Evan Laforge
("man ld.so" on Linux, "man dyld" on OS X, for the details)
I thought ghc uses its own homegrown loader, not the system one? I.e. ghci loads .o files, not .dyld or .so.
The bytecode backend (used by ghci, TH, runghc) uses a separate loader; compiling uses the system loader. Either way, though, the system's dynamic loader (which is invoked very early in initializing a new program) is always used because system libraries are usually shared; on ELF systems, it's also the "interpreter" for compiled programs so is unavoidable. (I don't know if something similar is true for Mach-O.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
participants (3)
-
Brandon Allbery
-
Evan Laforge
-
JP Moresmau