Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1141 make 3.8x fails to compile files.S

OTHER
closed
Cesar Strauss
make (27)
fixed
Known_bugs
2014-08-18
2008-03-29
Paulo Lopes
No

Hello all,

I've been trying to compile some asm files and mingw32-make 3.80, 3.81 and even the latest snapshot seem to be buggy when in my project i have files with .S extension.

I think that .s is an ASM code file that doesn't support pre processor and .S an ASM that supports it. Having this for base I create a file named main.S file and a simple Makefile like this:

CFLAGS = -Wall
CXXFLAGS = $(CFLAGS)
ASFLAGS = $(CFLAGS)

all: main.o

with the faulty versions 3.80, 3.81 and snapshot, I get an error on GCC trying to assemble main.s (make fails to identify the right case) which fails because my main.S uses some preprocessing directives. 3.71 works fine and identifies as main.S and compiles ok!

To sum up:

mingw32-make 3.8x assumes all files .S are .s which leads to compilation errors

mingw32-make 3.79 was good with it!

Discussion

  • Keith Marshall
    Keith Marshall
    2008-04-21

    Logged In: YES
    user_id=823908
    Originator: NO

    How do you expect to discriminate between `*.S' and `*.s' files, on a case insensitive file system? IIRC, all versions of mingw32-make honour the case insensitive property of the Win32 file system, and consider *all* file and goal names as if stated in lower case *only*, (which seems inconsistent with your assertion that mingw32-make-3.79 was good with it; perhaps you are comparing mingw32-make-3.8x with *MSYS* make-3.79)?

    If you can't choose some alternative extension to discriminate these file types, then you cannot use mingw32-make. You can, however, use MSYS. Versions of MSYS `make' prior to make-3.81 exploited the case preserving property of the Win32 file system, to pretend case sensitivity. From MSYS make-3.81 onward, this pretence has been dropped from the default build, but continues to be offered in the guise of csmake-3.81, for those who wish, (or need), to preserve the fiction.

     
  • Keith Marshall
    Keith Marshall
    2008-04-21

    • milestone: --> Known_Feature
    • status: open --> closed-invalid
     
  • Earnie Boyd
    Earnie Boyd
    2008-04-21

    Logged In: YES
    user_id=15438
    Originator: NO

    mingw32-make-3.79 allowed case sensitive name patterns. After all even though the FS is case insensitive it is case preserving and allows case sensitive patterns within make to work properly.

    mingw32-make-3.81 has the case insensitive name patterns compile time switch enabled. Paulo will need to rebuild the make from source without the switch. I myself consider this an issue since case preserved FS names should IMO be case sensitive matched in the make process.

     
  • Earnie Boyd
    Earnie Boyd
    2008-04-21

    Logged In: YES
    user_id=15438
    Originator: NO

    BTW, this issue prevents mingw32-make from building the mingw runtime. Do we really want that? I've reopened the issue to continue discussion.

     
  • Earnie Boyd
    Earnie Boyd
    2008-04-21

    • status: closed-invalid --> open-invalid
     
  • Paulo Lopes
    Paulo Lopes
    2008-04-22

    Logged In: YES
    user_id=242158
    Originator: YES

    I only use NTFS as my filesystem under windows, I know that code like: open("C:\\windows\\explorer.exe") will open the same file as: open("C:\\WINDOWS\\EXPLORER.EXE") however if a do a dir list i see that the files and directories have case sensitive names:

    C:\WINDOWS>dir explorer.exe
    Directory of C:\WINDOWS

    06/13/2007 12:23 1,033,216 explorer.exe
    1 File(s) 1,033,216 bytes
    C:\WINDOWS>

    What I think it should be the right behavior is to read the file/directory name and preserve the case from the underlying OS layer. Because if write a small program like:

    // enum_files.cpp
    // compile with: /clr
    using namespace System;
    using namespace System::IO;

    int main()
    {
    String^ folder = "C:\\";
    array<String^>^ dir = Directory::GetDirectories( folder );
    Console::WriteLine("--== Directories inside '{0}' ==--", folder);
    for (int i=0; i<dir->Length; i++)
    Console::WriteLine(dir[i]);

    array<String^>^ file = Directory::GetFiles( folder );
    Console::WriteLine("--== Files inside '{0}' ==--", folder);
    for (int i=0; i<file->Length; i++)
    Console::WriteLine(file[i]);

    return 0;
    }

    This prints the files with their creation case sensible names.

    Now, If you say this breaks the build of mingw then it is another story, in that case I think i can live by building my make with the special flag that turns on case sensitiveness.

     
  • Wu Yongwei
    Wu Yongwei
    2008-04-22

    Logged In: YES
    user_id=399758
    Originator: NO

    Keith, you said, "all versions of mingw32-make honour the case insensitive property of the Win32 file system".

    We have discussed on this topic some time ago and in length, so *I* do not want to repeat the arguments. Checking that thread again, I found that you also thought that only the MSYS version of Make 3.79 is case-sensitive. This is not true. I used *MinGW* Make 3.79 then, and I know that it is case-sensitive, thus my original report on the difference.

     
  • Keith Marshall
    Keith Marshall
    2008-05-01

    Logged In: YES
    user_id=823908
    Originator: NO

    Quoting Earnie:
    > this issue prevents mingw32-make from building the mingw runtime.

    If this is true--and I've no reason to doubt you--then that would indicate a bug in the Makefiles for the runtime; we should fix that.

    > Do we really want that?

    No, but neither do we want to cripple an otherwise correctly functioning tool, just to support improper rule definition in a Makefile. Fix the broken Makefile; please, don't break the tool.

    In any case, don't we need MSYS anyway, (or Cygwin, perhaps), to build the runtime? Chris hasn't complained, to my knowledge, that MSYS's case insensitive make-3.81 is unable to build it; why should mingw32-make-3.81 behave any differently?

    Quoting Yongwei:
    > Keith, you said, "all versions of mingw32-make honour the
    > case insensitive property of the Win32 file system".

    I also said "if I recall correctly"; it's possible that my recollection, or my perception of the situation in the days of mingw32-make-3.79, may be hazy.

    > I used *MinGW* Make 3.79 then, and I know that it is
    > case-sensitive

    My own experience would suggest otherwise--mingw32-make-3.79 could correctly resolve pattern rules in a large legacy makefile system, ported from DJGPP, where the rules *demanded* case *insensitive* treatment; MSYS make-3.79, with its case *sensitive* behaviour, was an abject failure in this situation.

    It is possible that mingw32-make-3.79 was built with local patches, which gave it some form of hybrid behaviour wrt case-sensitivity. I don't know if that's the case, but the current mingw32-make-3.81 is built from stock FSF sources, and is free from local patches; this is a maintenance objective which I am keen to preserve.

     
  • Earnie Boyd
    Earnie Boyd
    2008-05-02

    Logged In: YES
    user_id=15438
    Originator: NO

    It is not a but that as.exe treats a capital .S as something special. It is a documented feature of the assembler. You want to ignore the case preserving aspect of windows because you have a legacy system that needs the case insensitiveness of the file system. I think forcing make patterns to be case insensitive by making them lower case is wrong and is the bug.

    You stated that every pattern is converted to lower case. If it does this then the compile file.S becomes file.s and that is just wrong and there is then a bug in the tools that convert the filenames to lower case. There isn't any reason why the windows versions of make should rely on the case insensitiveness of the file system when the file system is case preserving which allows for special treatment of files contain an extension of a capital name. This is something the MinGW GCC can and does support.

     
  • Keith Marshall
    Keith Marshall
    2008-05-03

    Logged In: YES
    user_id=823908
    Originator: NO

    > It is not a but [sic] that as.exe treats a capital .S as
    > something special. It is a documented feature of the assembler.

    It *is* a bug, not in the sense that `gas' does not behave as documented, for it clearly does, but in the sense that `gas' itself is deficient in either design or in documentation. To clarify this statement, let's briefly forget about MS-Windows, and POSIX or Unix, and consider another operating system which GCC, (and by association, `gas'), purports to accommodate: OpenVMS.

    Now, OpenVMS is an operating system which you either love, or you hate, and I will freely confess to having no love for it, but it does have one property which is relevant: its file system is unequivocally case-insensitive, and is unencumbered by the case-retentive nonsense which has been the cause of so much discord here. In fact, directories on an OpenVMS file system record file names exclusively in upper case, with no mechanism for identifying the original case specified by the user, (or process), at the time of file creation. Thus, there can be no mechanism to discriminate between `foo.s' and `foo.S', for neither of these can ever exist; there can only ever be `FOO.S'.

    So, given this property, if `gas' behaves exclusively as documented, how does it determine the user's intent for `FOO.S'? Should it treat it as being the equivalent of `foo.s', or of `foo.S'? The simple answer is that it cannot possibly decide, unless it has some other less well documented, or possibly undocumented, feature which conveys the information.

    On reflection, exactly the same situation exists on MS-DOS, where with DPMI and DJGPP, `gas' is also supported. This is another system which records file names exclusively in upper case, in its directories. Therefore, `gas' must have exactly the same limitations on MS-DOS, in respect of `foo.s' vs. `foo.S' discrimination, as it does on OpenVMS. The design of `gas' simply *must* support some mechanism other than case distinction in the file name suffix, to control this behaviour, otherwise this particular aspect of `gas' behaviour must be definitively broken on these platforms.

    > You want to ignore the case preserving aspect of windows
    > because you have a legacy system that needs the case
    > insensitiveness [sic] of the file system.

    No, I don't. While it is true that experience of the legacy system may have influenced my deliberation, I want to have `make' honour its case-insensitive-file-system paradigm, because I firmly believe that it is the better choice for a majority of users.

    > I think forcing make patterns to be case insensitive by
    > making them lower case is wrong and is the bug.

    And I respectfully disagree. IMO, project maintainers introduce bugs by failing to write their Makefiles in a format which honours the least common denominator of the case sensitivity of the file systems on which they wish to build. Since MS-Windows' file system is fundamentally case-insensitive, (ignoring the case-retentive property for now; I will come back to it later), case-insensitive should be the norm, for development on MS-Windows.

    However, this bigoted `I'm right, and you are wired up to the moon' repetition of irreconcilable opinions serves no useful purpose whatsoever; we need to discard the dogma, put past differences behind us, and start to discuss this issue rationally and objectively.

    I base my assessment that the case-insensitive pattern matching variant of `make' is the better choice for the majority of users on the relative difficulty, (nigh impossible), of overcoming the potential problems introduced by *not* having that variant, as compared to the minimal difficulty of writing Makefiles which will behave correctly with *either* variant. That isn't an `I want it this way, so that's how it must be' choice; it is an objective assessment of what I believe will be the better choice for a majority of users.

    However, there *is* a problem in `gas', which apparently requires a Makefile to incorporate independent rules which are distinguishable only by the case of two otherwise identical file name suffixes. I say `apparently' because we have yet to identify how this is handled by an OpenVMS or MS-DOS implementation of `gas', and to determine if the mechanism employed in those cases could also be applicable for MS-Windows. Even if such a capability isn't available, the bug is *not* in the case-insensitive behaviour of `make'; the bug is rather a deficiency in `gas'. You say that the solution is to dispense with the case-insensitive variant of `make', and promote the case-sensitive variant in its stead. It is not. While that may be an effective workaround for this particular problem, (and I agree that some such workaround may be necessary in the short term), it is merely faffing with the consequences of the bug, rather than tackling it head on, and fixing the *real* underlying problem.

    Now, to come back to the case-retentive property of the MS-Windows file system. IMO, this is not as useful as you would have us believe; indeed, it may actually be harmful, if we allow ourselves to be deluded into the belief that it allows us to pretend that `case-retentive == case-sensitive', for that equality is most definitely untrue. However, that caveat aside, it is not entirely devoid of advantage, and since it is a property of the file system, we must consider its impact on this issue; unfortunately, GNU `make' does not do so, or at best does not do so adequately, in its design.

    Having said that, I am led to the conclusion, which is possibly controversial, that neither of us is right. You are wrong, because you favour a variant of `make' which utterly ignores the fundamentally overriding case-insensitive property of the file system. I am also wrong, because in choosing a `make' which does honour this property, I overlook the impact of the case-retentive property, albeit because I am forced to do so.

    So, if neither of us is right, where does the right solution lie? Well, somewhere between the two extremes, probably, with a bias toward the case-insensitive state, I think. Unfortunately, this doesn't help us much in the short term, because we've now identified two fundamental issues, neither of which is within our purview to resolve:--

    1) Just as GCC can differentiate C from C++ on the basis of `foo.c' vs. `foo.C', but also on the basis of `foo.cpp', or any of several other multi-character suffixes for C++, which facilitates avoidance of the ambiguity of the single character suffix on case-insensitive file systems, `gas' *needs* an unambiguous mechanism to similarly differentiate `foo.s' and `foo.S' on such systems. This should not be difficult for the binutils maintainers to implement, if indeed it doesn't already exist, in which case it needs to be properly documented; however, we must apprise them of the issue, to facilitate the solution.

    2) The present behaviour of GNU `make' seems to be too much `black and white' WRT case sensitivity in the file system; it either views everything as case-sensitive, or as case-insensitive, with no consideration for the possibility of a `middle ground'. I don't know how best to improve this behaviour, but some possibilities which may merit consideration:--

    2a) Dispense with the present philosophy of an either/or configuration, selected at build time; support *both* case-sensitive and case-insensitive behaviour integrally, within a single build, with a command line switch, to select the effective behaviour for a particular invocation of `make', or a new special pseudo-target to select it for processing of any particular Makefile.

    2b) Extend the special pseudo-target concept of (2a), to specify individual targets as requiring case-sensitive treatment, or otherwise.

    2c) Consider *all* targets as fundamentally case-insensitive, but first attempt to resolve them as case-sensitive, falling back to the case-insensitive behaviour only if the case-sensitive match remains unresolved.

    2d) Implement (2c) but suppress the fall back to case-insensitive matching for any target which is expressed in mixed case; thus only targets expressed in mono-case, (either upper or lower), would be subject to case-insensitive matching.

    2e) Extend the concept of (2d), such that only one of the two possible mono-case expressions of a target, (say lower-case only), becomes subject to case-insensitive matching.

    Again, it would not be for us to implement such a solution, and this discussion would be better taken to the GNU `make' mailing list, for it to have any useful impact.

    Of course, neither of the above suggestions for ultimate solutions will help with this particular problem, in the short term. Thus, we do need to retain the current compromise of providing two distinct flavours of `make'. We already have this for MSYS; perhaps we should do likewise for mingw32-make. I remain convinced that the case-insensitive variant is the better all round choice; anyone who disagrees with me is free to rename the `csmake' variant as their prefered default. Makefile authors should be educated, to avoid reliance on case-sensitive pattern matching, since it is generally unsafe; in rare cases where it is impossible to avoid, (as it appears in the case of this bug), then the `csmake' variant should be used.

     
  • Cesar Strauss
    Cesar Strauss
    2008-05-11

    Logged In: YES
    user_id=1369729
    Originator: NO

    Keith wrote:

    > 2c) Consider *all* targets as fundamentally case-insensitive, but first
    > attempt to resolve them as case-sensitive, falling back to the
    > case-insensitive behaviour only if the case-sensitive match remains
    > unresolved.

    This seems like a good compromise and would cover most use-cases of MSYS.

    I examined make's source code and I think I may be able to implement such a solution. If so, I could upload it as "cpmake" (case-preserving make) and it could eventually be the default for MSYS, if it is agreed. These changes could be submitted upstream, as they would not be specific for MSYS.

    Regards,
    Cesar

     
  • Earnie Boyd
    Earnie Boyd
    2008-05-12

    Logged In: YES
    user_id=15438
    Originator: NO

    Cesar wrote:

    > I examined make's source code and I think I may be able to implement such
    > a solution. If so, I could upload it as "cpmake" (case-preserving make) and
    > it could eventually be the default for MSYS, if it is agreed. These changes
    > could be submitted upstream, as they would not be specific for MSYS.

    I like this idea. The make-w32@gnu.org list can help with discussing and even testing the patch.

    Earnie

     
  • Earnie Boyd
    Earnie Boyd
    2013-02-04

    Cesar, did this ever get resolved?

     
    • Cesar Strauss
      Cesar Strauss
      2013-02-04

      Yes. I implemented a local patch in msys make that does exactly this:

      2c) Consider all targets as fundamentally case-insensitive, but first
      attempt to resolve them as case-sensitive, falling back to the
      case-insensitive behaviour only if the case-sensitive match remains
      unresolved.

       
  • Earnie Boyd
    Earnie Boyd
    2013-02-04

    • labels: MinGW --> make
    • status: open-invalid --> pending
    • assigned_to: Cesar Strauss
    • resolution: --> later
    • category: --> Known_bugs
    • milestone: Known_Feature --> OTHER
     
  • Cesar Strauss
    Cesar Strauss
    2013-02-04

    • status: pending --> closed
    • resolution: later --> fixed