Evan Laforge | 14 Sep 07:31 2012
Picon

ghc api and .o files

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
(Continue reading)

Evan Laforge | 14 Sep 07:37 2012
Picon

Re: ghc api and .o files

On Thu, Sep 13, 2012 at 10:31 PM, Evan Laforge <qdunkan <at> gmail.com> wrote:
> 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 <ian <at> well-typed.com>
Date:   Mon Sep 3 21:41:55 2012 +0100

    Move ldInputs into DynFlags

Thanks Ian!
JP Moresmau | 14 Sep 07:58 2012
Picon

Re: ghc api and .o files

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 <qdunkan <at> gmail.com> wrote:
> 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
(Continue reading)

Brandon Allbery | 14 Sep 20:22 2012
Picon

Re: ghc api and .o files

On Fri, Sep 14, 2012 at 1:31 AM, Evan Laforge <qdunkan <at> gmail.com> 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)

--
brandon s allbery                                      allbery.b <at> gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Evan Laforge | 25 Sep 02:39 2012
Picon

Re: ghc api and .o files

On Fri, Sep 14, 2012 at 6:22 PM, Brandon Allbery <allbery.b <at> gmail.com> wrote:
> On Fri, Sep 14, 2012 at 1:31 AM, Evan Laforge <qdunkan <at> gmail.com> 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.
Brandon Allbery | 25 Sep 15:37 2012
Picon

Re: ghc api and .o files

On Mon, Sep 24, 2012 at 8:39 PM, Evan Laforge <qdunkan <at> gmail.com> wrote:
> ("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 <at> gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Gmane