🚀 go-pugleaf

Hi,

Craig Burley <burley@tweedledumb.cygnus.com> writes:

> > Problem: another difference of stock libf2c vs egcs libf2c is that the
> > egcs version defines the routine "main" within the library.
> 
> So does stock libf2c, at least, last time I checked.

stock libf2c defines something called MAIN__ but not `main', or at
least I never had a problem with it.  The classic workaround was something
like -X defsym -X MAIN__=main on the loader command line.  Due
to the extra appearance of "main", it no longer worked with G77 libf2c.
This is not specific to redhat 5.0 either, we've had this problem
on redhat 4.2 as well whenever G77 is installed.

> Why there's a problem having main.o in libf2c is beyond me.  Seems
> to me that as long as you link only *one* "main program unit"
> (Fortran "PROGRAM"), crt0.o or crt1.o or whatever calls main_
> should be linked to that, instead of the linker pulling in
> libf2c/main.o.  It shouldn't matter, in this sense, whether the
> main program unit is compiled by g77/f2c or Absoft, assuming
> Absoft compiles main_ or MAIN__, because crt[01].o calls main_,
> which is either produced by Absoft or is linked to libf2c's main_,
> and the latter calls MAIN__.

See below, attached messages.  The real question is, why is G77
libf2c behaving differently than stock libf2c?  The fix proposed
in the messages below solved the problem, although it's a
huge hack.

					JAT

ps: have not included email addresses of the people who solved
this, since I don't want to be responsible for exposing them
to spam.  They did not use the newsgroups for reply, so I assume
they'd rather not have their email addresses posted.
The solutions below are the work of other people, not me!

--------------------------------------------------
$ Subject: Re: Request: help linking egcs-compiled fortran + other fortran
$ Date: Thu, 14 May 1998 17:32:38 BST
$ 
$ >  
$ >  > My two cents of contribution as an attempt to solve this problem.
$ >  > We have found that to avoid the two main programs that Jeff is
$ >  > reporting above, you can include the definition of the two
$ >  > following global variables in your C/C++ main program
$ >  > int xargv=0;
$ >  > int xargc=0;
$ >  >
$ >  > This works for us. We can link ROOT with CERNLIB98a.
$ >  > This is clearly a pain in the neck and more attention should have
$ >  > been given to this problem before making the release.
$ > 
$ > What if my main program is not C/C++ (it's not!)  Any ideas?
$ > 
$ 
$ Well, a quick and dirty way is to create a small c function
$ with these two statements and link it explicitely with your main.

--------------------------------------------------
* 
* Jeff Templon writes:
*  > Rene:
*  > 
*  > You are a genius!  Thanks, it worked.  I'm not sure I understand why,
*  > but that's OK.
*  > 
* 
* I think it works because there is a call to `getarg' in KUIP (kuinit.o
* I think it is). In libf2c, `getarg' gets the command line args via the
* `xargc' and `xargv' globals which are defined in libf2c's `main'. By
* pre-defining them there is no reason for the linker to pick up `main'.
* 
* I needed to do a kludge similar to Rene's to get PGF77 (v1.4 +
* gcc/libc5 system) to play nice with CERNLIB and C main()s. I fixed it
* by writing fake `getarg_' and `iargc_' functions. This, in effect,
* just blocks the linking in of the `xargc' and `xargv' globals which
* blocks the linking in of libf2c's main.
* 
* In general, I think it is not so good to call the `getarg' or `iargc'
* routines inside library code as it makes an arrogant assumption about
* which language `main' is being written in. Oh well.
*