[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Fang
Subject: Re: [Gnucap-devel] gnucap development snapshot 2009-06-11
Date: Sun, 28 Jun 2009 15:12:29 -0400 (EDT)

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/ /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, points a translation unit in the base package. Is 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/ (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.


David Fang

reply via email to

[Prev in Thread] Current Thread [Next in Thread]