Opened 9 years ago

Closed 10 months ago

Last modified 4 months ago

#1407 closed feature request (fixed)

Add the ability to :set -l{foo} in .ghci files

Reported by: guest Owned by: archblob
Priority: normal Milestone: 7.10.3
Component: GHCi Version: 6.6.1
Keywords: Cc: hvr
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D194 Phab:D1310
Wiki Page:

Description

Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6.

The only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in "unknown flags in {-# OPTIONS #-} pragma: -lidn" in 6.4.2 and appears to be silently ignored in 6.6.

Attachments (2)

fix_1407.patch (5.1 KB) - added by archblob 2 years ago.
fix_T1407.patch (3.7 KB) - added by archblob 2 years ago.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 9 years ago by igloo

  • Milestone set to 6.8

This is related to allowing -package flags in OPTIONS_GHC, which is talked about in http://hackage.haskell.org/trac/ghc/wiki/GhcPackages

comment:2 Changed 9 years ago by simonmar

  • difficulty changed from Unknown to Easy (1 hr)
  • Milestone changed from 6.8 branch to 6.10 branch

comment:3 Changed 8 years ago by igloo

See also #2365

comment:4 Changed 8 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:5 Changed 8 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:6 Changed 7 years ago by igloo

  • Milestone changed from 6.10 branch to _|_

comment:7 Changed 7 years ago by simonmar

  • difficulty changed from Easy (1 hr) to Easy (less than 1 hour)

comment:8 Changed 4 years ago by mf825

  • Type of failure set to None/Unknown

I would like to second this request. I use emacs as an IDE, and call ghci from emacs with all the command line parameter handling in .ghci. Of course I could write elisp functions to pluck -l parameters from :set statements in .ghci, but that seems a little insane.

Also, since both -L and -l are documented as dynamic, and all dynamic command line arguments are documented to work both on the command line and in .ghci, I suggest this is changed into a bug.

I reproduced this with ghc-7.6.1 on debian and with ghc-7.4.1 on ubuntu.

comment:9 Changed 4 years ago by simonpj

  • Owner set to igloo

Ian, could you investigate why this doesn't already work? Thanks.

comment:10 Changed 4 years ago by igloo

This works:

$ ghci -lz
GHCi, version 7.7.20130112: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (dynamic) /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libz.so ... done
final link ... done
Prelude> import Foreign.C
Prelude Foreign.C> import Foreign.Ptr
Prelude Foreign.C Foreign.Ptr> foreign import ccall "zlibVersion" z :: IO CString
Prelude Foreign.C Foreign.Ptr> z >>= peekCString
"1.2.3.4"
Prelude Foreign.C Foreign.Ptr> 

This doesn't:

$ ghci    
GHCi, version 7.7.20130112: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :set -lz
Prelude> import Foreign.C
Prelude Foreign.C> import Foreign.Ptr
Prelude Foreign.C Foreign.Ptr> foreign import ccall "zlibVersion" z :: IO CString

ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
  zlibVersion
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
  glasgow-haskell-bugs@haskell.org

comment:11 Changed 3 years ago by igloo

  • Owner igloo deleted

comment:12 Changed 2 years ago by archblob

  • Cc hvr added
  • Status changed from new to patch

There may be some nuances in the whole linking stuff that I don't understand, so please review. As far as I can tell the patch works as expected.

comment:13 Changed 2 years ago by archblob

  • Owner set to archblob

Changed 2 years ago by archblob

comment:14 Changed 2 years ago by archblob

  • Milestone changed from to 7.10.1

comment:15 Changed 2 years ago by thoughtpolice

  • Status changed from patch to infoneeded

@archblob - it seems this doesn't correcly apply to HEAD anymore. Would you mind rebasing the changes?

Changed 2 years ago by archblob

comment:16 Changed 2 years ago by archblob

I have attached a fix based on HEAD. The fix has no test case because I'm not sure what libraries are guaranteed to be present on every system so that the test won't fail. If you can think of any, let me know and I'll add a test case or someone else can do it.

I'm sorry this took a week to rebase :-P.

comment:17 Changed 2 years ago by Austin Seipp <austin@…>

