Mail Archives: djgpp-workers/1998/12/09/05:34:04
On Tue, 8 Dec 1998 snowball3 AT usa DOT net wrote:
> While trying to 'make' the latest weekly binutils snapshot (to test
> the patches I submitted), I came across a minor problem. The
> make stopped with errors in the file libtool . I stumbled on the
> apparent cause of the problem by resaving libtool with editor that
> comes with DOS. It turns out the top portion of the generated
> libtool files contain CR/LFs for the EOL, but the rest of the file uses
> LFs. If I convert the file to either use CR/LFs or LFs, the errors go
> away.
Been there, done that.
The problem is in the ported Bash: it is mightily confused by a script
which has mixed DOS/Unix-style EOL format (but doesn't have any
problems with scripts that consistently use either style). I didn't
have time to look into the Bash sources, but I'd guess it computes the
EOL style at the beginning, by looking at the first few lines, and
then uses that to seek into the script.
I don't know whether this can be solved in Bash. In general, Daisuke
Aoyama (who ported Bash) did an outstanding job, and he usually had a
good reason for anything he did in the ported code. So I'm assuming
this problem has no easy solution in Bash, and we have to live with
it. (However, volunteers are welcome to look into the Bash sources
and try to come up with ideas.)
Under that assumption, a simple solution would be to prevent libtool
from having mixed EOL style in the first place.
libtool is generated by running the ltconfig script, which computes
some variables, writes a prologue for libtool which sets those
variables as appropriate for the target system, and then appends the
fixed part of the script from ltmain.sh. The mixed EOL style is
created because "echo foo >> file" produces a DOS-style EOL, whereas
ltmain.sh is copied with "cat ltmain.sh >> file", and `cat' preserves
the EOL style of the original.
The solution I've chosen in the case where I had this problem was to
run both ltconfig and ltmain.sh through `utod' *before* launching the
configure script, and also to run the created libtool through utod
*after* configure finishes. In my setup, configure script is run by a
batch file anyway, so there's no problem to add a line to that batch
file which runs utod. (If you wonder why did I need to run utod twice,
the answer is paranoia.)
> I've attached the libtool generated in the opcodes directory so you
> can see it for yourselves. The only difference between Oct. 8th and
> today is that I'm using the latest djdev202 package and before I
> was using the alpha.
I can hardly believe this has anything to do with v2.02. Didn't you
say that the previous time you built a different snapshot of Binutils?
I would guess that the internal workings of libtool has changed since
then (or maybe the previous snapshot didn't use libtool at all).
- Raw text -