ld-options is not taken into account when passed by command line or cabal.project.local #4925
Comments
|
Do you have any insight, of how this could happen ? |
|
I'd look at the config loading code, the bug is probably there somewhere.
On 5 Dec 2017 18:19, "Erèbe - Romain Gerard" <[email protected]> wrote:
Do you have any insight, of how this could happen ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4925 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC5T_y_husS8a5eN4j7T0FW0xCwdACHks5s9YlDgaJpZM4QztsL>
.
|
|
@hvr I tried to add a section with but the binary still end-up being dynamically linked. I will try to grab the HEAD of cabal, to poke around |
|
From what I understood so far, P.S: By any hasard do you how to start a cabal new-repl inside the cabal project and start the main function in an other Path (the other project I am trying to build) ? |
|
The problem seems to be in rebuildProjectConfig the action phaseReadProjectConfig correctly parse the .local file into a ProjectConfig and all the options are correctly there, but sadly the later phase phaseReadLocalPackages read the .cabal file into a SpecificSourcePackage and it is this one that is used by the resolver.
If I understand correctly, I think there is a missing step where we should update the SpecificSourcePackage with the resulting ProjectConfig. Can you confirm this hypothesis ? Unrelated to my issue, I think there is also an other bug in the function as in the last line |
|
@erebe Excellent sleuthing, would it be possible for you to create a pull request? |
|
I was not sure about the direction to take as the problem seemed deeper than my original issue. So I browsed a bit and stumbled upon #4737, regarding my last interrogation. It seems the problem is already known and worked on. |
|
I will try the PR next week, as for now I only have my laptop and building cabal on it is kind of long... |
|
Possibly related, some other places where cabal ignores linker related options: |
|
Tentative patch for this: #5451 I would appreciate testers. |
Hello,
While migrating some project from Stack to Cabal new-style I stumbled upon an issue regarding the ld-options field, which is not taken into account into command line and cabal.project.local but is, if added directly into xxx.cabal file of the project.
My goal is to compile the binary of the project with static linking instead of the standard dynamic one.
To do so, I am following those two steps:
After the build finish, sadly the final executable is still dinamicaly linked
The result is the same if we pass the configuration to new-build as so
here the output of cabal -v
and the output of ld in verbose mode (note the -dynamic-linker)
now if we override the .cabal file of the project and add the ld-options directly in it, ld is correctly told to link in static mode (note the -static instead -dynamic-linker)
the cabal new-build -v output
What is expected ?
When passing ld-option by command line or in cabal.project.local it should be taken into account.
Version of ghc and cabal
The text was updated successfully, but these errors were encountered: