libf2c

libf2c

[Dave Love]

I'm afraid I don't understand building Fortran these days, but the new
libf2c process doesn't look right to me.  I did a bootstrap, and
libf2c was configured with an installed compiler (an older gcc, as
this is a Linux box), reading my site autoconf config.site and cache.
It was then built with xgcc (as I expected).

Originally the configuration was careful to avoid
potentially-misleading autoconf configuration files (including
clobbering things with `make clean', contra GNU standards) and ensure
it did everything with GCC_FOR_TARGET (or whetever the old make
variable was called).  I can't immediately point to anything mixing
the compilers can break but what work I've done on the runtime has
always assumed the target compiler is used generally.

[Sorry for getting this stuff wrong in the first place.]

Re: libf2c

[Jeffrey A Law]

  In message < rzqu3agfqys.fsf@djlvig.dl.ac.uk >you write:
  > I'm afraid I don't understand building Fortran these days, but the new
  > libf2c process doesn't look right to me.  I did a bootstrap, and
  > libf2c was configured with an installed compiler (an older gcc, as
  > this is a Linux box), reading my site autoconf config.site and cache.
  > It was then built with xgcc (as I expected).
Hmmm, that's definitely broken.

What *should* happen is the compiler should 3-stage via "make bootstrap", 
then the runtime libraries (libstdc++, libio, libf2c) should be configured
using the target compiler.

Odds are we've just got a minor goof in either the toplevel make/configure
files or in the libf2c make/config files.


  > Originally the configuration was careful to avoid
  > potentially-misleading autoconf configuration files (including
  > clobbering things with `make clean', contra GNU standards) and ensure
  > it did everything with GCC_FOR_TARGET (or whetever the old make
  > variable was called).
Yup.  All this hackery should be able to be removed with the new
organization modulo bugs we've introduced.


  > I can't immediately point to anything mixing
  > the compilers can break but what work I've done on the runtime has
  > always assumed the target compiler is used generally.
It fails for cross compilers :-)  Which is one of the big benefits of
getting it out of the gcc subdir, it's easier to get these issues dealt
with correctly.

  > [Sorry for getting this stuff wrong in the first place.]
No worries, we'll get it nailed down. :-)

jeff

Re: libf2c

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 >> I can't immediately point to anything mixing
 >> the compilers can break but what work I've done on the runtime has
 >> always assumed the target compiler is used generally.

 Jeff> It fails for cross compilers :-)  

I assumed without checking that it would DTRT for a cross-compiler :-)

 Jeff> Which is one of the big benefits of getting it out of the gcc
 Jeff> subdir, it's easier to get these issues dealt with correctly.

Perhaps I should again query the issues for criss-cross building, or
maybe they're moot now and won't affect new work.  I obviously
misunderstood what people have been saying for years about problems
with the configuration/build in the face of it working.  If I (or lots
of other keen people!) resume work on the runtime is there anything
obviously important to get into the proverbial thick skull?  Should it
be straightforward just to add code with autoconfism modelled on
what's there when the libf2c dir has settled down?

Re: libf2c

[Jeffrey A Law]

  In message < rzqsopzt24l.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  >> I can't immediately point to anything mixing
  >  >> the compilers can break but what work I've done on the runtime has
  >  >> always assumed the target compiler is used generally.
  > 
  >  Jeff> It fails for cross compilers :-)  
  > 
  > I assumed without checking that it would DTRT for a cross-compiler :-)
Hmmm, I just watched an x86 native "bootstrap" and it does the right thing
as far as I can tell:

Configuring in libraries/libf2c
creating cache ./config.cache
checking for gcc... /usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs/gcc/
checking whether the C compiler (/usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs/gcc/ -g -O2 ) works... yes
checking whether the C compiler (/usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs/gcc/ -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether /usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs/gcc/ accepts -g... yes
checking how to run the C preprocessor... /usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs/gcc/ -E

[ ... ]


  > Perhaps I should again query the issues for criss-cross building, or
  > maybe they're moot now and won't affect new work.  I obviously
  > misunderstood what people have been saying for years about problems
  > with the configuration/build in the face of it working.  If I (or lots
  > of other keen people!) resume work on the runtime is there anything
  > obviously important to get into the proverbial thick skull?  Should it
  > be straightforward just to add code with autoconfism modelled on
  > what's there when the libf2c dir has settled down?
The problems are a whole lot easier to deal with now.  Basically when the
libf2c subdir gets configured we should already have a cross compiler,
includes and libraries built.  This will allow more of the configuration
process to work in the normal way.

We certainly need to do more work with libf2c (multilib, actually make
sure the cross stuff works, etc).  But it's a much easier problem to
start working on now.

jeff

Re: libf2c

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> Hmmm, I just watched an x86 native "bootstrap" and it does the
 Jeff> right thing as far as I can tell:

 Jeff> Configuring in libraries/libf2c
 Jeff> creating cache ./config.cache
 Jeff> checking for gcc... /usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs/gcc/

I still find it DTWT for me.  I'll try to find time to figure it out.

Configuring in libraries/libf2c
loading site script /usr/local/share/config.site
loading cache /usr/local/var/config.cache
checking for gcc... (cached) gcc

Re: libf2c

[Jeffrey A Law]

  In message < rzqn2fs1ohb.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  Jeff> Hmmm, I just watched an x86 native "bootstrap" and it does the
  >  Jeff> right thing as far as I can tell:
  > 
  >  Jeff> Configuring in libraries/libf2c
  >  Jeff> creating cache ./config.cache
  >  Jeff> checking for gcc... /usr/tmp/egcs/egcs/gcc/xgcc -B/usr/tmp/egcs/egcs
  > /gcc/
  > 
  > I still find it DTWT for me.  I'll try to find time to figure it out.
  > 
  > Configuring in libraries/libf2c
  > loading site script /usr/local/share/config.site
  > loading cache /usr/local/var/config.cache
  > checking for gcc... (cached) gcc
I suspect it's because either config.site or config.cache has a 
specification for what compiler to use...

jeff

Re: libf2c

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 >> Configuring in libraries/libf2c
 >> loading site script /usr/local/share/config.site
 >> loading cache /usr/local/var/config.cache
 >> checking for gcc... (cached) gcc

 Jeff> I suspect it's because either config.site or config.cache has a 
 Jeff> specification for what compiler to use...

Indeed, but it shouldn't be allowed to bite.  (config.site is straight
from the autoconf manual, not that I think that DTRT; I think I
changed my former effort for purposes of testing like this.)

I followed the build process better this time :-).  This is what the
old f/runtime used to do.

1998-02-16  Dave Love  <d.love@dl.ac.uk>

	* Makefile.in ($(CONFIGURE_TARGET_MODULES)): Run configure with
	CONFIG_SITE=/dev/null to forestall lossage with site configuration.

Index: Makefile.in
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/Makefile.in,v
retrieving revision 1.14
diff -u -p -c -r1.14 Makefile.in
diff: conflicting specifications of output style
*** Makefile.in	1998/02/01 01:41:23	1.14
--- Makefile.in	1998/02/16 22:08:15
*************** $(CONFIGURE_TARGET_MODULES):
*** 1170,1180 ****
  	      libsrcdir="$$s/$${dir}"; \
  	    fi; \
  	    if [ -f $${libsrcdir}/configure ] ; then \
! 	      $(SHELL) $${libsrcdir}/configure \
  		$(CONFIG_ARGUMENTS) $${srcdiroption} \
  		--with-target-subdir="$(TARGET_SUBDIR)"; \
  	    else \
! 	      $(SHELL) $$s/configure \
  		$(CONFIG_ARGUMENTS) $${srcdiroption} \
  		--with-target-subdir="$(TARGET_SUBDIR)"; \
  	    fi; \
--- 1170,1180 ----
  	      libsrcdir="$$s/$${dir}"; \
  	    fi; \
  	    if [ -f $${libsrcdir}/configure ] ; then \
! 	      CONFIG_SITE=/dev/null $(SHELL) $${libsrcdir}/configure \
  		$(CONFIG_ARGUMENTS) $${srcdiroption} \
  		--with-target-subdir="$(TARGET_SUBDIR)"; \
  	    else \
! 	      CONFIG_SITE=/dev/null $(SHELL) $$s/configure \
  		$(CONFIG_ARGUMENTS) $${srcdiroption} \
  		--with-target-subdir="$(TARGET_SUBDIR)"; \
  	    fi; \

Re: libf2c

[Jeffrey A Law]

  In message < rzqk9avw5rq.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  >> Configuring in libraries/libf2c
  >  >> loading site script /usr/local/share/config.site
  >  >> loading cache /usr/local/var/config.cache
  >  >> checking for gcc... (cached) gcc
  > 
  >  Jeff> I suspect it's because either config.site or config.cache has a 
  >  Jeff> specification for what compiler to use...
  > 
  > Indeed, but it shouldn't be allowed to bite.  (config.site is straight
  > from the autoconf manual, not that I think that DTRT; I think I
  > changed my former effort for purposes of testing like this.)
  > 
  > I followed the build process better this time :-).  This is what the
  > old f/runtime used to do.
  > 
  > 1998-02-16  Dave Love  <d.love@dl.ac.uk>
  > 
  > 	* Makefile.in ($(CONFIGURE_TARGET_MODULES)): Run configure with
  > 	CONFIG_SITE=/dev/null to forestall lossage with site configuration.
Thanks.  Installed.
jeff

libf2c

[Christopher R. Jones]

On Redhat Linux 5.2, I have installed gcc2.95.1.  I am trying to building a
program that is wants to link libf2c (-lf2c) but I cannot locate this
library.  I did find libg2c.a.  


Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@interlog.com

libf2c

[Christopher R. Jones]

