gEDA-user: New gnucap development snapshot

[Colin Hall]

On 10 Dec 2006, at 5:56 am, al davis wrote:

> On Saturday 09 December 2006 05:23, Colin Hall wrote:
>> [iMacG4:~] cgh% which gnucap
>> /Users/cgh/bin/gnucap
>>
>> I tried to run it:
>>
>> [iMacG4:~] cgh% gnucap
>> incorrect link order
>> Abort
>> [iMacG4:~] cgh%
>>
>> Looks like the Mac OSX loader failed. I thought I would send
>> this before investigating the load error any further.
>
> To help me .. Tell more about what you have, in particular:
>
> 1. The compiler version "g++ --version" if you are using the gnu
> compiler, otherwise what are you using?

[iMacG4:~/gnucap-2006-12-04] cgh%
[iMacG4:~/gnucap-2006-12-04] cgh% g++ --version
g++ (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495)
Copyright (C) 2002 Free Software Foundation, Inc.

>
> 2. The actual text spew you get from "configure" and
> from "make", especially the link stage, which is probably the
> last "g++" command, the one that lists all the files.

[iMacG4:~/gnucap-2006-12-04] cgh% make install > make_install_out.lg
g++: unrecognized option `-rdynamic'
g++: unrecognized option `-rdynamic'
[iMacG4:~/gnucap-2006-12-04] cgh%

Here's the link phase from that re-directed stdout:

g++  -g -O2  -rdynamic -o gnucap   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  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 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 d_admit.o d_cap.o d_cccs.o d_ccvs.o d_coil.o d_coment.o 
d_cs.o d_dot.o d_logic.o d_logicmod.o d_res.o d_subckt.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 bm_cond.o bm_model.o bm_value.o bmm_table.o 
bmm_semi.o bm.o c__cmd.o c_attach.o c_comand.o c_delete.o c_fanout.o 
c_file.o c_genrat.o c_getckt.o c_list.o c_modify.o c_nodset.o c_param.o 
c_prbcmd.o c_status.o c_sweep.o c_sim.o c_system.o findbr.o plot.o 
main.o globals.o  -ldl -ltermcap

The configure output is large. Would you like me to email it to you?

>
> Thanks for the report.

You're welcome. I found your November post on the dev list predicting 
this, explaining the reasons for the run-time error. I understand that 
the problem is with static initialisation when the initialisation code 
is from multiple translation units.

>> My first port of call would be to take Fink off the path,
>> re-configure and re-build.
>
> Fink has nothing to do with it.

Agreed, a red herring, my apologies.

Regards,
Colin.