Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#1281 closed bug (fixed)

runghc, runhaskell invoke wrong ghc when not first ghc in PATH

Reported by: Isaac Dupree Owned by: igloo
Priority: normal Milestone: 6.10.1
Component: Compiler Version: 6.6
Keywords: Cc: id@…
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

In the 6.6.1 RC (source code) snapshot 6.6.20070415.
I installed with "./configure --prefix=/home/isaac/install/ghc-6.6.20070415; make; make install"

(at the time of configuring, /home/isaac/install existed but not the subdirectory ghc-6.6.20070415)

I was using the system ghc-6.6 to build it, installed via the ubuntu distro mechanism.

All went well (so far) after make install, except that the runghc and runhaskell executables installed in /home/isaac/install/ghc-6.6.20070415/bin/ invoke the system version of ghc (outputting "ghc-6.6: not built for interactive use", since that is how the ghc in my distro's packages is built) (the rest of the executables, including symlinks, in /home/isaac/install/ghc-6.6.20070415/bin/, are fine)

Change History (16)

comment:1 Changed 7 years ago by Isaac Dupree

  • Reporter changed from Isaac Dupree <id@…> to Isaac Dupree
  • Summary changed from runghc, runhaskell invoke wrong ghc when installed to an unusual prefix to runghc, runhaskell invoke wrong ghc when not first ghc in PATH

Actually, setting PATH="/home/isaac/install/ghc-6.6.20070415/bin/:$PATH" environment makes the runghc work. It also makes /usr/bin/runghc "work", which shouldn't. I guess runghc/runhaskell are inappropriately(?) searching PATH to find their ghc.

comment:2 Changed 7 years ago by igloo

  • Milestone set to 6.8

This is the intended behaviour, but a number of people have been confused by it now. Any objections to changing runghc to run the GHC it is part of?

comment:3 Changed 7 years ago by simonmar

Yes :-)

I don't think it's possible. On Unix runghc would have to be a script, so that we could add the appropriate $bindir at install-time, but you can't invoke a script using the #! syntax. This is why runghc currently just calls whatever GHC is in your PATH.

I suppose we could arrange to build runghc at install-time, but that sounds like a lot of work to get right.

It might make sense to have runghc not search the PATH on Windows, however.

comment:4 Changed 7 years ago by igloo

Invoking a script with #! syntax seems to work for me on Linux. Is it just unportable?

comment:5 Changed 7 years ago by Isaac Dupree

  • Cc id@… added

It's important to me, but fairly easy for me to work around if it's hard to fix ghc's behavior.

An alternate hack under Unix might be for the runghc executable to check its $0 argument and look for a ghc there, or have runghc be a symlink (or hardlink, which is discouraged) to ghc.

comment:6 Changed 6 years ago by simonmar

  • Milestone changed from 6.8 branch to 6.8.3

Todo: look into whether this is possible or not.

comment:7 Changed 6 years ago by igloo

OK, it turns out that it is zsh that handles scripts with a #! pointing at a script. If I try to do it in a bash shell then it doesn't work.
There's more information on http://www.in-ulm.de/~mascheck/various/shebang/, but the gist is that we can't make runhaskell a script (at least, not without requiring users use #!/usr/bin/env runhaskell).

comment:8 follow-up: Changed 6 years ago by igloo

I think symlinks are the best way forward here. Is there a reason we don't use a symlink for ghci?

comment:9 in reply to: ↑ 8 ; follow-up: Changed 6 years ago by simonmar

Replying to igloo:

I think symlinks are the best way forward here. Is there a reason we don't use a symlink for ghci?

No symlinks on Windows, but perhaps we could use symlinks on Un*x. The symlink would have to point to the wrapper script that invokes the GHC binary, so the cleverness might have to be in the script, not GHC itself.

comment:1 in reply to: ↑ 9 Changed 6 years ago by igloo

Replying to simonmar:

Replying to igloo:

I think symlinks are the best way forward here. Is there a reason we don't use a symlink for ghci?

No symlinks on Windows, but perhaps we could use symlinks on Un*x. The symlink would have to point to the wrapper script that invokes the GHC binary, so the cleverness might have to be in the script, not GHC itself.

Oh, right, because we still need to pass the right -B flag. So symlinks won't work for runghc, as the #! line will still point to a script.

So I think that that reduces our options to either leaving things as they are, or requiring that people use #!/usr/bin/env runhaskell if they want to make Haskell scripts.

comment:11 Changed 6 years ago by igloo

  • Milestone changed from 6.8.3 to 6.10 branch

Punting on this.

comment:12 Changed 6 years ago by simonmar

I think it's acceptable to require #!/usr/bin/env.

comment:13 Changed 6 years ago by igloo

  • Milestone changed from 6.10 branch to 6.10.1
  • Owner set to igloo

OK, let's do this then. So runhaskell will become a shell script that calls the GHC that it comes with.

comment:14 Changed 6 years ago by igloo

Fix at the same time as #1232

comment:15 Changed 6 years ago by igloo

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

Fixed by:

Wed Jul 23 19:11:15 BST 2008  Ian Lynagh <igloo@earth.li>
  * runghc now uses the compiler that it comes with; fixes trac #1281
  rather than the first one that it finds on the PATH

comment:16 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.