-optl behavior in ghc-7.8.1

Hi, I found that -optl behavior was changed in ghc-7.8.1 ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite. $ /opt/ghc-7.6.3/bin/ghc --make main.hs -optl=hello -v ... '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-o' 'main' 'main.o' 'hello' ... ... $ /opt/ghc-7.8.1/bin/ghc --make main.hs -optl=hello -v ... /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE hello -o main main.o ... ... Is it intentional change? I want to compile in a number of static libraries. I have the next line in my cabal file: ld-options: ./path/to/libsomething.a It works ok on linux and mac os with ghc-7.6.3, but with ghc-7.8.1 I get undefined references for symbols from the libsomething.a Thanks, Yuras

On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich
ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite.
(...)
Is it intentional change?
Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be. I want to compile in a number of static libraries. I have the next line
in my cabal file:
ld-options: ./path/to/libsomething.a
You're abusing ld-options. Use extra-libraries for this; if it doesn't work then you have found another bug and should file it as such. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote:
On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich
wrote: ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite.
(...)
Is it intentional change?
Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be.
Yes, I understand. But how the new behavior is better then the old one?
I want to compile in a number of static libraries. I have the next line
in my cabal file:
ld-options: ./path/to/libsomething.a
You're abusing ld-options. Use extra-libraries for this; if it doesn't work then you have found another bug and should file it as such.
extra-libraries doesn't work because it links with libsomething.so instead of libsomething.a

On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich
On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote:
On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich
Is it intentional change?
Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be.
Yes, I understand. But how the new behavior is better then the old one?
If it was not clear from what I said that some linker options must come before objects/libraries to have any effect then I am not sure what will clarify it for you.
ld-options: ./path/to/libsomething.a
You're abusing ld-options. Use extra-libraries for this; if it doesn't
work
then you have found another bug and should file it as such.
extra-libraries doesn't work because it links with libsomething.so instead of libsomething.a
Don't specify it using -l..., specify the .a file just as you were with ld-options. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Thu, 2014-04-10 at 12:13 -0400, Brandon Allbery wrote:
On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich
wrote: On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote:
On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich
Is it intentional change?
Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be.
Yes, I understand. But how the new behavior is better then the old one?
If it was not clear from what I said that some linker options must come before objects/libraries to have any effect then I am not sure what will clarify it for you.
...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed.
ld-options: ./path/to/libsomething.a
You're abusing ld-options. Use extra-libraries for this; if it doesn't
work
then you have found another bug and should file it as such.
extra-libraries doesn't work because it links with libsomething.so instead of libsomething.a
Don't specify it using -l..., specify the .a file just as you were with ld-options.
Are you kidding me? cabal unconditionally adds "-l" to extra-libraries.

On 04/10/14 06:39 PM, Yuras Shumovich wrote:
...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed.
Hmm, I'm not sure if I'm the patch provider, but at least I provided patch which was merged into HEAD (don't have 7.8 branch here so check yourself) which fixes linking of binaries failure on Solaris. Please see b9b94ec82d9125da47c619c69e626120b3e60457 The core of the change is: - else package_hs_libs ++ extra_libs ++ other_flags + else other_flags ++ package_hs_libs ++ extra_libs the patch contains full explanation in comment so see it for more information. If this is not what bugs you, then please ignore me. Thanks, Karel

On Thu, 2014-04-10 at 18:49 +0200, Karel Gardas wrote:
On 04/10/14 06:39 PM, Yuras Shumovich wrote:
...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed.
Hmm, I'm not sure if I'm the patch provider, but at least I provided patch which was merged into HEAD (don't have 7.8 branch here so check yourself) which fixes linking of binaries failure on Solaris. Please see b9b94ec82d9125da47c619c69e626120b3e60457
The core of the change is:
- else package_hs_libs ++ extra_libs ++ other_flags + else other_flags ++ package_hs_libs ++ extra_libs
Thank you for pointing to the commit. I hoped it was incidental change, but now I see the reason. Thanks, Yuras
the patch contains full explanation in comment so see it for more information.
If this is not what bugs you, then please ignore me.
Thanks, Karel

On 10/04/2014 18:11, Yuras Shumovich wrote:
On Thu, 2014-04-10 at 18:49 +0200, Karel Gardas wrote:
On 04/10/14 06:39 PM, Yuras Shumovich wrote:
...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed.
Hmm, I'm not sure if I'm the patch provider, but at least I provided patch which was merged into HEAD (don't have 7.8 branch here so check yourself) which fixes linking of binaries failure on Solaris. Please see b9b94ec82d9125da47c619c69e626120b3e60457
The core of the change is:
- else package_hs_libs ++ extra_libs ++ other_flags + else other_flags ++ package_hs_libs ++ extra_libs
Thank you for pointing to the commit. I hoped it was incidental change, but now I see the reason.
Actually this was me: https://ghc.haskell.org/trac/ghc/changeset/1e2b3780ebc40d28cd0f029b90df102df... The problem I was fixing was that we weren't always passing the -optl options. Now when we invoke a program the -optXXX options always come first - I think before it was kind of random and different for each of the phases. Cheers, Simon
Thanks, Yuras
the patch contains full explanation in comment so see it for more information.
If this is not what bugs you, then please ignore me.
Thanks, Karel
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
a

On Mon, Apr 14, 2014 at 10:42 AM, Simon Marlow
The problem I was fixing was that we weren't always passing the -optl options. Now when we invoke a program the -optXXX options always come first - I think before it was kind of random and different for each of the phases.
Some things do need to come first, like that; but apparently we need either after-options or a more flexible library syntax. (Or an other-objects?) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On 14/04/2014 15:44, Brandon Allbery wrote:
On Mon, Apr 14, 2014 at 10:42 AM, Simon Marlow
mailto:marlowsd@gmail.com> wrote: The problem I was fixing was that we weren't always passing the -optl options. Now when we invoke a program the -optXXX options always come first - I think before it was kind of random and different for each of the phases.
Some things do need to come first, like that; but apparently we need either after-options or a more flexible library syntax. (Or an other-objects?)
If you need control over the ordering of all the linker options, you just put -optl in front of them all (object files, library files, -l, -L). Then you'll need at least one object file (an empty one will do) to convince GHC that you actually want to run the linker though. FWIW, this is what our build system does. Cheers, Simon

On Thu, Apr 10, 2014 at 12:39 PM, Yuras Shumovich
On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich
On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote:
On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich < shumovichy@gmail.com wrote:
Is it intentional change?
Pretty sure it is intentional, because it's necessary for some
On Thu, 2014-04-10 at 12:13 -0400, Brandon Allbery wrote: options.
ld
options are not in general position independent, and can't be.
Yes, I understand. But how the new behavior is better then the old one?
If it was not clear from what I said that some linker options must come before objects/libraries to have any effect then I am not sure what will clarify it for you.
...and other linker options must come after, like in my case. So what?
Is your use case that much more important than everyone else's that other people's bugs must be rejected for your convenience? This has been an issue for other people and the change was needed.
Are you kidding me? cabal unconditionally adds "-l" to extra-libraries.
I may be misremembering some other option; I do recall people using direct references to static archives in cabal files, and not via ld-options where they don't belong. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (4)
-
Brandon Allbery
-
Karel Gardas
-
Simon Marlow
-
Yuras Shumovich