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 attachment 115073 [details] sci-electronics:iverilog-0.8.3:20070331-190301.log
Created attachment 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
Try 0.9.1.
I don't remember why I CC'd myself for this bug, but iverilog-0.8.6 seems to build now (on a new amd64 system). I wish you success fixing this. :)
After unmasking, compiled ok.
