[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gEDA-user: iverilog main.cc undefined reference using --host=mingw32
Previous thread name:
Re: gEDA-user: Re: [Mingw-users] Re: make: strip command can't find file
Hello,
I hope I'm not sending this twice. I haven't seen it pop up in the mailing
list; on closer inspection, it looks like I only sent it to myself on
Saturday afternoon. I hadn't quite thrown in the towel....here's the "last gasp"
in trying to solve the error messages associated with "configure --host=mingw32"
in getting iverilog working on my biggish design (it works fine on a small
toy design of mine).
All those names that are undefined, they appear in ...../mingw/include/getopt.h .
From the errors, it seems that main.cc does not include getopt.h . There are
only main.cc files in the source directories ..../iverilog-0.5 and ...../iverilog-0.5/vvp .
The Makefile's in both directories contain pattern rules to make main.cc, and
both files conditionally include getop.h if IF_GETOPT_H is defined. It is defined
in config.h, which occurs in both directories containing main.cc, despite the
fact that config.h.in undefines them. From their timestamps, it seems that the
"configure" step sets up config.h to define IF_GETOPT_H after finding that
getop.h exists. Since both main.cc files include config.h, it means getopt.h
is being included in their compilations. All this indicates to me is that the
error messages should not be there.
Anyway, that's it. I lay the issue to rest now. Who knows, maybe using
"config --host=mingw32" isn't even the right way to go about this; it was just
another thing to try to see if I can get around the first set of errors (below).
If a curious hacker with the same system as mine (and same problem) wants
to take a wack at it, I would be very interested in the outcome. For now,
everyone gets a break from my persistant rantings in trying to get "functional"
on my design.
Fred
--------------------------------------------------------------------------
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada K1S 5B6
fma@doe.carleton.ca
==========================================================================
"Shing-Fat (Fred) Ma" wrote:
> Actually, despite the seemingly newbie questions I've been posting about
> making iverilog, my unix background is better than my windows background.
> Even so, it's been quite the challenge to learn all the stuff to troubleshoot my
> installation. In fact, I would have been quite happy to use the precompiled
> binaries for Win32, but I ran into the problem described as Question 2 in
> http://www.seul.org/archives/geda/user/Oct-2001/msg00008.html . This
> renewed attempt is to compile with mingw and cygwin together. I've been
> pretty niggly about making "make check" work first because when things
> go wrong, I haven't much idea how to troubleshoot it, just bang away at
> any possibility after reading as much as I can.
>
> Regarding renaming hello.vl to hello.v, it was trivial but necessary because
> there were many references within the Makefile(s?) to hello.v, but there
> only existed hello.vl.
>
> I found my mistake in not being able to compile hello.v outside of the
> source directory. Basically, it's in the man pages. I needed to invoke
> vvp on the resulting output file, *not* merely invoke the output file directly, as
> I was trying to do. This worked fine on hello.v, but I get the same meaningless
> popup window error as Question 2 in
> http://www.seul.org/archives/geda/user/Oct-2001/msg00008.html when I
> try it on my big design. There is absolutely no information provided at all, so I
> think it's just a windows message responding to some violation of integrity of
> sorts.
>
> So I tried "-tvvm" to get a "more complete" executable output file. This still caused
> a failure, but a cleaner and more informative failure, with the assertion message
> mention in your bug report page. But I can't submit it because it deals with
> nonpublic stuff. The command line contains quite a few filenames and
> path components whose publicization would ruffle local feathers, even though
> the technical details are not contained in the filenames themselves. The output
> is as follows, with some stuff renamed to avoid sensitivity issues.
>
> PARSING INPUT ...
> ELABORATING DESIGN -s topmod_tb ...
> RUNNING FUNCTORS ...
> -F cprop
> -F nodangle
> CODE GENERATION -t vvm ...
> Assertion failed: expr->lsi() == 0, file t-vvm.cc, line 959
>
> abnormal program termination
> C:/MINGW/BIN/../lib/gcc-lib/mingw32/2.95.3-6/../../../libmingw32.a(main.o)(.text+0x8d):main.c: undefined reference to `WinMain@16'
> translate: C:\CYGWIN\USR\LOCAL\lib\ivl\ivlpp -v -L -Ic:/cygwin/home/unknown/Applications/XXXX/V1R3/vlib c:/cygwin/home/unknown/Applications/XXXX/YYY/zzzz/_blahblah.v c:/cygwin/home/unknown/Applications/XXXX/YYY/zzzz/_blehblar.v c:/cygwin/home/unknown/Applications/XXXX/YYY/zzzz/bloo.blum.v c:/cygwin/home/unknown/Applications/XXXX/YYY/zzzz/Blarrr_bluhhhh.v VlogFiles/Misc.v VlogFiles/TwidGetter.v VlogFiles/BfyIPadrsGenr.v VlogFiles/topmodule.v VlogFiles/topmodule_tb.v | C:\CYGWIN\USR\LOCAL\lib\ivl\ivl -v -tvvm -Fcprop -Fnodangle -fVPI_MODULE_PATH=C:\CYGWIN\USR\LOCAL\lib\ivl -otopmod_tb.vvm.cc -- -
> compile: c++ -s -fno-exceptions -o topmod_tb.vvm -IC:\CYGWIN\USR\LOCAL\lib\ivl\..\..\include -LC:\CYGWIN\USR\LOCAL\lib\ivl\.. topmod_tb.vvm.cc -lvvm -lvpip
>
> I tried a smaller example design, but couldn't duplicate the either of the
> errors associated with the vvp and vvm targets ie. both worked fine for the
> smaller design.
>
> I scoured the webpages again, and decided to try --host=ming32 in the
> configure step, but the "make" step fails with the errors
>
> c++ -o ivl.exe ivl.exp main.o cprop.o design_dump.o dup_expr.o elaborate.o elab_expr.o elab_lval.o elab_net.o elab_anet.o elab_pexpr.o elab_scope.o elab_sig.o emit.o eval.o eval_rconst.o eval_tree.o expr_synth.o functor.o lexor.o lexor_keyword.o link_const.o mangle.o netlist.o netmisc.o net_assign.o net_design.o net_event.o net_force.o net_link.o net_modulo.o net_proc.o net_scope.o net_udp.o pad_to_width.o parse.o parse_misc.o pform.o pform_dump.o set_width.o verinum.o verireal.o target.o targets.o util.o Attrib.o LineInfo.o Module.o PDelays.o PEvent.o PExpr.o PGate.o PTask.o PFunction.o PWire.o Statement.o nodangle.o synth.o syn-rules.o xnfio.o t-dll.o t-dll-api.o t-dll-expr.o t-dll-proc.o t-vvm.o t-xnf.o
> main.o: In function `main':
> //c/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/std/bastring.h:178: undefined reference to `optarg'
> main.o: In function `main':
> //C/cygwin/home/unknown/INSTALLS/verilog-0.5/main.cc:191: undefined reference to `optarg'
> main.o: In function `main':
> //c/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/std/bastring.h:178: undefined reference to `optarg'
> main.o: In function `main':
> //C/cygwin/home/unknown/INSTALLS/verilog-0.5/main.cc:205: undefined reference to `optarg'
> //C/cygwin/home/unknown/INSTALLS/verilog-0.5/main.cc:208: undefined reference to `optarg'
> main.o://c/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../include/g++-3/std/bastring.h:232: more undefined references to `optarg' follow
> main.o: In function `main':
> //C/cygwin/home/unknown/INSTALLS/verilog-0.5/main.cc:257: undefined reference to `getopt'
> //C/cygwin/home/unknown/INSTALLS/verilog-0.5/main.cc:294: undefined reference to `optind'
> //C/cygwin/home/unknown/INSTALLS/verilog-0.5/main.cc:317: undefined reference to `optind'
> c:\mingw\bin\make.exe: *** [ivl.exe] Error 1
>
> Anyway, this is probably not enough detail for anyone to comment meaningfully on,
> but it's what I can provide. If by chance someone can offer their thoughts on this,
> it would be very welcome. But in the mean time, I think I'll take a break from banging
> at this, partly because I think I've exhausted my options with my current level of
> knowledge, and partly because my buns are in the fire to do stuff. When I get a 2nd
> wind, I'll probably look at the possibility that the path names are a problem (some
> contain more than one dot, some are more than 8 characters long). If that has to
> change, it could pose compatibility problems with the current setup on solaris. Also,
> even if this effort had been successful, there is also the additional hurdle of getting
> gtkwave installed on windows (or cygwin + mingw).....the author has kindly added
> some functionality I was looking for, which compiled fine on solaris, but there's no
> guarantee that I won't run into issues like the above when trying to compile it on
> my laptop.
>
> Fred
>
> --------------------------------------------------------------------------
> Fred Ma
> Department of Electronics
> Carleton University, Mackenzie Building
> 1125 Colonel By Drive
> Ottawa, Ontario
> Canada K1S 5B6
> fma@doe.carleton.ca
> ==========================================================================
>
> Stephen Williams wrote:
>
> > fma@doe.carleton.ca said:
> > > For any interested parties that might try this in the future, I'll
> > > just summarize what worked on to some degree:
> >
> > This seems way more complicated then it ought to be, so I think
> > there are some bugs to fix.
> >
> > I must admit that I haven't tried to debug the "make check" rule,
> > and the mingw.txt instructions skip that and go on to the install
> > assuming the build is OK.
> >
> > The resulting binary is a Windows (DOS) binary, so it doesn't know
> > of or generate UNIX style directory separators. That is intentional
> > as most Windows users of Icarus Verilog are in fact Windows users
> > in general, for better or for worse.
> >
> > Also, I concede that I assume that most Windows users are not the
> > least bit interested in compiling Icarus Verilog, and are instead
> > going to use the installer. Therefore, the compile process for the
> > Windows environment is not necessarily as slick as the UNIX compile.
> > Hell, even MacOS users are *far* more likely to want to compile
> > from source:-)
> >
> > Patches are welcome.
> >
> > * To pass "make check", I changed all references to hello.vl and sqrt.vl
> > to hello.v and sqrt.v, then renamed *.vl files to *.v (can't remember which
> > files, but suffice to say all the Makefile's)
> >
> > I can't imagine why this would make a difference.
> > --
> > Steve Williams "The woods are lovely, dark and deep.
> > steve at icarus.com But I have promises to keep,
> > steve at picturel.com and lines to code before I sleep,
> > http://www.picturel.com And lines to code before I sleep."