Re: [Gnucap-devel] Feedback needed, especially non-Linux

[David Fang]

On Thu, 22 Feb 2007, al davis wrote:

> On Thursday 22 February 2007 17:10, David Fang wrote:
> > % ./gnucap
> > incorrect link order
> > Abort
>
> That tells me all I need to know.  There is code to check for a
> known problem and notify of it.
>
> Try this:
>
> Option #1 ...
>
> Change the order in which the files are listed.
> Put "globals.cc" first instead of last.
>
> Now does it work?

Editing the makefile, the final link command is now:
g++  -g -O2  -rdynamic -o gnucap   globals.o d_bjt.o d_mos1.o d_mos2.o
d_mos3.o d_mos4.o d_mos5.o d_mos6.o d_mos7.o d_mos8.o d_mos123.o
d_mos_base.o d_mos.o d_diode.o  d_admit.o d_cap.o d_cccs.o d_ccvs.o
d_coil.o d_coment.o d_cs.o d_logic.o d_logicmod.o d_poly_g.o d_poly_cap.o
d_res.o d_switch.o d_trln.o d_vcr.o d_vcvs.o d_vs.o bm_complex.o bm_exp.o
bm_fit.o bm_generator.o bm_poly.o bm_posy.o bm_pulse.o bm_pwl.o bm_sffm.o
bm_sin.o bm_tanh.o bmm_table.o bmm_semi.o c_comand.o c_delete.o c_getckt.o
c_list.o c_modify.o c_param.o c_status.o c_sweep.o c_sim.o c_system.o md.o
ap_construct.o ap_convert.o ap_error.o ap_get.o ap_match.o ap_skip.o
l_ftos.o l_pmatch.o l_timer.o l_trim.o l_wmatch.o m_fft.o m_spline.o io.o
io_contr.o io_error.o io_findf.o io_getln.o io_out.o io_xopen.o u_lang.o
u_nodemap.o u_opt1.o u_opt2.o u_parameter.o u_prblst.o u_probe.o u_sdp.o
u_xprobe.o s__.o s__aux.o s__init.o s__map.o s__out.o s__solve.o s_ac.o
s_ac_set.o s_ac_slv.o s_ac_swp.o s_dc.o s_dc_set.o s_dc_swp.o s_tr.o
s_tr_rev.o s_tr_set.o s_tr_swp.o s_fo.o s_fo_out.o s_fo_set.o d_dot.o
d_subckt.o e_base.o e_card.o e_node.o e_model.o e_compon.o e_subckt.o
e_elemnt.o e_ccsrc.o e_storag.o e_cardlist.o bm_model.o bm_value.o
bm_cond.o bm.o c__cmd.o c_attach.o c_file.o c_genrat.o c_prbcmd.o findbr.o
plot.o main.o  -ldl -lreadline -ltermcap

And yes, it works.

% gnucap
Gnucap 2007.02.21 RCS 26.16
The Gnu Circuit Analysis Package
Never trust any version less than 1.0
Copyright 1982-2002, Albert Davis
Gnucap comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome
to redistribute it under certain conditions
according to the GNU General Public License.
See the file "COPYING" for details.


> Option #2 ...
>
> Use the old build system  ./configure.old.
>
> I really should call it the development build system because
> that is the one I use for development.  Autoconf is a big pain.
> I use it for distribution because people expect it, kind of
> like RPM and DEB, and because Dan did the work of setting it
> up.  I don't have the patience to use it for development.  I
> would very much welcome a good replacement for autoconf, and
> know how to spec it and do it, but I am focusing my effort on
> gnucap instead.  If someone wants to do it, I can work with
> them.

Understood, but this issue with link-ordering is independent of configury
or libtoolisms.  The build-system can use whatever works for developers
and users.  (I personally find autoconf suitable for developement.)

For global static initialization ordering, however, I do recommend
something more robust (previous message).  When I have some time, I might
see if l_dispatcher can be re-written to "initialize on-demand".  Any
other pointers on what other global objects are order-critical?

> Anyway ...  that alone won't fix it.  You still need to put
> globals.cc first.

Better yet, take the guess-work out completely, and enforce ordering
programmatically.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
        -- (2400 baud? Netscape 3.0?? lynx??? No problem!)