Re: [Bug-gnucap] building guncap-0.35 in cygwin

[al davis]

On Monday 27 November 2006 17:11, Jon Choy wrote:
>   I'm attempting to do a build in the most recent version of
> cygwin. During the "make", I get the following errors:
>
>
> Making all in modelgen
> make[2]: Entering directory `/home/src/gnucap-0.35/modelgen'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/src/gnucap-0.35/modelgen'
> Making all in src
> make[2]: Entering directory `/home/src/gnucap-0.35/src'
> make[2]: *** No rule to make target `d_bjt.cc', needed by
> `c_getckt.o'. Stop.
> make[2]: Leaving directory `/home/src/gnucap-0.35/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/src/gnucap-0.35'
> make: *** [all] Error 2

The first concern is "Nothing to be done...."  It should compile 
the program there.  It could be that there is "nothing to be 
done" because this is the second try, and it is keeping stuff 
from the first try.

The "no rule to make" line is bewildering.  It tells me that 
there was probably an error in building your custom Makefile.  
I think you meant to say "d_bjt.h" instead of "d_bjt.cc".  If 
not, that is another bewilderment.  Those files are generated 
by running "gnucap-modelgen" on "d_bjt.model".

Probably the best thing to do is to start over, and log all 
output, including what configure says.  Delete the whole 
directory tree, untar it again, then run "./configure"  
then "make", saving all messages in a file.  If that doesn't 
work, wipe clean, start over, and do "./configure.old" 
then "make", again saving everything in a file and see if it 
works this way.

If it still doesn't work, post the output from configure and 
configure.old.  Hopefully that will tell me what is wrong.

If that doesn't tell me, I may ask you for some other files that 
are generated by configure.

I do not have a system running cygwin, so I must rely on people 
like you to know if it works or not.

>   I noticed in the announcement for a November release (which
> I also tried) some statements about the link order being very
> important.
> http://archives.seul.org/geda/dev/Nov-2006/msg00030.html
>
>   Could this be related? 

No.  That comment only applies to the November snapshot.  Please 
try it and let me know!  

If there is a link order problem, it will still compile and 
link, but will have problems when you run it.  It has to do 
with the order of construction of static objects in different 
files.  The link order issue is an artifact of a new mechanism 
to allow for run time dynamic linking of model files.  It is 
part of the infrastructure needed for native compiled 
Verilog-AMS support.