I wanted to upgrade (Windows Vista) from 4.3.0 (20071017) to the latest stable 4.3.x The Windows installer apparently is for 4.4.0. After installing it, I get the following error when compiling a simple program that worked fine under 4.3.0: gfortran: CreateProcess: No such file or directory Do you have a solution for this, or at least a pointer to the latest stable 4.3.x installer for Vista? Thnx in advance PS: this is a critical problem for me, I build virtally all my applications with gfortran and need to deliver one in the next few days...
IIRC the driver does not relocate correctly under Vista.
Subject: Re: problem running gfortran 4.4.0 in Vista pinskia at gcc dot gnu dot org wrote: > IIRC the driver does not relocate correctly under Vista. The Vista shell seems to populate argv[0] differently than previous versions, so the relocate machinery in the driver can't determine GCC_EXEX_PREFIX. Workarounds are: - use a shell other than CMD.EXE - give the full path to the binary when invoking it from CMD.EXE (even if its in PATH), or write a .bat/.cmd to do as such - add $libexec/gcc/$target/$version dir to PATH
Subject: Re: problem running gfortran 4.4.0 in Vista I used your second option with the batch file as follows: - I renamed gfortran.exe to gfortran4.0.0.exe - I put a one-line batch file gfortran.bat in directory C:\Program Files\gfortran\bin content is: "C:\Program Files\gfortran\bin\gfortran4.4.0" %1 %2 %3 %4 %5 %6 %7 %8 %9 That seems to do the trick for now, and it means I don't have the modify my make files. An obvious limitations is that this allows only for 9 command line parameters. Nevertheless, I think I can live with this for a while until a patch is available, thank you very much. I am very impressed with the bug tracking system, and the team that handles it. I've posted some Vista problems before, which have been dealt with very promptly, resulting in an almost immediate new release. Nevertheless, may I make a few suggestions? - please keep the installers for the previous stable versions available, so that it is possible to regress to a version that worked; on the Wiki pages, only the last version is available, and that usually is an experimental one. Maybe I missed something and older versions are still available somewhere, but then this is not obvious. - Much to my regret and undoubtedly to many others as well, Vista is here to stay; I didn't even have the option to install XP on my new laptop, and XP distribution will cease more or less soon anyway. So I would strongly suggest to perform the same severe testing for Vista as you undoubtedly do for XP. I am trying to convince my international colleagues to switch from g77 to gfortran. Many of them still use g77, even though it is no longer supported or even officially distributed (you wouldn't believe what some of them do to install g77!). However, some large Fortran libraries which were built a decade or so ago for g77, are still very much in use, with very little chance of them ever being updated. I have tried to build one of these from source, with the provided make files, using gfortran, but gave up very quickly after being inundated with errors and warnings. In my experience, one of the main differences is the definition of structures, and the structure syntax (e.g. the use of "%" instead of "."). Is there a way (compiler option or something) to compile old code with old structure definitions, using gfortran, and without replacing them in the source code? Once again, thank you very much for the valuable service you provide, and keep up the good work! Thank you in advance, Daniel Heynderickx brian at dessent dot net wrote: > ------- Comment #2 from brian at dessent dot net 2008-04-13 00:06 ------- > Subject: Re: problem running gfortran 4.4.0 in Vista > > pinskia at gcc dot gnu dot org wrote: > >> IIRC the driver does not relocate correctly under Vista. > > The Vista shell seems to populate argv[0] differently than previous > versions, so the relocate machinery in the driver can't determine > GCC_EXEX_PREFIX. Workarounds are: > > - use a shell other than CMD.EXE > - give the full path to the binary when invoking it from CMD.EXE (even > if its in PATH), or write a .bat/.cmd to do as such > - add $libexec/gcc/$target/$version dir to PATH > >
*** Bug 35958 has been marked as a duplicate of this bug. ***
This will probably only be fixed once a gfortran developer gets access to Vista...
Subject: Re: problem running GCC under Vista with relocated directory As pointed out in <http://gcc.gnu.org/ml/fortran/2008-03/msg00120.html>, config/mh-mingw contains BOOT_CFLAGS += -D__USE_MINGW_ACCESS. Does this setting get applied only when building gcc, or does it apply to target libraries too? Because there are places in libiberty (e.g. make-relative-prefix.c) where access() is called, and so libiberty needs to be built with -D__USE_MINGW_ACCESS if it is to contain the Vista workaround. If the above host fragment only applies to gcc, then I think it will still be necessary to override BOOT_CFLAGS and CFLAGS when invoking make. Brian
Subject: Re: problem running GCC under Vista with relocated directory er, I mean s/target library/host library/
I submitted a patch to MinGW to work around the problem (in crt1.o and crt2.o): http://sourceforge.net/tracker/index.phpfunc=detail&aid=1951037&group_id=2435&atid=302435
*** Bug 36417 has been marked as a duplicate of this bug. ***
Oh this explains why the PS3 toolchain works, we override access in libiberty to and out the the bit.
This fixes for me on Vista host. Can someone confirm? config/ChangeLog PR35916 * mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS. Index: config/mh-mingw =================================================================== --- config/mh-mingw (revision 136350) +++ config/mh-mingw (working copy) @@ -1,3 +1,4 @@ # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows # Vista (see PR33281 for details). BOOT_CFLAGS += -D__USE_MINGW_ACCESS +CFLAGS += -D__USE_MINGW_ACCESS
Subject: Bug 35916 Author: dannysmith Date: Thu Jun 5 03:45:41 2008 New Revision: 136389 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136389 Log: PR driver/35916 * mh-mingw (CFLAGS): Add -D__USE_MINGW_ACCESS. Modified: trunk/config/ChangeLog trunk/config/mh-mingw
Closing, as this is fixed on trunk.