🚀 go-pugleaf

Jeff Templon <templon@studbolt.physast.uga.edu> writes:

> Hi,

Hi back, and thanks for the helpful info!  Maybe we can fix some
of these things before 0.5.23 is released.

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

Okay, this confuses me.  AFAIK, stock (netlib) libf2c does not
*define* MAIN__ (which becomes MAIN___), it defines main (which
becomes main_), and its main() calls MAIN__.

In this respect, g77 should be no different, in any release, from
the netlib libf2c.

> $ >  > 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;
[...]
> * 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.

It seems to me as if a simple and worthwhile solution is to have
libf2c (maybe just g77's version for now, but perhaps netlib will
pick up this change after we email it to them) put the definitions
of xargc and xargv into a separate source module, maybe named
`xarg.c', compiled and added to libf2c as `xarg.o'.  Of course its
main() routine would then `extern' these and set them as usual.

That way, if you want your own main(), you can have it and GETARG/IARGC
as well, as long as you set xargc and xargv in main().  (Though,
I don't like the names xargc/xargv, and hardly wish to publish
them further, as they could conflict with user code, e.g.
SUBROUTINE XARGC shouldn't conflict with it.)

Hmm, I think I'll try mangling the external names somewhat and
provide wrappers for them, so user-written main() routines can
simply call the wrappers instead of having to memorize names.
(In the libf2c world, all mangling requires is inserting an
underscore into the midst of a name, which keeps the current
naming convention from colliding with it.  `x_argc', for example,
can't be called by an g77/f2c-compiled program because of the
trailing underscore(s), unless special options are used, options
that mean "you're likely to break your program this way".  :)

How does that sound as a general approach to solving this particular
problem?  It might be worth holding up 0.5.23 to get this "right",
at least a couple of days.  Heck, if MS can hold up Windows 98 over
the weekend, we can hold up g77 0.5.23 for about that long, right?
-- 

"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson    burley@gnu.org