preparing for the next open-source gfortran release

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/nat
ive/x86_32/gcc/4.2.3
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls --disa
ble-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp --with-m
pfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,c++,fortran --with-sysroot=/home/gfortran/gcc-home/bina
ry/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 -ipref
ix
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-ming
w32/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/i3
86-pc-mingw32 c:/gcc/bin/../lib/gcc/i386-pc-mingw32/4.2.3/../../../../includ
e/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++ --v
ersion   yieldsGNU C++ version 4.2.3 (i386-pc-mingw32) compiled by GNU C ver
sion 4.2.3.GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsiz
e=131006Compiler executable
checksum: 7d1ae633d2d0a50743a002fa1f809f44 c:/gcc/bin/../lib/gcc/i386-pc-min
gw32/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 F
oundation, Inc.GNU Fortran comes with NO WARRANTY, to the extent permitted b
y law.You may redistribute copies of GNU Fortranunder the terms of the GNU G
eneral Public License.For m
ore information about these matters, see the file named COPYING!end rebuke f
rom 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 fortr
ansyntax.--Gerry Ford"Er ha
t sich georgiert."  Der Spiegel, 2008, sich auf Chimpy Eins komma nullbezieh
end.

> 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.

"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.

"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.