Re: [Gnucap-devel] gnucap development snapshot 2009-06-11

[David Fang]

Hi Al,
	I've started to build the bsim plug-ins for gnucap, and ran into 
some issues that could use clarification.

In BSIM3v301:

g++ -O2 -g -I. -I../Include -DTRACE_UNTESTED -DSPICE_3e -DPREDICTOR 
-DHAS_STDLIB -fPIC -I../Gnucap -Wall -Wextra  -c 
../Gnucap/spice-wrapper.cc
/usr/include/stdlib.h:226: error: declaration of C function 'int 
setenv(const char*, const char*, int)' conflicts with
../Include/cpstd.h:54: error: previous declaration 'void setenv()' here
make: *** [spice-wrapper.o] Error 1

is caused by:

#ifndef linux
extern void setenv();
#endif /* linux */

Barrage of questions :)

Usage model:
In the plug-in source, spice-wrapper.cc points a translation 
unit in the base package.  Is spice-wrapper.cc shared among multiple 
plug-ins? Do you plan to require that the base package's source be 
unpacked and present for building plug-ins?  or do you also plan to 
support building plug-ins against an installed base package?  It looks 
like a good subset of the files in <base-package>/src would be 
appropriately installed to $(pkgincludedir).  A bin_SCRIPT like 
gnucap-config could direct a plug-in build to look in the right place for 
header files (I can draft such a script for you).  Can you list for me 
which .cc .h files would be appropriate to install from the base package?

Regarding the setenv() issue above, constructs like #ifndef linux are 
usually dubious.  Would it be acceptable to just include <stdlib.h> or 
(<cstdlib> of C++ convention)?  I know it bloats the preprocessing, but it 
would help to keep things more portable.  Is it your intent to NOT have 
the users re-run any sort of configure step for the plug-ins?  If so, it 
is possible to re-use the results of the base-package's configuration for 
plug-in complations, e.g. installing config.h as gnucap-config.h.  This 
way, plug-in builds already look configured, so a common boilerplate 
Makefile will suffice.  Or the configure phase would be trivially short, 
just setting path/prefix variables.

The shared-library flag issue on Mac OS X 
("powerpc-apple-darwin8-g++-4.0.1: unrecognized option '-shared'") was 
address in another thread, so I won't repeat it here.  For ease of 
portability, I propose using libtool for plug-ins in the following manner:

* From the base-package install the configured 'libtool' script as 
'gnucap-libtool', so that plug-in builds need not re-run the configuration 
detection steps for libtool that were done for the base package.  The new 
plug-in boilerplate Makefile will wrap all compilations through this 
script, much like the libtoolized-automake commands LTCOMPILE and 
LTCXXCOMPILE in src/Makefile.in. (I should probably write up such a 
Makefile to make it clear.)  Compilation will produce both .o and .lo 
object files for the gnucap-libtool script to handle.  The link step 
should produce .la and libs/*.so for every plug-in.  The said plug-ins can 
be used in-place (uninstalled), and after installation.  (The subtle 
differences due to run-paths are handled by libtool --finish, upon 
installation.)

I'll start by modifying the base-package to perform some of the above 
actions.  (BTW, did you get a chance to test out last week's autotools 
updated patch I sent?)

This may require a few tries for me to get right, but hopefully discussion 
and feedback will keep things straight.

Fang

David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/