Re: gcc4/gfortran
On Thu, 4 Dec 2008 14:35:02 -0500, Gustavo Seabra [EMAIL PROTECTED] wrote: On Wed, Dec 3, 2008 at 8:36 PM, Eric Blake wrote: According to Gustavo Seabra on 12/3/2008 7:38 AM: 1. Is is safe to remove the old gcc (3.*) packages and replace them by symlinks to the new gcc4 executables? Read the archives. Dave has mentioned that he is planning on a future packaging of the gcc packages that use the alternatives package, so that the symlink management of the name gcc can be done automatically to point to either gcc-3 or gcc-4. But at the moment, I'm not sure whether the gcc-4 package requires files provided by the gcc package, in which case blindly deleting all thing gcc 3.* might break gcc-4. Got it. But I was actually just planning on removing the gcc and g77 executables, and make those names point to gcc4 executables instead. It actually has nothing to do with disk space: the whole point is that, when compiling a program, I want to make sure it will *not* use g77, but gfortran instead. The way it is now, I have to specify gfortran-4 as the fortran compiler, say by using FC=/usr/bin/gfortran-4, but one can never be sure exactly how a specific 'configure' program will find its compilers. So, the removal of gcc/g77 executables and replacing by a symlink would remove any possibility for confusion. That could lead to confusion as the arguments for gfortran are not identical to those for g77. Myself, I want to have both to check that code compiles OK with both them. Brian. 2. In this case, which executables should I point the symlink to? For instance, if I were to replace g77 by a symlink to gfortran, which of the 4 gfortran executables should I use: $ locate gfortran | grep exe /bin/gfortran-4.exe /bin/i686-pc-cygwin-gfortran-4.exe These are identical copies; one is the name preferred when cross-compiling, the other when doing native compiles. Got it, thanks. But why worry about adding symlinks? Why not just rely on what the package gave you, since it works? Are you really that low on disk space? I suppose they could be made hardlinks to one another, if someone were to invest the time into patching setup.exe to attempt to make hardlinks (instead of its current behavior of blindly creating identical copies, even when the tar file specifies hardlinks). /usr/bin/gfortran-4.exe /usr/bin/i686-pc-cygwin-gfortran-4.exe These two are identical to the ones above - you need to read the manual, and remind yourself that /bin and /usr/bin are mount points that visit the same directory. Removing /bin/gfortran-4.exe would simultaneously make /usr/bin/gfortran-4.exe disappear. 3. Lastly, just a dumb question: why do we get multiple executables in the first place? I noticed that g77 also comes in multiple files: $ locate g77 | grep exe /bin/g77.exe /usr/bin/g77.exe Is that really necessary? Yes, because that's how the default mount points are set up. OK, I had missed the point about /bin and /usr/bin actually pointing to the same directory. Things are a lot clearer now. Thanks, -- Brian Salter-Duke Melbourne, Australia My real address is b_duke(AT)bigpond(DOT)net(DOT)au Use this for reply or followup. Registered Linux user 287938. Cygwin for Linux on PCs. http://www.cygwin.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc4/gfortran
On Wed, Dec 3, 2008 at 8:36 PM, Eric Blake wrote: According to Gustavo Seabra on 12/3/2008 7:38 AM: 1. Is is safe to remove the old gcc (3.*) packages and replace them by symlinks to the new gcc4 executables? Read the archives. Dave has mentioned that he is planning on a future packaging of the gcc packages that use the alternatives package, so that the symlink management of the name gcc can be done automatically to point to either gcc-3 or gcc-4. But at the moment, I'm not sure whether the gcc-4 package requires files provided by the gcc package, in which case blindly deleting all thing gcc 3.* might break gcc-4. Got it. But I was actually just planning on removing the gcc and g77 executables, and make those names point to gcc4 executables instead. It actually has nothing to do with disk space: the whole point is that, when compiling a program, I want to make sure it will *not* use g77, but gfortran instead. The way it is now, I have to specify gfortran-4 as the fortran compiler, say by using FC=/usr/bin/gfortran-4, but one can never be sure exactly how a specific 'configure' program will find its compilers. So, the removal of gcc/g77 executables and replacing by a symlink would remove any possibility for confusion. 2. In this case, which executables should I point the symlink to? For instance, if I were to replace g77 by a symlink to gfortran, which of the 4 gfortran executables should I use: $ locate gfortran | grep exe /bin/gfortran-4.exe /bin/i686-pc-cygwin-gfortran-4.exe These are identical copies; one is the name preferred when cross-compiling, the other when doing native compiles. Got it, thanks. But why worry about adding symlinks? Why not just rely on what the package gave you, since it works? Are you really that low on disk space? I suppose they could be made hardlinks to one another, if someone were to invest the time into patching setup.exe to attempt to make hardlinks (instead of its current behavior of blindly creating identical copies, even when the tar file specifies hardlinks). /usr/bin/gfortran-4.exe /usr/bin/i686-pc-cygwin-gfortran-4.exe These two are identical to the ones above - you need to read the manual, and remind yourself that /bin and /usr/bin are mount points that visit the same directory. Removing /bin/gfortran-4.exe would simultaneously make /usr/bin/gfortran-4.exe disappear. 3. Lastly, just a dumb question: why do we get multiple executables in the first place? I noticed that g77 also comes in multiple files: $ locate g77 | grep exe /bin/g77.exe /usr/bin/g77.exe Is that really necessary? Yes, because that's how the default mount points are set up. OK, I had missed the point about /bin and /usr/bin actually pointing to the same directory. Things are a lot clearer now. Thanks, -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc4/gfortran
Hi All, I recently made a fresh new Cygwin installation. I asked for the full installation of the devel category to be installed, which resulted in both gcc and gcc4 to be installed. (BTW, great work with gcc4 package, thanks a lot!!!) I wonder: 1. Is is safe to remove the old gcc (3.*) packages and replace them by symlinks to the new gcc4 executables? 2. In this case, which executables should I point the symlink to? For instance, if I were to replace g77 by a symlink to gfortran, which of the 4 gfortran executables should I use: $ locate gfortran | grep exe /bin/gfortran-4.exe /bin/i686-pc-cygwin-gfortran-4.exe /usr/bin/gfortran-4.exe /usr/bin/i686-pc-cygwin-gfortran-4.exe 3. Lastly, just a dumb question: why do we get multiple executables in the first place? I noticed that g77 also comes in multiple files: $ locate g77 | grep exe /bin/g77.exe /usr/bin/g77.exe Is that really necessary? Thanks a lot, -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc4/gfortran
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gustavo Seabra on 12/3/2008 7:38 AM: 1. Is is safe to remove the old gcc (3.*) packages and replace them by symlinks to the new gcc4 executables? Read the archives. Dave has mentioned that he is planning on a future packaging of the gcc packages that use the alternatives package, so that the symlink management of the name gcc can be done automatically to point to either gcc-3 or gcc-4. But at the moment, I'm not sure whether the gcc-4 package requires files provided by the gcc package, in which case blindly deleting all thing gcc 3.* might break gcc-4. 2. In this case, which executables should I point the symlink to? For instance, if I were to replace g77 by a symlink to gfortran, which of the 4 gfortran executables should I use: $ locate gfortran | grep exe /bin/gfortran-4.exe /bin/i686-pc-cygwin-gfortran-4.exe These are identical copies; one is the name preferred when cross-compiling, the other when doing native compiles. But why worry about adding symlinks? Why not just rely on what the package gave you, since it works? Are you really that low on disk space? I suppose they could be made hardlinks to one another, if someone were to invest the time into patching setup.exe to attempt to make hardlinks (instead of its current behavior of blindly creating identical copies, even when the tar file specifies hardlinks). /usr/bin/gfortran-4.exe /usr/bin/i686-pc-cygwin-gfortran-4.exe These two are identical to the ones above - you need to read the manual, and remind yourself that /bin and /usr/bin are mount points that visit the same directory. Removing /bin/gfortran-4.exe would simultaneously make /usr/bin/gfortran-4.exe disappear. 3. Lastly, just a dumb question: why do we get multiple executables in the first place? I noticed that g77 also comes in multiple files: $ locate g77 | grep exe /bin/g77.exe /usr/bin/g77.exe Is that really necessary? Yes, because that's how the default mount points are set up. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk3NDcACgkQ84KuGfSFAYC44gCgy4e7MwOMh9RO1Z+pZVPhZfE8 ZOIAoLF9YRTAbGc6SHz/cvGjcsMPON02 =nQAf -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
