[Bug 19922] New: Build will not work on a drive mounted in binary mode

[bugzilla-daemon at ecoscentric dot com]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=19922

           Summary: Build will not work on a drive mounted in binary mode
           Product: eCos
           Version: unknown
          Platform: Other
        OS/Version: Other
            Status: UNCONFIRMED
          Severity: normal
          Priority: low
         Component: Other
        AssignedTo: jld at ecoscentric dot com
        ReportedBy: nobody at cygnus dot com


The build system will not generate a usable makefile in the case that the current drive is mounted in binary mode.

How-To-Repeat:
mount -b c: /c
attempt build


---------------------------------------------------------------------------

Originator:
Simon FitzMaurice

Organization:
Cygnus

Audit-Trail:
Responsible-Changed-From-To: alexs->bartv 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Thu Apr 22 12:07:02 PDT 1999 
Responsible-Changed-Why:  
Please look into this bart.

State-Changed-From-To: open-analyzed
State-Changed-By: bartv
State-Changed-When: Fri Apr 23 03:54:34 1999
State-Changed-Why:
This is correct. There are a number of different approaches to
tackling the problem (which will not go away once pkgconf.tcl
disappears, there will still be generated makefiles etc.)

The first approach is to say that mounting drives in binary mode under
cygwin is simply a bad idea. There are far too many programs out there
which are not cygwin aware and hence will not do the right thing when
writing out a file that will later on be accessed via a cygwin binary
mount point. We want to allow people to edit source files etc. using
their favourite editor. There are also issues if e.g. a mount point
changes from text to binary or vice versa.

The second approach is not to ban binary mount points completely but
to make the tools more tolerant. I believe this is already the case
for gcc, if it comes across a carriage return/linefeed pair then it
just ignores the carriage return (the actual rules are more generic, I
believe it is also supposed to cope with Macintosh conventions etc,
but I cannot remember the details). It is probably also true for the
assembler, for the linker when reading in the linker script, and
various other tools that might be involved in builds, but this has not
been tested. It is known that make is not currently tolerant of
spurious carriage returns, hence the build failures reported in this
PR.

There was actually some discussion in the GnuMake mailing list about
this issue a while back, and there seemed to be a consensus that
ignoring spurious carriage returns was ok (although there were worries
that this might break some existing makefiles in extreme conditions).
The change may even have been made in the current snapshot releases of
GnuMake. However make is not maintained by Cygnus, the current
maintainer is Paul Smith at Bay Networks, so we have less control over
this tool than over the others.

So we could make or import the necessary changes into our copy of the
GnuMake sources and contribute them back to the FSF. Of course this
would only help people who use a subsequent release of cygwin, and I
do not know what the release schedules are for that. 

A third approach is to fix the problem at the Tcl interpreter level.
The makefiles that cause the build problems are either generated by
pkgconf.tcl or they are copied across by pkgconf.tcl. Currently
cygtclsh80 is not aware of cygwin mount points etc. This has caused
problems because of pathnames (pkgconf.tcl actually has to translate
between cygwin and Windows pathnames in various places, and the
current code is not 100% robust.) If cygtclsh80 became fully cygwin
aware then the pathname problems would go away, and as a useful side
effect binary mount points would work correctly as well. The cygwin
team has shown little inclination to do this work, and even if the
work were done there would have to be synchronization with Scriptics
to avoid excessive divergence with the master Tcl source base.

This third approach would not be guaranteed to eliminate problems: it
is still possible for an end user to load a makefile into a
non-cygwin-aware editor and save it in the wrong format, but we could
claim that that was a user error.

A fourth approach would be to tackle the problem at the pkgconf.tcl
and libcdl levels. This means detecting when a makefile will end up
being accessed via a binary mount point and using either
fopen( ..., "wb") or fconfigure -translation binary. Detecting a
binary mount point is non-trivial, it might involve either a cygwin
call (which means linking the config tool with cygwin, probably
non-trivial), or parsing the output of the mount command. This
approach would not be tolerant of user changes either.

IMO the second approach is the most sensible long-term solution, but
needs to be discussed with at least the cygwin team first. The work
involved is probably fairly small, although the GnuMake sources are
not renowned for being particularly clean.

State-Changed-From-To: analyzed-analyzed
State-Changed-By: bartv
State-Changed-When: Tue Apr 27 09:05:51 1999
State-Changed-Why:
It appears that a change has already gone into the FSF sources.

1999-03-31  Paul D. Smith  <psmith at gnu dot org>

	* read.c (readline): Ignore carriage returns at the end of the
	line, to allow Windows-y CRLF line terminators.

Index: read.c
===================================================================
RCS file: /gd/gnu/anoncvsroot/make/read.c,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -5 -r1.87 -r1.88
--- read.c      1999/03/05 05:55:32     1.87
+++ read.c      1999/03/31 23:25:16     1.88
@@ -2127,10 +2127,21 @@
          continue;
        }

       ++nlines;

+#if !defined(WINDOWS32) && !defined(__MSDOS__)
+      /* Check to see if the line was really ended with CRLF; if so ignore
+         the CR.  */
+      if (len > 1 && p[-2] == '\r')
+        {
+          --len;
+          --p;
+          p[-1] = '\n';
+        }
+#endif
+
       if (len == 1 && p > buffer)
        /* P is pointing at a newline and it's the beginning of
           the buffer returned by the last fgets call.  However,
           it is not necessarily the beginning of a line if P is
           pointing past the beginning of the holding buffer.


However I am not sure that the change is correct for cygwin.
Specifically, is WINDOWS32 defined for cygwin apps?

I suggest this PR be reassigned to the cygwin team. They have more
experience sorting out merge issues like this.


Responsible-Changed-From-To: bartv->cgf 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Tue Apr 27 09:43:22 PDT 1999 
Responsible-Changed-Why:  
Hi Chris 

This is a problem which we encountered in the eCos QA on NT. 
It appears to be a cygwin issue. 

-- Alex 

Responsible-Changed-From-To: cgf->alexs 
Responsible-Changed-By: cgf 
Responsible-Changed-When: Tue Apr 27 10:45:14 PDT 1999 
Responsible-Changed-Why:  
Why did the state change? (Ctrl-D to end) 
Please feel free to make the change suggested in the PR. 
Note that this will just fix one part of the entire build 
process.  Other tools like sed and grep may not necessarily 
work correctly when they encounter a rn pair.  Textmode mounts 
were invented to allow utilities like this to work correctly. 

Responsible-Changed-From-To: alexs->bartv 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Tue Apr 27 10:55:46 PDT 1999 
Responsible-Changed-Why:  
Hi Bart 

It seems Chris has given the OK to make the changes ourselves. 
Please go ahead and do so. They will need to go into devo 
as well as be submitted for 99r1 if we can still do this. 

Have fun 
-- Alex

Unformatted:
Originator:  

page: www.cygnus.com/product/ecc-pr.html

Send_PR_form: Sent_from_www.cygnus.com

------- Additional Comments From alexs at ecoscentric dot com  2003-24-04 17:05 BST -------
Issue may be resolved?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.