[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-user: Using iVerilog with fileio
Hi,
You might want to change your LDFLAGS to be '-G'. Depending on which
linker you're using, -shared may not be accepted... (shared-lib command
on Solaris is: ld -G <objs/libs> -o <shlib>)
Regardless, looks like you're looking at a bit of hacking due to the
missing tf_ functions..
Good Luck,
Matt
On Tue, 2002-09-17 at 11:50, L. Russell-Morris wrote:
> I have been trying to use Chris Spears fileio (http://chris.spear.net/pli/fileio.htm) with iverilog, I currently have the fileio
> working with VCS, and am trying to set up iverilog in the same environment. When I try to compile the fileio into a iverilog
> module, using iverilog-vpi I get:
>
> Compiling fileio.c...
> Making fileio.vpi from fileio.o...
> Text relocation remains referenced
> against symbol offset in file
> vpi_get_value 0xac /usr/local/lib/libveriuser.a(getp.o)
> vpi_get_value 0x5c /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_get_value 0xd4 /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> acc_fetch_tfarg_str 0x4 /usr/local/lib/libveriuser.a(getcstringp.o)
> acc_fetch_tfarg_str 0x0 /usr/local/lib/libveriuser.a(getcstringp.o)
> vpi_scan 0xac /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_scan 0x2c /usr/local/lib/libveriuser.a(a_handle_tfarg.o)
> vpi_scan 0x5c /usr/local/lib/libveriuser.a(putp.o)
> vpi_scan 0x34 /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_scan 0x3c /usr/local/lib/libveriuser.a(getp.o)
> vpi_scan 0x30 /usr/local/lib/libveriuser.a(nump.o)
> vpi_handle 0x8 /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_handle 0x80 /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_handle 0x14 /usr/local/lib/libveriuser.a(a_handle_tfarg.o)
> vpi_handle 0x14 /usr/local/lib/libveriuser.a(getp.o)
> vpi_handle 0x14 /usr/local/lib/libveriuser.a(putp.o)
> vpi_handle 0x8 /usr/local/lib/libveriuser.a(nump.o)
> __assert 0xc4 /usr/local/lib/libveriuser.a(putp.o)
> __assert 0xe4 /usr/local/lib/libveriuser.a(putp.o)
> __assert 0x84 /usr/local/lib/libveriuser.a(a_set_value.o)
> __assert 0x15c /usr/local/lib/libveriuser.a(a_set_value.o)
> __assert 0x1ac /usr/local/lib/libveriuser.a(a_set_value.o)
> __assert 0x1c8 /usr/local/lib/libveriuser.a(a_set_value.o)
> __assert 0x1e4 /usr/local/lib/libveriuser.a(a_set_value.o)
> __assert 0x9c /usr/local/lib/libveriuser.a(putp.o)
> __assert 0x200 /usr/local/lib/libveriuser.a(a_set_value.o)
> __assert 0xbc /usr/local/lib/libveriuser.a(getp.o)
> __assert 0xdc /usr/local/lib/libveriuser.a(getp.o)
> vpi_get 0x34 /usr/local/lib/libveriuser.a(putp.o)
> vpi_get 0x70 /usr/local/lib/libveriuser.a(getp.o)
> vpi_get 0x8c /usr/local/lib/libveriuser.a(getp.o)
> vpi_iterate 0x14 /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_iterate 0x8c /usr/local/lib/libveriuser.a(a_fetch_tfarg.o)
> vpi_iterate 0x14 /usr/local/lib/libveriuser.a(nump.o)
> vpi_iterate 0x24 /usr/local/lib/libveriuser.a(putp.o)
> vpi_iterate 0x20 /usr/local/lib/libveriuser.a(getp.o)
> vpi_iterate 0x20 /usr/local/lib/libveriuser.a(a_handle_tfarg.o)
> <unknown> 0xb4 /usr/local/lib/libveriuser.a(putp.o)
> ....... (lots of unknowns)......
> <unknown> 0x58 /usr/local/lib/libveriuser.a(putp.o)
> vpi_put_value 0x21c /usr/local/lib/libveriuser.a(a_set_value.o)
> vpi_put_value 0x10c /usr/local/lib/libveriuser.a(putp.o)
> <unknown> 0x264 /usr/local/lib/libveriuser.a(a_set_value.o)
> ld: fatal: relocations remain against allocatable but non-writable sections
> collect2: ld returned 1 exit status
>
> When I remove the -shared in the LDFLAGS argument for the linker I get:
>
> Compiling fileio.c...
> Making fileio.vpi from fileio.o...
> Undefined first referenced
> symbol in file
> tf_strgetp fileio.o
> tf_spname fileio.o
> acc_fetch_size fileio.o
> tf_getworkarea fileio.o
> tf_nodeinfo fileio.o
> tf_getrealp fileio.o
> main /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/3.0.4/crt1.o
> tf_message fileio.o
> tf_typep fileio.o
> tf_setworkarea fileio.o
> ld: fatal: Symbol referencing errors. No output written to fileio.vpi
> collect2: ld returned 1 exit status
>
> So it appears to be a library issue. Anyone come accross it before or any ideas?
>
> Thanks,
>
> Lee Russell-Morris
>