Understanding the undefine flags passed to gcc when linking
Hi, When I run 'ghc -v ...', the linking is done via gcc->ld with a large list of -u flags passed in. I'm hoping to find a way to link my object files without those flags, but first I need to understand what they are doing. Can someone explain it to me? Or point me to documentation that explains it? My ultimate goal is to build a static Haskell library and make it available to c programmers ignorant of Haskell. The undefines described above are a major obstacle. Does anyone know a way around them? Thanks, Joe Bruce Phone: 509.372.6198 Pacific Northwest National Laboratory 902 Battelle Blvd. Richland, WA
Bruce, Joseph R (Joe) wrote:
When I run 'ghc -v ...', the linking is done via gcc->ld with a large list of -u flags passed in. I'm hoping to find a way to link my object files without those flags, but first I need to understand what they are doing. Can someone explain it to me? Or point me to documentation that explains it?
My ultimate goal is to build a static Haskell library and make it available to c programmers ignorant of Haskell. The undefines described above are a major obstacle. Does anyone know a way around them?
The -u flags arise because there is a circular dependency between the RTS (libHSrts.a) and the base package (libHSbase.a). The RTS refers to a few datatypes and functions in the base package, for instance the constructors for True and False, I#, C# and so on, and some exceptions that the RTS automatically raises for certain events (e.g. stack overflow, non-termination). One way to avoid needing the -u flags would be to link the base package twice, but that would slow down linking, and twice might not be enough. With shared libraries there's no problem, because we always just link the whole library, this is only an issue with static libraries. So for building a static Haskell library, can't you just link the RTS and base package together in a single .a file? Cheers, Simon
Thanks Simon. That is the best answer I've received to this question in many askings. I will try to go the shared library route. A question about you last comment: when you say link RTS and base, you mean extract the object files and package in a single .a? Am I going to run into namespace collisions? Joe
-----Original Message----- From: Simon Marlow [mailto:simonmarhaskell@gmail.com] Sent: Wednesday, March 12, 2008 3:18 PM To: Bruce, Joseph R (Joe) Cc: glasgow-haskell-users@haskell.org Subject: Re: Understanding the undefine flags passed to gcc when linking
Bruce, Joseph R (Joe) wrote:
When I run 'ghc -v ...', the linking is done via gcc->ld
with a large
list of -u flags passed in. I'm hoping to find a way to link my object files without those flags, but first I need to understand what they are doing. Can someone explain it to me? Or point me to documentation that explains it?
My ultimate goal is to build a static Haskell library and make it available to c programmers ignorant of Haskell. The undefines described above are a major obstacle. Does anyone know a way around them?
The -u flags arise because there is a circular dependency between the RTS (libHSrts.a) and the base package (libHSbase.a). The RTS refers to a few datatypes and functions in the base package, for instance the constructors for True and False, I#, C# and so on, and some exceptions that the RTS automatically raises for certain events (e.g. stack overflow, non-termination).
One way to avoid needing the -u flags would be to link the base package twice, but that would slow down linking, and twice might not be enough. With shared libraries there's no problem, because we always just link the whole library, this is only an issue with static libraries.
So for building a static Haskell library, can't you just link the RTS and base package together in a single .a file?
Cheers, Simon
Bruce, Joseph R (Joe) wrote:
Thanks Simon. That is the best answer I've received to this question in many askings.
I will try to go the shared library route.
Shared libraries are currently experimental - you'll probably experience problems, and parts of the infrastructure are still in flux. I wouldn't recommend relying on shared libraries just yet.
A question about you last comment: when you say link RTS and base, you mean extract the object files and package in a single .a? Am I going to run into namespace collisions?
Yes, put the whole of the RTS and base into a single .a. You shouldn't run into namespace collisions, as the symbol namespace is global anyway. Cheers, Simon
Joe
-----Original Message----- From: Simon Marlow [mailto:simonmarhaskell@gmail.com] Sent: Wednesday, March 12, 2008 3:18 PM To: Bruce, Joseph R (Joe) Cc: glasgow-haskell-users@haskell.org Subject: Re: Understanding the undefine flags passed to gcc when linking
Bruce, Joseph R (Joe) wrote:
When I run 'ghc -v ...', the linking is done via gcc->ld with a large list of -u flags passed in. I'm hoping to find a way to link my object files without those flags, but first I need to understand what they are doing. Can someone explain it to me? Or point me to documentation that explains it?
My ultimate goal is to build a static Haskell library and make it available to c programmers ignorant of Haskell. The undefines described above are a major obstacle. Does anyone know a way around them?
The -u flags arise because there is a circular dependency between the RTS (libHSrts.a) and the base package (libHSbase.a). The RTS refers to a few datatypes and functions in the base package, for instance the constructors for True and False, I#, C# and so on, and some exceptions that the RTS automatically raises for certain events (e.g. stack overflow, non-termination).
One way to avoid needing the -u flags would be to link the base package twice, but that would slow down linking, and twice might not be enough. With shared libraries there's no problem, because we always just link the whole library, this is only an issue with static libraries.
So for building a static Haskell library, can't you just link the RTS and base package together in a single .a file?
Cheers, Simon
participants (2)
-
Bruce, Joseph R (Joe) -
Simon Marlow