Windows Build[]
Somewhere it should be made clear that the Mingw port is the preferred means of building for Windows. I have detailed instructions for the Mingw build in the mingw32.txt file that comes with the source. A Mingw Build page should either point to that file in the source bundle, or we should write a Wiki page and seed it with the contents of that file.
--Stevewilliams 17:10, 26 October 2006 (UTC)
I was wondering why cygwin is effectively deprecated? I also think the latest patch I submitted for cygwin removed the requirement for the ps2pdf program (since cygwin has a working man page system I removed pdf creation).
--Cary 01:21, 16 February 2007 (UTC)
Reasonable question. I've reworded the Cygwin section to be somewhat less pessemistic. The main reason for preferring the mingw32 build is that it is the preferred distribution format, but the Cygwin build does have uses, and should be expected to work.
Feel free to improve the Cygwin build instructions as you see fit.
Stevewilliams 04:52, 16 February 2007 (UTC)
Repositories of Prepackaged Sources[]
Icarus Verilog is starting to show up in 3'rd party package repositories. For example, Icarus Verilog is available for MacOSX via Fink, and aparently macports. We might want to create a section for listing these repositories (possibly with reviews), and also lobby for more.
--Stevewilliams 17:15, 26 October 2006 (UTC)
That chapter now exists on this page and titled Installation From Premade Packages. Please lets use it. Some content may need to be moved.
--Stevewilliams 18:28, 30 October 2006 (UTC)
The macports and fink install process should be moved to the "Prepackaged..." section, seperated from the "build by hand" instructions.
--Stevewilliams 21:32, 3 November 2006 (UTC)
Should the RedHat/Fedora section in "installing from source" be dropped as a duplicate? Building from a src rpm belongs in the PreMade Packages section, but it seems to be already covered there by the "other rpm based..." subsection. The duplicate should be removed, I think.
--Stevewilliams 21:38, 3 November 2006 (UTC)
There should be one section for RPM-based systems. Steve, could you provide some instructions on how to build the .src.rpm file using source obtained from CVS?
Reformatting[]
I think the <hN></hN> tags and other html formatting should be replaced in favor of th mediawiki markup syntax. Also, the example code should be replaced with unformatted boxes. This is to be consistent with the rest of the formatting in this wiki.
--Stevewilliams 04:33, 30 October 2006 (UTC)
Ubuntu Linux install instructions need testing[]
I moved this sub-section into the "prepackaged" section and attempted to reformat it to be consistent with other instructions. Unfortunately, I'm not 100% sure I didn't mess it up. Please drop a note here if it is still OK. (Or maybe fix it:-)
--Stevewilliams 01:07, 1 November 2006 (UTC)
I have Ubuntu (Dapper Drake 6.06 LTS) on my laptop and the following command installed verilog (0.8-3build1)
sudo apt-get install verilog
from the dapper universe repository which was enabled earlier. I suppose if you use synaptic it could be as simple as search, point and click... One can setup the repositories in synaptic (frontend to apt tools).
HTH [Shashikiran Ganesh]
I am using Hardy Heron (8.04) and it worked for me. The universe repository was already enabled so I only had to do sudo apt-get install verilog . --Gabe
I'm using Ubuntu 11.10 (Oneiric Ocelot). There was no need to edit the sources since the universe repository is already included. I only typed sudo apt-get install iverilog and it worked. - LA80.212.76.52 14:15, February 11, 2015 (UTC)
I'm using Ubuntu 12.04 (Precise). Works straight out of the box as reported by LA above. 11 February 2015 - baard80.212.76.52 14:15, February 11, 2015 (UTC)
I'm using Ubuntu 18.04 (Bionic Beaver). I added the PPA lines to my sources.list and the repository key with "sudo apt-key ...". I got an error having something to do with the key when I tried "sudo apt-get update", but I guess it's ok because "sudo apt-get install verilog" went just fine.
Duwaar (talk) 18:14, January 25, 2019 (UTC)duwaar
Solaris Build Instructions (Updated June 12th 2010)[]
Someone needs to flesh out the Solaris build instructions. I've filled in the basics for the tools, but someone who actually uses Solaris should help fill out details on how to get the right tools and how to use them.
Stevewilliams 16:06, 13 February 2007 (UTC)
- I have provided the instructions below ... email me ssingh aa tt uwaterloo dottttt ca if you need to talk to me.
==
I built iVerilog 0.9.2 on a Sun UltraSPARC Solaris 10 system with these additional packages. The additional information below each SunFreeware package is from the pkginfo "-l" (letter "l") switch followed by the name of the package.
application SMCbison biso PKGINST: SMCbison NAME: bison CATEGORY: application ARCH: sparc VERSION: 2.4.2 BASEDIR: /usr/local VENDOR: FSF
application SMCcoreu coreutil
PKGINST: SMCcoreu NAME: coreutils CATEGORY: application ARCH: sparc VERSION: 5.97 BASEDIR: /usr/local VENDOR: FSF
- The GNU versions of common Unix utilities are needed because the Makefiles use argumentation that is specific to those versions, so these need to be installed and in the path in order for configure to find them and reference them when generating Makefiles. Also, I used an older version because the more recent package versions are built to go looking for a particular version of libsec.so.1 which is not the same as the one /usr/lib/libsec.so.1 and it fails. So I just went on a hunch and used an older package set and hoped that it would still compile, and it did.
application SMCflex flex
PKGINST: SMCflex NAME: flex CATEGORY: application ARCH: sparc VERSION: 2.5.35 BASEDIR: /usr/local VENDOR: FSF
application SMCgcc gcc
PKGINST: SMCgcc NAME: gcc CATEGORY: application ARCH: sparc VERSION: 3.4.6 BASEDIR: /usr/local VENDOR: FSF
- This is an older version of GCC, being version 3, while most people are using GCC 4, but the runtimes will likely also work for older releases of Solaris, if iVerilog compiled successfully, which it did. While I compiled this on a Solaris 10 system, I also plan to test the binaries on a Solaris 8 system and if they work OK, then it means that others can donwload the pre-compiled binaries and use them on Solaris 8 and earlier systems, as long as they download at least the 3.4.6 runtimes from SunFreeware.
application SMCliconv libicon
application SMClintl libintl
I believe these are needed because utilities like flex and bison and others link against these libraries, but iVerilog itself does not use them. So it should not be necessary to download and install these if one only wants the binaries.
application SMCm4 m4
PKGINST: SMCm4 NAME: m4 CATEGORY: application ARCH: sparc VERSION: 1.4.14 BASEDIR: /usr/local VENDOR: FSF
application SMCmake make
PKGINST: SMCmake NAME: make CATEGORY: application ARCH: sparc VERSION: 3.81 BASEDIR: /usr/local VENDOR: FSF
==[]
I tuned the GCC flags for UltraSPARC with this stuff in .cshrc:
setenv CPPFLAGS "-O3 -mcpu=v9 -mtune=ultrasparc -m32" setenv CXXFLAGS "-O3 -mcpu=v9 -mtune=ultrasparc -m32" setenv CFLAGS "-O3 -mcpu=v9 -mtune=ultrasparc -m32" setenv LDFLAGS "-R/lib -R/usr/lib -R/usr/local/lib -R /opt/lib -R/usr/openwin/lib-L/lib -L/usr/lib -L/usr/local/lib -L/opt/lib -L/usr/openwin/lib"
I configured with:
configure --prefix=/opt/verilog-0.9.2
NOTE the following:
Warning: No suitable gperf found.
The gperf package is essential for building ivl from
CVS sources, or modifying the parse engine of ivl itself.
You can get away without it when simply building from
snapshots or major releases.
I elected not to worry about this since I am building from a tarball release and not CVS.
A sample compilation line during a make looks like this:
g++ -DHAVE_CONFIG_H -I. -I. -O3 -mcpu=v9 -mtune=ultrasparc -m32 -Wall -O3 -mcpu=v9 -mtune=ultrasparc -m32 -MD -c main.cc -o main.o
When all is said and done you should just be able to type: "make install" and have it copy and chmod files to /opt/verilog-0.9.2 and then just update your PATH and you're good to go.
Optionally, you might want to run /usr/ccs/bin/strip to reduce the file sizes, by stripping out the symbol table information but this is only if you're a real perfectionist. But do NOT use the GNU strip command. It will corrupt the binary and you will not be able to run them, and you will have to recompile.
The git repository instructions are weak[]
I know that the git instructions are weak. I'm struggling with a bit of a learning curve of my own here, so I'm open to suggestions.
MacOS X 10.4.11 install from binaries[]
"./configure" script runs successfully, but "make" prints this:
Using ./version.h for VERSION_TAG
bison --verbose -t -p VL -d -o parse.cc ./parse.y
./parse.y:4182: invalid input: ;
make: *** [parse.h] Error 1
- The proper place to request support is the bugs database. Please go to the Icarus Verilog home page and follow the links to the bug tracking system on sourceforge and submit your report there. Stevewilliams 05:17, 3 October 2008 (UTC)
This is probably not a bug but a result of the arcane version of flex/bison in 10.4 Tiger. Updating to flex, bison and m4 to 2.5.35, 2.4 and 1.4.14 (or probably later) respectively solves the issue. On Tiger these reside in /usr/bin but ./configure will default to /usr/local/bin. Brian Dam Pedersen 2 March 2010
Build instructions in "git" section[]
I think there is no use putting compile steps in the "git" section because the instructions for building will vary for the system where you are building. So that is why I'm removing the little sequence of build instructions from that section.
Stevewilliams 03:33, 13 January 2009 (UTC)