[ ghc-Bugs-1016120 ] Fails silently if preprocessor not found

Bugs item #1016120, was opened at 2004-08-25 16:35
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1016120&group_id=8032
Category: Compiler
Group: 6.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Schoinobates Volans (schoinobates)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails silently if preprocessor not found
Initial Comment:
When using a package that asks ghc to run a
preprocessor on the source, if the execution of the
preprocessor fails (e.g. because the latter is not
installed on the system or not in the PATH), ghc fails
silently. It should write an error message to stderr,
something like "execution of preprocessor 'foo' failed:
No such file or directory".
I encountered this with Wash, version WashNGo-2.0.3:
http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/
----------------------------------------------------------------------
>Comment By: Simon Marlow (simonmar)
Date: 2004-09-01 09:55

[ ghc-Bugs-1015205 ] ghc-split fails to quote path when used as regex

Bugs item #1015205, was opened at 2004-08-24 12:41
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1015205&group_id=8032
Category: Driver
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Peter Strand (pstrand)
>Assigned to: Simon Marlow (simonmar)
Summary: ghc-split fails to quote path when used as regex
Initial Comment:
If the second argument to ghc/driver/split/ghc-split
contains
a backslash and a 'p', for example ...\pe..., the
script fails with an error message:
Can't find unicode character property definition via
main->e or e.pl at unicode/Is/e.pl line 0
The problem can be solved by a
$Tmp_prefix =~ s/\/\\/g;
before it is used as a regexp around line 50 in ghc-split.
----------------------------------------------------------------------
>Comment By: Simon Marlow (simonmar)

Interestingly, I first thought this problem was related to the long
"readline story", since the build process complained about
"readline" when it failed. But that turned out not to be the case!
The subject of the mail reflects this, hopefully making this mail
easier to find should someone face similar problems.
Background:
I'm trying to build GHC 6.2.1 on a Fedora Core 2 (FC2) Linux box.
The reason is that ghci from the available binary releases (the RH9 rpm
and the generic Linux version for glibc 2.3) segfaults.
However, the compiler itself seems to run fine, so I decided to try to
build and install a system from sources, using the GHC compiler from
the generic binary release.
Problem:
After a long time with a lot of activity, the build process halts
with the following error:
/home/henrik/ghc-6.2.1/libraries/readline/libHSreadline.a:
could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
<<ghc: 3845976 bytes, 2 GCs, 129524/129524 avg/max bytes residency
(1 samples), 5M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (3.80
elapsed),
0.00 GC (0.00 elapsed) :ghc>>
It turns out that "libHSreadline.a" actually isn't an archive at all:

PS:
A small clarification, in case someone needs a step-by-step
guide for recovering from a partially failed build.
I just wrote:
> Changing this to
>
> ArSupportsInput =
>
> allows "libHSreadline.a" to be built correctly, using a different
> way of passing the desired file name arguments to "ar".
Of course, it isn't just "libHSreadline.a" that does not get generated
correctly. So, in order to complete the build, I did a "make clean"
in the "library" subdirectory, and then restarted make from the top
level. That worked, as far as I know.
/Henrik
--
--
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
nhn <at> cs.nott.ac.uk
This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks. Email communications with the

On 01 September 2004 17:20, Henrik Nilsson wrote:
> So, in summary, there were two problems:
>
> * The configuration tools somehow thinks the system's "ar"
> supports "-input".
> * The build system fails to detect when "ar" failed in the first
> place.
Indeed, I think these two are probably related. It looks like your 'ar'
doesn't emit a non-zero exit code when given the -input option, so
neither the configure script nor the build system detected that it had
in fact failed.
Could someone with one of these offending ar's please hack up a fix to
the configure script? Maybe just grepping for the error message in the
output of ar would be sufficient.
Cheers,
Simon