On Redhat Linux 5.2, I have installed gcc2.95.1.  I am trying to building a
program that is wants to link libf2c (-lf2c) but I cannot locate this
library.  I did find libg2c.a.  


Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@interlog.com

Re: libf2c

[Christopher R. Jones]

>In a message dated 9/20/99 10:39:34 AM EST, cj@interlog.com writes:
>
>> a
>>  program that is wants to link libf2c (-lf2c) but I cannot locate this
>>  library.  I did find libg2c.a.  

>libg2c makes a serious attempt to be upward compatible from the libf2c which 
>comes with f2c.  Linking normally is done by the g77 command, which implies 
>-lg2c.
>
So I can create a sym link libf2c.a -> libg2c.a and there should be no
problem.  I have been reading about binary incompatibility between files
compiled with previous egcs versions and gcc-2.95.1


Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@interlog.com

Re: libf2c

[Christopher R. Jones]

>In a message dated 9/20/99 10:39:34 AM EST, cj@interlog.com writes:
>
>> a
>>  program that is wants to link libf2c (-lf2c) but I cannot locate this
>>  library.  I did find libg2c.a.  

>libg2c makes a serious attempt to be upward compatible from the libf2c which 
>comes with f2c.  Linking normally is done by the g77 command, which implies 
>-lg2c.
>
So I can create a sym link libf2c.a -> libg2c.a and there should be no
problem.  I have been reading about binary incompatibility between files
compiled with previous egcs versions and gcc-2.95.1


Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@interlog.com

Re: libf2c

[N8TM]

In a message dated 9/21/99 8:51:54 AM EST, cj@interlog.com writes:

> So I can create a sym link libf2c.a -> libg2c.a and there should be no
>  problem.  I have been reading about binary incompatibility between files
>  compiled with previous egcs versions and gcc-2.95.1
The binary compatibility problem shouldn't arise between code newly compiled 
by the same version of gcc which made libg2c.a.  I have not seen any problems 
running any f77 style code, translated or not, and associated support 
libraries, over any of the egcs releases.  The real problems are with changes 
in g++, which needn't enter here.

Tim

Re: libf2c

[N8TM]

In a message dated 9/21/99 8:51:54 AM EST, cj@interlog.com writes:

> So I can create a sym link libf2c.a -> libg2c.a and there should be no
>  problem.  I have been reading about binary incompatibility between files
>  compiled with previous egcs versions and gcc-2.95.1
The binary compatibility problem shouldn't arise between code newly compiled 
by the same version of gcc which made libg2c.a.  I have not seen any problems 
running any f77 style code, translated or not, and associated support 
libraries, over any of the egcs releases.  The real problems are with changes 
in g++, which needn't enter here.

Tim

Re: libf2c

[Christopher R. Jones]

>> So I can create a sym link libf2c.a -> libg2c.a and there should be no
>>  problem.  I have been reading about binary incompatibility between files
>>  compiled with previous egcs versions and gcc-2.95.1
>The binary compatibility problem shouldn't arise between code newly compiled 
>by the same version of gcc which made libg2c.a.  I have not seen any
problems 
>running any f77 style code, translated or not, and associated support 
>libraries, over any of the egcs releases.  The real problems are with
changes 
>in g++, which needn't enter here.
Right you are.  I creates a symbolic link and the program complied, linked
and runs fine.  The program is esp-r
( http://www.strath.ac.uk/Departments/ESRU/esru.html ) , a dynamic thermal
simulation environment for the analysis of energy and mass flows and
environmental control systems within the built environment.  Originally
designed for Sun and Silicon graphics workstations, it now builds and runs
on Linux with gcc.  Now I am working on correcting the errors on Solaris 7,
Intel with gcc.


Thanks for your help.

Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@interlog.com

Re: libf2c

[Christopher R. Jones]

>> So I can create a sym link libf2c.a -> libg2c.a and there should be no
>>  problem.  I have been reading about binary incompatibility between files
>>  compiled with previous egcs versions and gcc-2.95.1
>The binary compatibility problem shouldn't arise between code newly compiled 
>by the same version of gcc which made libg2c.a.  I have not seen any
problems 
>running any f77 style code, translated or not, and associated support 
>libraries, over any of the egcs releases.  The real problems are with
changes 
>in g++, which needn't enter here.
Right you are.  I creates a symbolic link and the program complied, linked
and runs fine.  The program is esp-r
( http://www.strath.ac.uk/Departments/ESRU/esru.html ) , a dynamic thermal
simulation environment for the analysis of energy and mass flows and
environmental control systems within the built environment.  Originally
designed for Sun and Silicon graphics workstations, it now builds and runs
on Linux with gcc.  Now I am working on correcting the errors on Solaris 7,
Intel with gcc.


Thanks for your help.

Christopher R. Jones, P.Eng.
14 Oneida Avenue
Toronto, Ontario M5J 2E3
Tel. 416 203-7465
Fax. 416 203-3044
Email cj@interlog.com