Home > Archive > Fortran > March 2008 > preparing for the next open-source gfortran release
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
preparing for the next open-source gfortran release
|
|
| Gerry Ford 2008-02-29, 4:31 am |
| I've been working up my game with open-source distros and believe to have
come upon a compelling reason not to have more than one on a given machine.
So I'll be ripping out everything I have in anticipation of the new release.
Linux is much more aware this way. Anyways, I had an installation that
turned out to be 4.3.0, after which I installed 4.2.3. This is what the
linker is looking for:
g++ -o lang1.o -c langston1.cpp -v 2>text69.txt
, where langston1.cpp is a c++ function that does modest mathematical
things:
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: i386-pc-mingw32
Configured with:
.../gcc-4.2.3-mingw/configure --host=i386-pc-mingw32 --build=x86_64-unknown-linux-gnu
--target=i386-pc-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls --disable-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,c++,fortran --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.2.3
--enable-threads=win32 --enable-libgomp --disable-win32-registry
Thread model: win32
gcc version 4.2.3
c:/gcc/bin/../libexec/gcc/i386-pc-mingw32/4.2.3/cc1plus.exe -quiet -v -iprefix
c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.2.3/ langston1.cpp -quiet -dumpbase
langston1.cpp -mtune=i386 -auxbase-strip lang1.o -version -o
C:\DOCUME~1\dan\LOCALS~1\Temp/ccMg6Sbj.s
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3/include/c++/4.2.3"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3/include/c++/4.2.3/i386-pc-mingw32"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3/include/c++/4.2.3/backward"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.2.3/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3/lib/gcc/i386-pc-mingw32/4.2.3/../../../../include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3/lib/gcc/i386-pc-mingw32/4.2.3/include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.2.3/i386-pc-mingw32/include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.2.3/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
C:/gcc/include
c:/gcc/bin/../lib/gcc/i386-pc-mingw32/4.2.3/../../../../include/c++/4.2.3
c:/gcc/bin/../lib/gcc/i386-pc-mingw32/4.2.3/../../../../include/c++/4.2.3/i386-pc-mingw32 c:/gcc/bin/../lib/gcc/i386-pc-mingw32/4.2.3/../../../../include/c++/4.2.3/backward c:/gcc/bin/../lib/gcc/i386-pc-mingw32/4.2.3/include c:/gcc/bin/../lib/gcc/i386-pc
-mingw32/4.2.3/../../../../i386-pc-mingw32/includeEnd of search list.g++ --version yieldsGNU C++ version 4.2.3 (i386-pc-mingw32) compiled by GNU C version 4.2.3.GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131006Compiler executable
checksum: 7d1ae633d2d0a50743a002fa1f809f44 c:/gcc/bin/../lib/gcc/i386-pc-mingw32/4.2.3/../../../../i386-pc-mingw32/bin/as.exe -o lang1.o C:\DOCUME~1\dan\LOCALS~1\Temp/ccMg6Sbj.s, while gfortran2, my renaming, --version yieldsGNU Fortran (GCC) 4.3.0 20080
127 (experimental) [trunk revision 131883]Copyright (C) 2007 Free Software Foundation, Inc.GNU Fortran comes with NO WARRANTY, to the extent permitted by law.You may redistribute copies of GNU Fortranunder the terms of the GNU General Public License.For m
ore information about these matters, see the file named COPYING!end rebuke from linkersThe 4.3.0 version came with an un-installer that I will use after pullingout the earlier version. I'll keep silverfrost around to test fortransyntax.--Gerry Ford"Er ha
t sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma nullbeziehend.
| |
|
| > I've been working up my game with open-source distros and believe to
> have come upon a compelling reason not to have more than one on a given
> machine.
There is no reason you can't have more than one GCC (or GCC-based)
installation on your Windows computer. I have many more than one, and
never had the slightest problem. If you have a problem, it means some of
your installations have done crude things to the environment variables
that prevent other installations from working (g95 and the gfortran
binaries from www.equation.com were known to do that at some point, I
don't know if it was fixed). This is a bug of these installations, and
you should report that to the person who provided them to you.
--
FX
| |
|
|
"Gerry Ford" <invalid@invalid.net> wrote in message
news:1204268678_55777@news.newsgroups.com...
> I've been working up my game with open-source distros and believe to have
> come upon a compelling reason not to have more than one on a given
machine.
> So I'll be ripping out everything I have in anticipation of the new
release.
>
> Linux is much more aware this way. Anyways, I had an installation that
> turned out to be 4.3.0, after which I installed 4.2.3. This is what the
> linker is looking for:
> .....
>
You installed two versions on the same system. ENVIRONMENT VARIABLES messed
up. The way to resolve the problem is type the command
set | more
to find out which environment variable messed up. The distribution 4.2.3,
from www.equation.com, properly set the variable, and won't cause the
problem. That is not a problem caused by 4.2.3. If you re-install 4.2.3
under a new account, you should not get the problem.
The distribution 4.3.0-20080127 does not have g++. I have no idea how the
distribution, 4.3.0-20080127 (possibly from FX) you installed, set the
variables. The message, you provided, shows "nonexistent directory". That
means c++ components cannot be found. As a matter of fact, the distribution
4.2.3 has all the g++ components. This is problem of environment variables.
Please type the command
set | more
to show the environment variables. I do have a suggestion. If you like to
install two distributions on Windows. You can install, for example, 4.2.3,
under a new account user_a, and install 4.3.0-20080127 under another
account. Don't install two distributions under the same account. Environment
variables could be messed up.
| |
|
| > The distribution 4.2.3, from www.equation.com, properly set the
> variable, and won't cause the problem.
Which variable?
> Don't install two distributions under the same account. Environment
> variables could be messed up.
GCC-based compilers should, if compiled in the right way, not rely on
environment variables to find their own libraries (or the mingw libraries
that come with them). That's all. Setting LIBRARY_PATH (like g95 and your
distribution does) only leads to trouble.
The one variable that can be set without trouble is PATH.
--
FX
| |
|
|
"FX" <coudert@alussinan.org> wrote in message
news:fqa5ur$2cei$1@nef.ens.fr...
> GCC-based compilers should, if compiled in the right way, not rely on
> environment variables to find their own libraries (or the mingw libraries
> that come with them). That's all. Setting LIBRARY_PATH (like g95 and your
> distribution does) only leads to trouble.
Do you have any evidence the distribution with a setting of LIBRARY_PATH
leads to a trouble?
The setting of LIBRARY_PATH never contradicts to any setting. What kind of
trouble existed?
The reason to set LIBRARY_PATH is the old version of mingw-w64 put libs in
the subdirectory /lib64. Linker cannot find the libs without the setting.
LIBRARY_PATH was added into installer under this circumstance. Possibly, you
never built native 64-bit for mingw, and you cannot realize this. (Newer
version put libs in /lib, and LIBRARY_PATH is no longer required).
>
> The one variable that can be set without trouble is PATH.
>
This could be true in some occasions, and could be false in other occasions.
Thank you for your contribution to GCC.
| |
|
| > Do you have any evidence the distribution with a setting of
> LIBRARY_PATH leads to a trouble?
LIBRARY_PATH is a environment library that tells the GCC driver that
there are libraries to be included in the directory it points to, and
that it should in some case override the "usual" directories for
libraries. As it is common to all GCC-based distributions, setting it to
point to a directory that contains libraries specific to one distribution
can make all other distributions fail, if they distributed
ABI-incompatible versions of the same library.
That has been the case in the past for g95, that set it and distributed
an old mingw-runtime version, which conflicted with gfortran's more
recent mingw-runtime. I don't know if it has been fixed since then.
For the benefit of our users, it is best that not GCC implementation set
this variable altogether. GCC should find its way without it, and if it
doesn't, it's a bug that should be fixed by other means than the use of
LIBRARY_PATH.
> Thank you for your contribution to GCC.
You're welcome. By the way, I'm still waiting for an answer to my
question about your OpenMP library (see
http://groups.google.com/group/comp...1d0d30c62ab1082).
Can you help me make sure it reaches the right person in your company?
Since I have not found any specific license in your distribution, I
assume that your implementation of libgomp is under the GPL, and would
thus like to have access to its source code.
--
FX
| |
|
|
"FX" <coudert@alussinan.org> wrote in message
news:fqbeio$2dvh$1@nef.ens.fr...
> LIBRARY_PATH is a environment library that tells the GCC driver that
> there are libraries to be included in the directory it points to, and
> that it should in some case override the "usual" directories for
> libraries. As it is common to all GCC-based distributions, setting it to
> point to a directory that contains libraries specific to one distribution
> can make all other distributions fail, if they distributed
> ABI-incompatible versions of the same library.
>
> That has been the case in the past for g95, that set it and distributed
> an old mingw-runtime version, which conflicted with gfortran's more
> recent mingw-runtime. I don't know if it has been fixed since then.
>
> For the benefit of our users, it is best that not GCC implementation set
> this variable altogether. GCC should find its way without it, and if it
> doesn't, it's a bug that should be fixed by other means than the use of
> LIBRARY_PATH.
Libs directory, out of gcc convention, is set by the variable LIBRARY_PATH.
| |
| Gerry Ford 2008-03-02, 4:37 am |
|
"post" <no-spam@equation.com> wrote in message
news:oDlyj.1313$6R.73@trnddc04...
>
> "FX" <coudert@alussinan.org> wrote in message
> news:fqbeio$2dvh$1@nef.ens.fr...
>
> Libs directory, out of gcc convention, is set by the variable
> LIBRARY_PATH.
>
Your non-response is noted. I'm getting a little ANSI on that new frickin
release: get it out the door.
--
Gerry Ford
"Er hat sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.
| |
|
|
"Gerry Ford" <invalid@invalid.net> wrote in message
news:1204439266_57688@news.newsgroups.com...
> Your non-response is noted. I'm getting a little ANSI on that new frickin
> release: get it out the door.
>
>
You are here.
You don't provide the environment settings, there is no way to know what's
wrong with your installations. According to your post, the problem is not
originated by the distribution 4.2.3. You are the only one getting the
problem. GCC has its "convention" to find the path if the path is not
explicitly set. The distribution 4.2.3 can find all the paths it needs if
the variable is not explicitly set. When you invoke release 4.2.3, you got
distribution 4.3.0 (from FX). What could that happen? The distribution 4.2.3
never set an environment variable pointing to 4.3.0. There is an environment
variable, inappropriately and explicitly set on your computer, pointing to a
subdirecoty of 4.3.0. We need to find which distribution inappropriately set
the variable.
| |
| Gerry Ford 2008-03-02, 10:14 pm |
|
"post" <no-spam@equation.com> wrote in message
news:vFwyj.7875$li.7084@trnddc06...
>
> "Gerry Ford" <invalid@invalid.net> wrote in message
> news:1204439266_57688@news.newsgroups.com...
>
>
> You are here.
>
> You don't provide the environment settings, there is no way to know what's
> wrong with your installations. According to your post, the problem is not
> originated by the distribution 4.2.3. You are the only one getting the
> problem. GCC has its "convention" to find the path if the path is not
> explicitly set. The distribution 4.2.3 can find all the paths it needs if
> the variable is not explicitly set. When you invoke release 4.2.3, you got
> distribution 4.3.0 (from FX). What could that happen? The distribution
> 4.2.3
> never set an environment variable pointing to 4.3.0. There is an
> environment
> variable, inappropriately and explicitly set on your computer, pointing to
> a
> subdirecoty of 4.3.0. We need to find which distribution inappropriately
> set
> the variable.
>
>
>
The more direct reason that the path doesn't work is that I've deleted both
gfortran installations. I'm jonesing for another. Did I understand you
correctly that of the 2 versions I had, only one had g++exe?
Does someone have the link again for that heavily-mingw 4.2.3 release from
equation.com? What features of gfortran's iso c binding has it yet to
implement?
--
Gerry Ford
"Er hat sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.
| |
|
|
"Gerry Ford" <invalid@invalid.net> wrote in message
news:1204506611_57788@news.newsgroups.com...
> The more direct reason that the path doesn't work is that I've deleted
both
> gfortran installations. I'm jonesing for another. Did I understand you
> correctly that of the 2 versions I had, only one had g++exe?
>
> Does someone have the link again for that heavily-mingw 4.2.3 release from
> equation.com? What features of gfortran's iso c binding has it yet to
> implement?
>
I do have a suggestion. Don't download future distribution based on your
baseless complaint.
1) gfortran 4.2 does not support c binding. For c binding, you should try
4.3
2) According to your initial post, you tried 4.2.3, but got 4.3.0. If you
have a brain, you could figure out the environment variables had been
override by 4.3.0. Compiler has searched libraries under 4.3.0 no matter
which version of compiler you run. Even you run 4.2.3, the libraries are
4.3.0 that caused the problem for failure to find g++ components. All the
mess was from the distribution 4.3.0 (from FX) that inappropriately set
environment variables to override the settings.
| |
| Gerry Ford 2008-03-03, 8:08 pm |
|
"post" <no-spam@equation.com> wrote in message
news:ScTyj.13812$e_.9510@trnddc03...
>
> "Gerry Ford" <invalid@invalid.net> wrote in message
> news:1204506611_57788@news.newsgroups.com...
> both
>
>
> I do have a suggestion. Don't download future distribution based on your
> baseless complaint.
What complaint was that? That my linker was  and that I was ripping
out everything prophylactically?
>
> 1) gfortran 4.2 does not support c binding. For c binding, you should try
> 4.3
> 2) According to your initial post, you tried 4.2.3, but got 4.3.0. If you
> have a brain, you could ....
Spoken like a true linux weenie at a distance. Your insult is syntactically
incorrect. If you *had* an OS or an answer to the distribution question
that doesn't have the odor of the Bush admin's "answers" for illegality,
this conversation might have gone differently.
--
Gerry Ford
"Er hat sich georgiert." Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.
| |
| Gerry Ford 2008-03-12, 4:46 am |
|
"post" <no-spam@equation.com> wrote in message
news:7R0yj.7364$li.2495@trnddc06...
>
> "Gerry Ford" <invalid@invalid.net> wrote in message
> news:1204268678_55777@news.newsgroups.com...
> machine.
> release.
>
> You installed two versions on the same system. ENVIRONMENT VARIABLES
> messed
> up. The way to resolve the problem is type the command
>
> set | more
>
> to find out which environment variable messed up. The distribution 4.2.3,
> from www.equation.com, properly set the variable, and won't cause the
> problem. That is not a problem caused by 4.2.3. If you re-install 4.2.3
> under a new account, you should not get the problem.
>
> The distribution 4.3.0-20080127 does not have g++. I have no idea how the
> distribution, 4.3.0-20080127 (possibly from FX) you installed, set the
> variables. The message, you provided, shows "nonexistent directory". That
> means c++ components cannot be found. As a matter of fact, the
> distribution
> 4.2.3 has all the g++ components. This is problem of environment
> variables.
> Please type the command
>
> set | more
>
> to show the environment variables. I do have a suggestion. If you like to
> install two distributions on Windows. You can install, for example, 4.2.3,
> under a new account user_a, and install 4.3.0-20080127 under another
> account. Don't install two distributions under the same account.
> Environment
> variables could be messed up.
These are the values of the path system variable of my primary identity, now
that I put equation's open source distro on another user identity:
C:\path\gcc\bin;C:\path\gcc\i386-pc- mingw32\bin;C:\equation\gcc\bin;C:\Progr
am
Files\Silverfrost\FTN95;C:\Perl\site\bin
;C:\Perl\bin;c:\ruby\bin;%SystemRoot%\sy
stem32;%SystemRoot%;%SystemRoot%\System3
2\Wbem
I don't think that having another user identity shelters a person from path
trouble with open-source distros. The point is, I think, that you have to
go in after the fact and change this stuff manually, if you want gcc distros
of differing versions to "work." At a minumum, dos cannot be as
well as your linker.
Now that I look back, equation 4.2.3 adds a mingw entry; 4.3.0 does not.
> set | more
I'm curious what that pipe is supposed to do for me.
--
Gerry Ford
"Anybody who says, that a high-speed collision with water is the same as
with concrete, likely has more experience with the former than the latter."
| |
|
|
"Gerry Ford" <invalid@invalid.net> wrote in message
news:1205308110_27@news.newsgroups.com...
>
> I don't think that having another user identity shelters a person from
path
> trouble with open-source distros. The point is, I think, that you have to
> go in after the fact and change this stuff manually, if you want gcc
distros
> of differing versions to "work." At a minumum, dos cannot be as
> well as your linker.
>
For what purpose for you to keep two distributions? If you like, you can
keep in separate accounts. Separate account has an individual user's
environments, which are in the registry, for example,
My Computer
--> HKEY_CURRENT_USER
------> Environment
That is the right place to keep individual settings. Don't install
applications by an account with "administrator privilege", which may
possibly make system-wide settings. This is not within the scope of
"fortran". If necessary, some references on Windows may help, or post on
Windows newsgroup.
> Now that I look back, equation 4.2.3 adds a mingw entry; 4.3.0 does not.
>
> I'm curious what that pipe is supposed to do for me.
>
If you have a long list of environment variables, the "pipe" allows you to
see the list page-by-page. Fortran newsgroup needs to answer your Windows
questions.
|
|
|
|
|