#8 tune/blas/ger/Makefile exe copy


on cygwin-1.7.0-62 the following "if / cp"
is giving fault as when xccobj.exe exists both the tests
are true and the second cp fails.

if [ -s "xccobj" ]; then \ cp -f xccobj $(GR1dir)/. ; \ fi
if [ -s "xccobj.exe" ] ; then \ cp -f xccobj.exe $(GR1dir)/. ; \ fi
on other makefiles this solution is instead used,

-@ cp -f xccobj $(GR1dir)/.
-@ cp -f xccobj.exe $(GR1dir)/.

and this work fine.
Unfortunately I have no clue from where this Makefile is
coming from, so I can not provide a source patch.



  • Anonymous - 2009-10-21

    I attach my own patch "cp_workaround.patch".

  • Anonymous - 2009-10-21

    Sorry, I failed to attach a patch.

    Makefile's are in ATLAS/makes/.

    I don't prefer the solution that you suggested, because the code doesn't show why it goes fine.

    I modify Make.mmtune, Make.mvtune and Make.r1tune as follows:

    if [ -s "xccobj.exe" ] ; then \ cp -f xccobj.exe $(GR1dir)/. ; \ else \ cp -f xccobj $(GR1dir)/. ; \ fi

  • R. Clint Whaley

    R. Clint Whaley - 2009-10-21
    • milestone: --> developer
  • R. Clint Whaley

    R. Clint Whaley - 2009-10-21


    The reason for this change (from possibly failing cp to the ifs) is that users have been griping about all the error messages that come from the ATLAS install failing to do things that are not legal/needed on their platform. The if was my way of trying to eliminate one source of these "spurious" error messages.

    Can someone explain to me why the second copy would fail? If the file exists, why can't I copy it? If one were going to fail, I would expect the first one to do so (cygwin fillls in the .exe on the query, but not the copy). sf1021's fix suggests to me it is the non-exe copy that is failing . . .


  • R. Clint Whaley

    R. Clint Whaley - 2009-10-21
    • assigned_to: nobody --> rwhaley
  • Anonymous - 2009-10-21

    I'm not familiar with inside cygwin. So, I don't know the exact reason.

    On cygwin, "foo.exe" can be accessed by both "foo.exe" and "foo".
    I think that there may be a trick in accessing exe files and it causes the problem.

    The problem can be reproduced by following sequence:

    mkdir bar
    touch foo.exe

    cp foo bar/ # Succeed (bar/foo [not foo.exe] is created.)
    cp foo.exe bar/ # Succeed (bar/foo.exe is created.)
    cp foo bar/ # Fail
    # cp: cannot create regular file `bar/foo': File exists)

    I found that "cp foo bar/" fails if "bar/foo.exe" exists.
    (The existence of "bar/foo" has no relation to this problem.)
    In this case, cp try to copy "foo" to "bar/foo", but "bar/foo.exe" can also be accessed by "bar/foo" on cygwin. This makes the situation complicated.

  • marco atzeri

    marco atzeri - 2009-10-21

    sf1021 is right. There is a regression on latest cygwin binutils that makes

    $ if [ -s xccobj ]; then cp xccobj prova ; fi
    cp: cannot create regular file `prova': File exists

    fail when prova.exe exists.
    This bug does not exist in cygwin-1.5.

    Attached the patch/workaround using the other style "-@ cp ..."

    The usual solution to meet your target is to define a EXEEXT=".exe" for windows and
    empty for unix and use somthing like

    if [ -s xccobj$EXEEXT ]; then cp xccobj$EXEEXT provaEXEEXT ; fi


  • R. Clint Whaley

    R. Clint Whaley - 2009-11-16

    Can someone tell me if this still happens in 3.9.17? I applied at least some fixes, but I'm not sure I got them all.


  • R. Clint Whaley

    R. Clint Whaley - 2009-11-16
    • status: open --> open-accepted
  • Anonymous - 2009-11-30

    It works. Thank you.

    However, There remains "-@ cp ..." style workarounds.
    Line 1415 in Make.mmtune
    Line 782 in Make.mvtune
    Line 527 in Make.r1tune

    How about unifying the way into "if ~ then ~ else ~" style?

  • R. Clint Whaley

    R. Clint Whaley - 2009-12-08


    Can you verify that the lines you mention actually cause things to die? It seems to me that if one of hte copies work, the other will just not do anything, but things won't die since the Makefile ignores the error condition on the copy, and the only thing we care about is that the file is copied. I changed only the lines that were actually dying (tried to, anyway).


  • Anonymous - 2009-12-11

    Hi Clint,

    The present makefiles work fine as you explained.

    My previous comment is just a proposal. In the current makefiles, two ways exist for one probrem (cygwin's cp problem). I think "one way for one problem" is good for increasing maintainability. You can do:
    (1) reject my proposal.
    (2) unify the ways into "-@ cp ..." style.
    (3) unify the ways into "if ... then ... else ..." style.

    Again, the present makefiles work as expected and the bug was fixed. I'm sorry for confusion.

    Thank you,

  • R. Clint Whaley

    R. Clint Whaley - 2012-06-13


    I am very sorry for the looong delay, but I think I have gotten Windows fully supported in ATLAS 3.9.79. Using it, you can build 32-bit libs using either the cygwin compilers or the MinGW compilers, though you still need cygwin installed. The ATLAS installation guide that comes with the tarfile has Windows-specific installation instructions.

    Can you try 3.9.79 and let me know if it works for you?

    Many thanks,

  • R. Clint Whaley

    R. Clint Whaley - 2012-06-13
    • status: open-accepted --> closed-fixed
  • R. Clint Whaley

    R. Clint Whaley - 2012-06-13

    This seems to have been fixed, in that my Windows installs work. Reopen this if you experience the same problem with the newest ATLAS and cygwin, and open up a new tracker item if you have a different problem.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks