ghci 7.4.1 no longer loading .o files?
marlowsd at gmail.com
Tue Feb 28 10:44:58 CET 2012
On 21/02/2012 04:57, Evan Laforge wrote:
> On Mon, Feb 20, 2012 at 8:33 PM, Evan Laforge<qdunkan at gmail.com> wrote:
>> On Mon, Feb 20, 2012 at 1:14 AM, Eugene Crosser<crosser at average.org> wrote:
>>> On 02/20/2012 10:46 AM, Evan Laforge wrote:
>>>> Is there something that changed in 7.4.1 that would cause it to decide
>>>> to interpret .hs files instead of loading their .o files? E.g.:
>>> I don't *know* but could this have anything to do with this?
>> Indeed it was, I initially thought it wasn't because I wasn't using
>> flags for either, but then I remember ghci also picks up flags from
>> ~/.ghci. Turns out I was using -fno-monomorphism-restriction because
>> that's convenient for ghci, but not compiling with that.
>> I guess in the case where an extension changes the meaning of existing
>> code it should be included in the fingerprint and make the .o not
>> load. But my impression is that most ExtensionFlags let compile code
>> that wouldn't compile without the flag. So shouldn't it be safe to
>> exclude them from the fingerprint?
>> Either way, it's a bit confusing when .ghci is slipping in flags that
>> are handy for testing, because there's nothing that tells you *why*
>> ghci won't load a particular .o file.
> After some fiddling, I think that -osuf should probably be omitted
> from the fingerprint. I use ghc -c -o x/y/Z.hs.o. Since I set the
> output directly, I don't use -osuf. But since ghci needs to be able
> to find the .o files, I need to pass it -osuf. The result is that I
> need to pass ghc -osuf when compiling to get ghci to load the .o
> files, even though it doesn't make any difference to ghc -c, which is
> a somewhat confusing requirement.
> In fact, since -osuf as well as the -outputdir flags affect the
> location of the output files, I'd think they wouldn't need to be in
> the fingerprint either. They affect the location of the files, not
> the contents. If you found the files it means you already figured out
> what you needed to figure out, it shouldn't matter *how* you found the
> And doesn't the same go for -i? Isn't it valid to start ghci from a
> different directory and it should work as long as it's able to find
> the files to load?
I agree - I'll omit all these flags from the recompilation check in 7.4.2.
More information about the Glasgow-haskell-users