Bugzilla Bug 172919

i686-pc-linux-gnu-gcc -DHAVE_CVS_IDENT=1 -I. -I./.. -I..  -DPACKAGE_NAME=\"\"
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_MALLOC_H=1 -DSIZEOF_UNSIGNED_LONG_LONG=8 -DSIZEOF_UNSIGNED_LONG=4
-DSIZEOF_UNSIGNED=4 -DHAVE_DLFCN_H=1  -fPIC -Wall -O2 -march=athlon-mp -pipe
-mmmx -msse -m3dnow -MD -c cadpli.c
mv cadpli.d dep
make[1]: *** No rule to make target `../vvp/libvpi.a', needed by `cadpli.vpl'. 
Stop.
make[1]: Leaving directory
`/var/tmp/portage/sci-electronics/iverilog-0.8.3/work/verilog-0.8.3/cadpli'

Logs coming after creation.

Created an attachment (id=115073) [details]
sci-electronics:iverilog-0.8.3:20070331-190301.log

Created an attachment (id=115074) [details]
/tmp/emerge--info

Thanks for reporting this bug. The problem was in the vvp subdirectory, which
needed an include file that is generally found in the kernel sources. This was
the reason for libvpi.a not being built. As tapping the kernel sources directly
isn't a solution, I have implemented a different fix.

Denis.

*** Bug 188199 has been marked as a duplicate of this bug. ***

Not fixed in stable -> reopen. Please stabilize >=0.8.3

I ran into this problem too.. the problem seems to be that the linux-headers
package does not install /usr/include/asm-generic/memory_model.h or
/usr/include/asm-generic/page.h . I don't understand why the kernel header
package isntalls files into asm-generic, but not these two. I think the fix
would be to change sys-kernel/linux-headers to install these two files along
with the others it already places in that directory.

I just ran into this problem. sci-electronics/iverilog-0.8.4 is in the tree
since 01 Apr 2007 and does not suffer from this problem.

can we please stabilize 0.8.4?

(In reply to comment #7)
> I just ran into this problem. sci-electronics/iverilog-0.8.4 is in the tree
> since 01 Apr 2007 and does not suffer from this problem.
> 
> can we please stabilize 0.8.4?

Agreed. However, I have recently bumped iverilog to version 0.8.6 and since
stabilization seems to be such a long and painful process (even when I provide
a full testing recipe that even a non-specialist can run in a few minutes), I
would prefer to wait a couple more weeks and stabilize 0.8.6 instead of 0.8.4.

Denis.

how about marking 0.8.4 stable NOW and 0.8.6 in a few weeks. This would fix the
stable tree, which shouldn't be broken.

(In reply to comment #9)
> how about marking 0.8.4 stable NOW and 0.8.6 in a few weeks. This would fix the
> stable tree, which shouldn't be broken.

This kind of non-essential and complicated package (for the general audience)
usually takes a lot of time to get stabilized, and I can perfectly understand
that. So I prefer to request stabilization when it makes the most sense only.

I'm currently preparing a testbench to add to the already existing (small)
collection, see [1]. As soon as this is done I'll request stabilization for
0.8.6 even it's a bit ahead of usual schedule.

Denis.

[1] http://dev.gentoo.org/~calchan/sci-electronics/tests/index.xml

nice testbench! I'm looking forward!

Aaaw, I want it fixed! ;)

any news on this one? can we move forward to a working version?

Any progress on this?

I am now using stable, and 0.8.6 is installed and works for me. But after a
check, I keyworded it, so, 0.8.6 may not be in stable. Randall, do you mean you
tried 0.8.3 and it failed ?

to users: keyword iverilog, and install something recent.

to maintainers: please stabilise a recent version.

0.8.3 is ~ ... so, since we have to keyword for unstable, please, try 0.8.6 ,
and forget 0.8.3

This bug has to remain open until something is done in portage.

Demaine, I meant, "Any progress on stabilizing the versions which actually
work?" I haven't actually bothered un-soft-masking the package, but by reading
this bug it sounds like it would work, so I'm not worried about that.

while trying out iverilog-vpi:
mabi@pluto gentoo % cp -r /usr/share/doc/iverilog-0.8.6/examples .
mabi@pluto gentoo % cd examples 
mabi@pluto examples % ls
clbff.v  des.v  hello.vl  hello_vpi.c  hello_vpi.vl  outff.v  pal_reg.v 
show_vcd.vl  sqrt-virtex.v  sqrt.vl  xnf_add.vl  xram16x1.v
mabi@pluto examples % gcc -c -fpic hello_vpi.c 
mabi@pluto examples % gcc -shared -o hello_vpi.vpi hello_vpi.o -lvpi
mabi@pluto examples % iverilog-vpi hello_vpi.c                      
Compiling hello_vpi.c...
Making hello_vpi.vpi from  hello_vpi.o...
mabi@pluto examples % ./hello_vpi.vpi 
[1]    15053 segmentation fault  ./hello_vpi.vpi
mabi@pluto examples % 

Is that expected? some testbench i can run?

problem also occurs with stable version sci-electronics/iverilog-0.8.2 and a
kernel 2.6.27-gentoo-r8