0004940: Problem with end-on-line convention on bytecomp/bytelink.ml

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004940

OCaml

OCaml general

public

2009-12-14 18:02

2009-12-30 16:40

Reporter

frisch

Assigned To

doligez

Priority

normal

Severity

minor

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

Fixed in Version

3.12.0+dev

Summary

0004940: Problem with end-on-line convention on bytecomp/bytelink.ml

Description

When using "ocamlc -output-obj" with a recent version of OCaml compiled from the branch version/3.11 of the SVN, using the Win32 MSVC port, I get errors like:

csml_bytecode.c : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format
File "_none_", line 1, characters 0-1:
Error: Error while building custom runtime system

The culprit is very probably some non-Unix end-of-lines in the file bytelink.ml, in parts that generate literal C code. Applying the dos2unix tool to bytelink.ml solves the problem.

Possible fixes:
- do not use Mac end-of-lines for OCaml sources;
or:
- do not insert end-of-lines in literal strings (instead, terminate lines with \n\).

Btw, we also have to apply dos2unix to the file VERSION to be able to compile OCaml (but this is not new).

FWIW, we use the "DOS / text" install mode of Cygwin, not the "Unix / binary" mode.

Tags

No tags attached.

Attached Files

Relationships

Notes
(0005209) doligez (manager) 2009-12-28 14:19	We do not use Mac end-of-lines for OCaml sources. In fact, there isn't a single occurrence of CR in the whole source tree. What probably happens is this: - there are end-of-lines in literal strings - they are translated by your Cygwin into CR-LF when OCaml reads and compiles the source, so the string contains CR-LF - when the compiler outputs them as CR-LF, your cygwin again translates the LF into CR-LF, resulting in CR-CR-LF in the output file. The short-term solution is to terminate the lines of bytelink.ml with \n\, the long-term solution is to do that for all compiler source files, and to add a warning for naked end-of-lines in string constants. We have made the change to bytelink.ml for 3.11.2+rc1, we'll do the rest for 3.12.

(0005214) doligez (manager) 2009-12-30 16:40	added the warning and escaped all end-of-lines in strings (in the trunk)

Issue History
Date Modified	Username	Field	Change
2009-12-14 18:02	frisch	New Issue
2009-12-28 14:19	doligez	Note Added: 0005209
2009-12-28 14:19	doligez	Assigned To	=> doligez
2009-12-28 14:19	doligez	Status	new => acknowledged
2009-12-30 16:40	doligez	Note Added: 0005214
2009-12-30 16:40	doligez	Status	acknowledged => closed
2009-12-30 16:40	doligez	Resolution	open => fixed
2009-12-30 16:40	doligez	Fixed in Version	=> 3.12.0+dev