Opened 10 years ago

Closed 19 months ago

Last modified 13 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 3 years ago.
fix_T1407.patch (3.7 KB) - added by archblob 3 years ago.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 10 years ago by igloo

Milestone: 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 10 years ago by simonmar

difficulty: UnknownEasy (1 hr)
Milestone: 6.8 branch6.10 branch

comment:3 Changed 9 years ago by igloo

See also #2365

comment:4 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:5 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:6 Changed 8 years ago by igloo

Milestone: 6.10 branch_|_

comment:7 Changed 8 years ago by simonmar

difficulty: Easy (1 hr)Easy (less than 1 hour)

comment:8 Changed 4 years ago by mf825

Type of failure: 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 4 years ago by igloo

Owner: igloo deleted

comment:12 Changed 3 years ago by archblob

Cc: hvr added
Status: newpatch

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 3 years ago by archblob

Owner: set to archblob

Changed 3 years ago by archblob

Attachment: fix_1407.patch added

comment:14 Changed 3 years ago by archblob

Milestone: 7.10.1

comment:15 Changed 3 years ago by thoughtpolice

Status: patchinfoneeded

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

Changed 3 years ago by archblob

Attachment: fix_T1407.patch added

comment:16 Changed 3 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 3 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 3 years ago by thoughtpolice

Resolution: fixed
Status: infoneededclosed

Merged, thanks!

comment:19 Changed 3 years ago by thoughtpolice

Differential Rev(s): Phab:D194

comment:20 Changed 2 years ago by thomie

Operating System: Unknown/MultipleWindows
Owner: archblob deleted
Resolution: fixed
Status: closednew

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 2 years 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 2 years 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 2 years ago by archblob (previous) (diff)

comment:23 Changed 21 months ago by thoughtpolice

Milestone: 7.10.17.10.3

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

comment:24 Changed 20 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 20 months ago by thomie

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

comment:26 Changed 20 months ago by Phyx-

Differential Rev(s): Phab:D194Phab:D194 Phab:D1310
Status: newpatch

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 20 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 20 months ago by Phyx-

I can make the changes that's no problem.

comment:29 Changed 20 months ago by simonmar

Status: patchmerge

comment:30 Changed 20 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 19 months ago by bgamari

Resolution: fixed
Status: mergeclosed

comment:32 Changed 13 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.