Haskell GHC生成的临时.o文件的用途和来源

作为发展我对GHC理解的一部分，我希望能够将GHC生成的程序集与GHC rts（以及其他必要的库）手动链接，以生成可运行的文件。
特别是……
我有一个文件

helloworld.hs

，其内容非常简单

main = putStrLn "Hello, World! again"

如果我运行

ghc-c-o helloworld.o helloworld.hs

生成程序集。 我想知道如何手动链接

helloworld.o

如果我运行

ghc-o runnable helloworld.o-v3

来查看ghc是如何实现这一点的（使用详细的输出），我会看到这一点

Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3
Using binary package database: /usr/lib/ghc/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d
wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181
wired-in package ghc mapped to ghc-7.10.3-624693c6aa854116c707bc7b4d0d7cb6
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: 
Created temporary directory: /tmp/ghc54ce_0
*** C Compiler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc54ce_0/ghc_1.c -o /tmp/ghc54ce_0/ghc_2.o -I/usr/lib/ghc/include
*** C Compiler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc54ce_0/ghc_4.s -o /tmp/ghc54ce_0/ghc_5.o -I/usr/lib/ghc/include
*** Linker:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -o final helloworld.o -L/usr/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/lib/ghc/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc/rts /tmp/ghc54ce_0/ghc_2.o /tmp/ghc54ce_0/ghc_5.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lgmp -lm -lrt -ldl -lffi
*** Deleting temp files:
Deleting: /tmp/ghc54ce_0/ghc_7.rsp /tmp/ghc54ce_0/ghc_6.rsp /tmp/ghc54ce_0/ghc_5.o /tmp/ghc54ce_0/ghc_4.s /tmp/ghc54ce_0/ghc_3.rsp /tmp/ghc54ce_0/ghc_2.o /tmp/ghc54ce_0/ghc_1.c
*** Deleting temp dirs:
Deleting: /tmp/ghc54ce_0

我不能简单地使用对gcc的类似调用来链接helloworld.o。如果您查看上面的输出，gcc实际上创建了

/tmp/ghc54ce_0

，最终保存了七个不同的临时文件。其中两个文件是代码链接的目标文件。
我很难找到最初的

/tmp/ghc54ce_0/ghc_1.c

来自哪里。我也很好奇为什么这个过程的这一部分是必要的（即生成的内容不能包含在helloworld.o中尚未包含的静态库中）。

---

任何直接的信息，或在哪里找到答案的好线索将不胜感激

可能是你要找的国旗。这很有用，但不是我要找的。使用tmpdir标志时，文件仍然会自动删除。我要寻找的主要内容是更深入地了解ghc_1.c文件的起源（当然，对其内容的评估可能会产生一些线索。我会尝试在tmpdir中不允许删除文件），您尝试过忽略它们吗？我正在手动链接一个项目（虽然是嵌入的——因此我用C++编写了自己的main），它工作得很好，我不必担心这个tmp的东西。@Culex我认为您看到的标志是错误的-您可能希望

-保留tmp文件
，正如标志名称所暗示的，这将导致GHC不删除临时文件。您也可以重定向它们，但这是另一个问题。非常感谢您的帮助！我可以手动管理链接，我最终将使用
-keep tmp files
标志检查文件内容。不过，我仍然对这些文件的性质感到好奇。我将编辑这个问题以澄清这一点。