I tried your new g77 3.3.2 on 10.3 with cernlib. cernlib builds fine, but the test fails as it was the case with 3.3(.1) (see our email exchange from Jul 17, 2003). With the g77 3.4-20031015 it works flawlessly.
Thanks for your effort.
Remi
On Friday, November 7, 2003, at 04:43 AM, Jeff Whitaker wrote:
William and Martin: I've verified that the latest released g77 (3.3.2)
does not have the assembler bug present in 3.1,3.3.1 and Apple's
3.3-20030304. As Martin pointed out, the reason I put the 3.4 package in,
even though it is not a released version of g77, is that it was the only
version that didn't have the bug at the time. William - I've put 3.3.2 in
10.3 unstable, please try it on your packages, if it works for them (and
all the other fortran packages) I can make it the primary g77 version
either by using Martin's trick, or adding "Epoch: 1" to the info file.
-Jeff
On Fri, 7 Nov 2003, Martin Costabel wrote:
William Scott wrote: []Is there any way to have version 3.1 and 3.3 cohabitating in 10.3?
I don't think there is a reasonable way to have two *installed* versions
of g77 cohabitate. For two *package descriptions* cohabitating, the
right way would be to create a g77-3.1 package, i.e. instead of
Package: g77 Version: 3.1-20020420 Revision: 6
make it
Package: g77-3.1 Version: 20020420 Revision: 6
and make it conflict/replace with g77.
BUT:
Whereas the fatal bug of g77-3.1 is clearly documented(*) and has not gone away with Panther, the bugs with g77-3.4 that have been reported here do not seem to be deterministic. At least I haven't seen bug reports that can be reproduced by everyone.
I don't think Jeff or anyone else feels the need to have the very latest
g77 version. The only criterion is to have a fortran compiler that just
works. And so far the best strategy seemed to be to use recent snapshots
in order to take advantage of the bug fixes that went into the
"official" gcc sources.
I've
noticed that some other people have had problems too. Alternatively, is
there a way for me to install 3.1 and avoid having fink try to
auto-update it to 3.4 every time I issue fink update-all? The latter
would solve my problem, but I still can't put some of my packages into
10.3 until I can get them to compile.
(*) Contrary to what some have reported here, the gcc3.3 of Panther
still has the bug where a trivial program defining an empty struct does
not compile. Compiling the 2-liner
struct { } foo = { }; void * bar(void) { return &foo; }
with gcc-3.3 gives
costabel% gcc test_c.c
/var/tmp//cc7djqBM.s:22:section difference relocatable subtraction
expression, "_foo" minus "L00000000001$pb" using a symbol at the end of
section will not produce an assembly time constant
/var/tmp//cc7djqBM.s:22:use a symbol with a constant value created with
an assignment instead of the expression, L_const_sym = _foo -
L00000000001$pb
/var/tmp//cc7djqBM.s:21:section difference relocatable subtraction
expression, "_foo" minus "L00000000001$pb" using a symbol at the end of
section will not produce an assembly time constant
/var/tmp//cc7djqBM.s:21:use a symbol with a constant value created with
an assignment instead of the expression, L_const_sym = _foo -
L00000000001$pb
With g77-3.1, the following program gives the same error message. Even a
program consisting only of 1 line " end" gives the same error:
costabel% cat test_f.f
program hello
write(6, '(1X,A)') 'Hello world'
end
[abook:]costabel% g77 test_f.f
/var/tmp//ccAvjI34.s:48:section difference relocatable subtraction
expression, "LC3" minus "L1$pb" using a symbol at the end of section
will not produce an assembly time constant
/var/tmp//ccAvjI34.s:48:use a symbol with a constant value created with
an assignment instead of the expression, L_const_sym = LC3 - L1$pb
/var/tmp//ccAvjI34.s:47:section difference relocatable subtraction
expression, "LC3" minus "L1$pb" using a symbol at the end of section
will not produce an assembly time constant
/var/tmp//ccAvjI34.s:47:use a symbol with a constant value created with
an assignment instead of the expression, L_const_sym = LC3 - L1$pb
The accepted way to "correct" this bug with g77 prior to 3.4 was to
replace the assembler in /usr/libexec/gcc/darwin/ppc/ by an older one
from the Dec2002 dev tools (or to install an as package that does this),
and I don't think anyone wants to do this on Panther.
-- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449 325 Broadway Web : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
---------------------------------------------------------------------
"Sometimes I think the surest sign that intelligent life exists else-
where in the universe is that none of it has tried to contact us."
Calvin (Bill Watterson)********************************************************************* Remigius K. Mommsen e-mail: [EMAIL PROTECTED] University of California, Irvine URL: http://cern.ch/mommsen c/o SLAC voice: ++1 (650) 926-3595 2575 Sand Hill Road #35 fax: ++1 (650) 926-3882 Menlo Park, CA 94025, US home: ++1 (650) 233-9041 *********************************************************************
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