In 52eab67a99dd928204b730355245233fa96fa24d/ghc:

Add the ability to :set -l{foo} in ghci, fix #1407.

Summary:
The dynamic linking code was already there but it was not called
on flag changes in ghci.

Test Plan: validate

Reviewers: hvr, simonmar, austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D194

GHC Trac Issues: #1407

comment:18 Changed 2 years ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from infoneeded to closed

Merged, thanks!

comment:19 Changed 2 years ago by thoughtpolice

  • Differential Rev(s) set to Phab:D194

comment:20 Changed 15 months ago by thomie

  • Operating System changed from Unknown/Multiple to Windows
  • Owner archblob deleted
  • Resolution fixed deleted
  • Status changed from closed to new

There are 2 problems with the above patch on Windows:

  • the test fails, because -ldl can not be found.
  • in ghci, I can type :set -lsomethingnonexistent and it doesn't complain

Note that running ghci -lsomethingnonexistent does fail on all platforms. Running :set -lsomethingnonexist in ghci on linux also fails.

comment:21 Changed 15 months ago by Thomas Miedema <thomasmiedema@…>

In a765f72c130111cdbd30f2a3e159186c6e625d2a/ghc:

Testsuite: mark tests as expect_broken on win64

Tickets: #1407, #9381, #9878.

Differential Revision: https://phabricator.haskell.org/D977

comment:22 Changed 15 months ago by archblob

  • Owner set to archblob

I'll do windows build and see what's wrong. The test case we should change to a library guaranteed to be on both plaforms, I thought libdl was, we need something better.

Last edited 15 months ago by archblob (previous) (diff)

comment:23 Changed 12 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.10.3

Moving to 7.10.3, in case we want to investigate this, since it causes some failures.

comment:24 Changed 11 months ago by archblob

I talked with @thomie on #ghc right after the ticked was opened again and the second problem was just a mistake and there is no problem with the patch, but there is indeed a problem with the test. I have looked into it then but I did not find a solution that was guaranteed not to break in the future(I looked for a library that was guaranteed to be present on both systems).

What we could do instead is build one as part of the test and try to load that. If you think that is ok I'll go ahead and make a patch.

comment:25 Changed 11 months ago by thomie

Sounds good to me. See also the other tests in testsuite/tests/ghci/linking/Makefile.

comment:26 Changed 11 months ago by Phyx-

  • Differential Rev(s) changed from Phab:D194 to Phab:D194 Phab:D1310
  • Status changed from new to patch

Hi archblob, This should be covered under Phab:D1310 that I submitted to correct another issue. See test 'ghci_short_name'.

Let me know if this is sufficient for this.

comment:27 Changed 11 months ago by archblob

Hello Phyx, Yes it covers it and I see that you have made it so that the old test still runs on linux. I'm of the opinion that we should also make the linux test against your custom lib so that we don't have any headaches in the future. I can do it, or you can do it after your patch lands, whatever is best for you, just let me know.

comment:28 Changed 11 months ago by Phyx-

I can make the changes that's no problem.

comment:29 Changed 11 months ago by simonmar

  • Status changed from patch to merge

comment:30 Changed 11 months ago by Thomas Miedema <thomasmiedema@…>

In 5d84110/ghc:

Add short library names support to Windows linker

Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
to pass -L to all components by using -B instead. These two fix
shortnames linking on windows.

re-enabled tests: ghcilink003, ghcilink006 and T3333
Added two tests: load_short_name and enabled T1407 on windows.

Reviewed By: thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1310

GHC Trac Issues: #9878, #1407, #1883, #5289

comment:31 Changed 10 months ago by bgamari

  • Resolution set to fixed
  • Status changed from merge to closed

comment:32 Changed 4 months ago by Tamar Christina <tamar@…>

In e6627d1f/ghc:

Fix aggressive cleanup of T1407

Summary:
The aggressive cleanup routine of T1407 is removing files that don't belong to it.
Constrain the test to only removing files it should by putting all it's generated
binaries in it's own output folder.

Test Plan: make test -C testsuite/tests/ghci/linking/dyn

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D2165

GHC Trac Issues: #1407
Note: See TracTickets for help on using tickets.