sbmlsolver-discuss — support and discussion for the SBML ODE Solver Library

Re: [SOSlib-discuss] sink reactions

[Rainer M. <ra...@tb...>]

Michael Lawrence wrote:
> I just posted a bug to the tracker about apparent lack of support for 
> sink reactions (those with only reactants). See e.g. the behavior of HG 
> in BIOMD0000000015. Does not match up with the expected.

Hi Michael,

SOSlib should actually handle sink (and creation) reactions correctly.

Do you mean HX? I can't find HG in the model.

You are right, that the default version of BioModels #15 simulated in 
SOSlib (both version 1.6.0 and current CVS) does not reproduce e.g. 
figure 2 in the publication or the online simulation results at 
biomodels database showing species HX.

However, for figure 2 the initial concentration of PRPP has been 
increased from 5 to 50 uM.

If I increase PRPP accordingly in the SBML from 5.01742 to 50.1742, I 
can reproduce the published results (dashed line for GMA version), both 
with SOSlib v1.6.0 and current CVS.

Can you confirm this or did you mean another error?

Thanks,
Rainer

> 
> Thanks,
> Michael
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] sink reactions

[Michael L. <mfl...@fh...>]

I just posted a bug to the tracker about apparent lack of support for sink
reactions (those with only reactants). See e.g. the behavior of HG in
BIOMD0000000015. Does not match up with the expected.

Thanks,
Michael

[SOSlib-discuss] libSBML xml library

[Rainer M. <ra...@tb...>]

Hi,

libSBML has changed its default xml library on linux to libxml2 which is 
not accounted for in our current configure routine. SOSlib configure fails 
because the test program for libSBML uses either -lxerces-c or -lexpat 
linking flags.

question: is there any need at all for these flags? we don't use any 
functions from the xml library, and for me configure and compilation with 
libxml2 works without any flag (remove all -lxerces-c from config/sbml.m4 
or from configure). Can we completely leave out this flag or is it 
required for some architectures, or e.g. if the xml library is installed 
at a location different from one of the other libs and is thus not part 
of the -I  and -L path values? For the latter case, we could have no flag 
as default, but xml library flags could be added optionally.

Rainer

Re: [SOSlib-discuss] [SOSlib-devel] [ sbmlsolver-Bugs-1924288 ] Only one timepoint

[Rainer M. <ra...@tb...>]

Hi Gabriel,

The 1.6.0 version requires SUNDIALS 2.1.1. This is mentioned here:

http://www.tbi.univie.ac.at/~raim/odeSolver/doc/installGnu.html

but unfortunately not in the README/INSTALL instructions of the 
distribution (as back then, 2.1.1 was the latest version). Sorry for that.

Please could you try to remove the new version of SUNDIALS from your 
include and lib directories (maybe they have a make uninstall ?), 
install the 2.1.1 version, and then try again to compile SOSlib 1.6.0?

Alternatively, you could go for the CVS version of SOSlib which should 
run quite stable and compile easier then 1.6.0.

However, this requires the SUNDIALS 2.3.0 which you already have BUT 
also libSBML 3.2.0 (latest). In this case, please make sure to 
completely remove the old libSBML headers before installing SOSlib!!!

The CVS version has a couple of nice new features and should also run 
much faster for large models, if you use the compile option (-c for 
command-line, CvodeSettings_setCompileFunctions(settings, 1) for library 
use).

Unfortunately, we don't know yet when the next official release will 
happen :( but there should be few changes left with respect to current CVS.

Please let us know (either email me personally or the sbmlsolver-discuss 
list, see CC address) if you run into further problems!!

best regards,
Rainer









SourceForge.net wrote:
> Bugs item #1924288, was opened at 2008-03-24 13:23
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=744811&aid=1924288&group_id=139893
> 
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: solver malfunction
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Gabriel Plantat (gabrieljps)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Only one timepoint
> 
> Initial Comment:
> Hello,
> I have in fact two problems, and i think that i need the solution to only one of them :)
> I'm trying to install the verison 1.6.0 on a Kubuntu (Linux) operating system. I have installed the libsbml.2.3.4 (compiled with the expat library) and sundials.2.3.0 libraries in a local directory, and when i compile the SBML_odeSolver, it crashes. I have set the --with-libsbml option to the directory where the libraries are, and it produces the error:
> 
> checking for SBML Library Version... expr: syntax error
> expr: syntax error
> expr: syntax error
> ./configure: line 4175: test: -eq: unary operator expected
> configure: found SBML Library Version
> checking correct functioning of SBML... yes
> ./configure: line 4278: test: -eq: unary operator expected
> checking correct functioning of SUNDIALS CVODE... no:
>                    CFLAGS=-g -O2 -I/home/gabrieljps/trabajos/synthbio2/genetdes_3.0//include
>                    LDFLAGS= -L/home/gabrieljps/trabajos/synthbio2/genetdes_3.0//lib
>                    LIBS= -lsundials_kinsol -lsundials_cvodes -lsundials_cvode -lsundials_nvecserial -lsundials_shared -lm
> configure: error: Can not link to SUNDIALS CVODE Library
> 
> 
> 
> If i change the directory to where the files .so are (the same directory with a /lib appended), it gives this error:
> 
> checking for SBML Library Version... configure: found SBML Library Version 2.3.4
> checking correct functioning of SBML... no:
>                    CFLAGS=-g -O2 -I/home/gabrieljps/trabajos/synthbio2/genetdes_3.0/lib/include -I/home/gabrieljps/trabajos/synthbio2/genetdes_3.0/lib/include/sbml
>                    LDFLAGS= -Wl,-rpath,/home/gabrieljps/trabajos/synthbio2/genetdes_3.0/lib/lib -L/home/gabrieljps/trabajos/synthbio2/genetdes_3.0/lib/lib
>                    LIBS= -lxerces-c -lsbml
> configure: error: Can not link to SBML Library:
>                   Please, make sure to use libSBML version >= 2.3.2
> 
> 
> So i began using the 1.6pre version, which compiles. But doesn't seem to be working properly. I have tried the integrate exemple file with the MAPK.xml file, and when i expect all the results from the integration, it just gives me one time. I have printed the results->timepoints variable and it is set to 1.
> Even further, in this file the third parameter to be given is supposed to be the number of time steps, but if the number of steps is greater than the ending time, it crashes. On the contrary, if it is not, it doesn't, even if the number of steps is lower than 1 (0.1 for exemple)! 
> Anyway, i have used the MAPK.xml file given as an exemple with the library, and i get only the initial conditions, and no other point of the integration.
> 
> I think that if i can integrate the function or intall the 1.6.0 version, i will have the problem solved. Thank you for your help!
> 
> Gabriel PLANTAT.
> Ecole Polytechnique's student.
> gab...@gm...
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=744811&aid=1924288&group_id=139893
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

Re: [SOSlib-discuss] Model compiling on AIX now working and some questions

[Rainer M. <ra...@tb...>]

Hi Eric,

yes to both questions: an odeModel_t structure is only compiled once, 
and is reused for subsequent integrations (or for all 
integratorInstances which are based on this model!) and setVariableValue 
can be used as normal.

sensModel_t is independent from odeModel_t, and the corresponding 
functions are compiled when sensitivity is activated. I am not sure 
about recompilation of these, i.e. to which extend it is recognized that 
a specific sensitivity structure is already existing. It might be that 
this is still on the todo list and sensitivity is recompiled on every 
run. Let me know if this should be done sooner.

Thanks for all the AIX patches. We would probably like to contact to you 
before the next official release to check whether we made all changes 
correctly for AIX.

BTW, we are currently working on an internal compiler for the functions, 
but for now it only works on 32bit architectures and is not implemented 
in CVS yet.

Thanks,
Rainer




Eric Fernandez wrote:
> Hi,
> 
> I have managed to make SOSlib compile SBML models under AIX (using gcc),
> and the gain in solving seems very significant. However, it comes with a
> penalty overhead: the time to compile very large models. 
> 
> Once a model has been compiled the first time, is it possible to reuse
> the compiled file for several simulations using the same model?
> 
> Is it also possible to change a variable value using
> IntegratorInstance_setVariableValue(ii,varindex,val) ?
> I'll send the patch very soon; that was not very difficult to correct
> actually.
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] Model compiling on AIX now working and some questions

[Eric F. <efe...@ph...>]

Hi,

I have managed to make SOSlib compile SBML models under AIX (using gcc),
and the gain in solving seems very significant. However, it comes with a
penalty overhead: the time to compile very large models.=20

Once a model has been compiled the first time, is it possible to reuse
the compiled file for several simulations using the same model?

Is it also possible to change a variable value using
IntegratorInstance_setVariableValue(ii,varindex,val) ?

I'll send the patch very soon; that was not very difficult to correct
actually.

Eric

[SOSlib-discuss] Compiling SOSlib under AIX5.3 WAS: advice

[Eric F. <efe...@ph...>]

> -----Original Message-----
> From: sbm...@li...
[mailto:sbmlsolver-
> dis...@li...] On Behalf Of Kevin Stratford
> Sent: 14 January 2008 18:19
> To: sbm...@li...
> Subject: [SOSlib-discuss] advice[Scanned]
>=20
>=20
> Dear All,
>=20
> I am interested in using the SBML_odeSolver library as part
> of a project on which we will want to deploy it on a number
> of different Unix systems (e.g, AIX and various others).
>=20
> I am currently intending to use libsbml-3.0.3, sundials-2.3.0,
> along with a version of 'libSoS'. However, there appear to
> be a number of issues with the configure / build process
> (at least under AIX 5.3) with both the 1.6pre release and
> the latest cvs.
>=20

Hi Kevin,

This is exactly the configuration I have, and I can advise you.

Firstly, I faced many problems with the IBM compilers (xlc/xlC) and I
strongly suggest you use GNU tools to build the libraries and software.
It was possible for me to compile using xlc (requiring Makefile patching
usually, as xlc does not accept the same switches than gcc), however,
sundials performance was significantly reduced compared to the code
generated with gcc! I did not have time to investigate this issue
though.

Moreover, if GNU is installed from packages on your AIX system, it will
be probably an old version (rpms distributed with AIX were usually
gcc-3.2.2, tar 1.13, etc...) Don't use it. I had to install my own GNU
toolset from source and stick with it. Using the old gcc leads to
linking issues when compiling latest cvs versions of libsbml and soslib.

I first decided to install the software in my own work directory, I used
the shell bash and adjusted the environment variables accordingly, eg:
PREFIX=3D/path/to/work/local  <-- where I put my software
PREFIXGNU=3D/path/to/work/gnu <-- where I put GNU tools
I then used $PREFIX/$PREFIXGNU for the ./configure --prefix=3D

The first step is to install and compile tar 1.19. tar 1.13 which is
provided with AIX is not able to untar correctly gcc archive (beware,
1.13 actually seems to work, but you would get file-not-found errors
during  compilation! I reported this to the gcc ML.)

As you might be aware, you need to use gmake and not the IBM make to
compile the software. I therefore installed my own -latest- make 3.81,
can't do evil.

Then uncompress gcc-4.2.2 and compile according to the instructions (e.g
use a separate folder for compilation, etc). It should compile and
install without problem. FYI, I used these configuration options:
--enable-threads --enable-languages=3Dc,c++
--prefix=3D/hpc/work/fernandz/gnu --enable-threads --disable-shared
--enable-version-specific-runtime-libs --disable-nls

Adjust your environment variables: eg for bash:
export CC=3Dgcc
export CXX=3Dg++
export F77=3Dxlf_r
export TMPDIR=3D~/User-Tmp
export PREFIX=3D/path/to/work/local
export PREFIXGNU=3D/path/to/work/gnu
export
LIBPATH=3D$PREFIXGNU/lib/gcc/powerpc-ibm-aix5.3.0.0:$PREFIX/lib:/usr/lib:=
/
lib
export
PATH=3D$PREFIXGNU/bin:$PREFIX/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/b=
i
n/X11:/sbin:/usr/java131/jre/bin:/usr/java131/bin:/usr/local/bin:/usr/va
c/bin:/usr/vacpp/bin:/u
sr/lpp/LoadL/full/bin:/usr/local/gnu/bin

Check that g++ -v returns version 4.2.2.

I then installed other GNU tools that are useful:
Autoconf
Automake
Curl (OK this one is not GNU, but handy and easier to compile than wget)
Diffutils
M4
Patch

OK, now for soslib:
1) Compile expat-2.0.1. I Had trouble with xerces on AIX.
2) Compile sundials-2.3.0
3) Compile libsbml CVS version, using expat as the parser. If
compilation fails, look at config.log.
4) Get CVS version of SBML_odeSolver and compile using expat, libsbml
and sundials prefixes. Here it becomes tricky. From scratch it will
compile and work properly. But odeSolver in the odeSolver directory will
fail with memory exhaustion problems. This is caused by the fact that in
solverError.c:
static int memoryExhaustion =3D 0;
is not initialised properly! I found somewhere people reporting the same
kind of issues when trying to initialise static variables. I also
checked this myself in gdb. I don't know why. Maybe a gcc bug??

Anyway, there are two workarounds, both being bad practices, but that
work:
- don't use  SolverError_dump(); and SolverError_haltOnErrors(); in your
programs (but solverError.c is still broken)
- in solverError.c inactivate memoryExhaust tests (BAD! as well...)
using memoryExhaustion=3D0; just before testing for if =
(!memoryExhaustion)
or memoryExhaustion =3D memoryExhaustion || !result ;
The advantage of this last solution is to have a odeSolver working
without changing its code. And anyway, solverError.c is broken on AIX,
so...

Here it is! I hope this is helpful, but I have to say I passed a lot of
times debugging and solving issues on AIX.

Eric Fernandez

[SOSlib-discuss] advice

[Kevin S. <ke...@ep...>]

Dear All,

I am interested in using the SBML_odeSolver library as part
of a project on which we will want to deploy it on a number
of different Unix systems (e.g, AIX and various others).

I am currently intending to use libsbml-3.0.3, sundials-2.3.0,
along with a version of 'libSoS'. However, there appear to
be a number of issues with the configure / build process
(at least under AIX 5.3) with both the 1.6pre release and
the latest cvs.

So before I start picking apart the build process, I wonder
if anyone has any advice on what versions of the various
libraries I should be looking to use. From various comments
floating around the mailing list it sounds like I should be
using the cvs for SoS and the 'latest' version of sundials, but
it's not entirely clear to me what the latest advice should be.

I can relay any findings about the various platforms back to
the list in the event that I decide to go ahead with this.

Many thanks for any comments.

Cheers,
Kevin

===============================================================================
Kevin Stratford				Edinburgh Parallel Computing Centre,
Tel: +44 (0)131 650 5115		Room 3417 JCMB, The King's Buildings,
Fax: +44 (0)131 650 6555		The University of Edinburgh,
http://www.epcc.ed.ac.uk/~kevin/	Edinburgh EH9 3JZ, United Kingdom.
===============================================================================

Re: [SOSlib-discuss] starting a solver at an arbitrary time

[Rainer M. <ra...@tb...>]

Hi Eric,

> I would like to start a solver at an arbitrary time instead of time=0,

It was easier then I thought, but is so far not really tested well.

CVS version has now a new public function

IntegratorInstance_setInitialTime(ii, double initialtime)

which however only works on fresh or freshly reset integrators with the 
first output time (next time step) greater then the requested initial 
time. An error will be issued otherwise.

This first output time must have been already set via 
IntegratorInstance_create or _set/_reset functions, or via 
_setNextTimeStep called prior to _setInitialTime.

This means you can now use the combination of _copyVariableState and 
_setInitialTime to start a new integrator from the current state of 
another integrator (e.g. to simulate cell proliferation and keep the 
time for both cells).

Also _copyVariableState does now lead to resetting of the solver if the 
  target instance had already been integrated.

We should think about possible pitfalls for the functionalities of 
_copyVariableState and _setInitialTime.

Eric, please let me know, if it does what you need and if it works as it 
should!

And another warning: in CVS we have already switched to libSBML 3 and 
libSBML 3.0.2 or CVS version is recommended if not even required.

Rainer

Re: [SOSlib-discuss] starting a solver at an arbitrary time

[Rainer M. <ra...@tb...>]

Hi Eric,

 > I would like to start a solver at an arbitrary time instead of time=0,

I fear that this is not easily possible. The main reason is that it 
would violate SBML definitions, where the initial conditions always 
correspond to an initial time 0 (imagine non-autonomous systems which 
explicitly have "time" on the right-hand-side of the ODE system, or 
time-dependent events etc.).

What you could do is integrate to this starting time point and then

a) set all values to the initial conditions via 
IntegratorInstance_setVariableValue
or
b) via IntegratorInstance_copyVariableState from a fresh integrator 
instance of the same model and which has not been integrated yet.

If you want to use option b please let me know. The function needs to be 
adapted for this case, because currently it can only be used without 
prior integration of the target integrator.

However, both options involve unnecessary integrations to your start 
time, and i would recommend handling the time differences externally, 
i.e. remember the different time for this integrator and add it for your 
output yourself.
Would this latter option be OK for you?

I am not sure currently what the implications (in coding hours, maybe 
its only minutes but i dont know ;) ) would be to implement arbitrary 
start times - in principle it would however be possible.

Rainer





Eric Fernandez wrote:
> Hi,
> 
> I would like to start a solver at an arbitrary time instead of time=0,
> using the same initial conditions (and then continue until
> IntegratorInstance_timeCourseCompleted(engine) is false, aka reaches the
> simulation time).
> That would be only a time translation, but could be handy for designing
> cell populations. Is that possible, even after the CVOdeSettings have
> been set (eg using the same IntegratorInstance, resetting it after a
> first solving, and restarting from a later time but with the initial
> conditions).
> 
> Thanks for your advice,
> Eric Fernandez
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] starting a solver at an arbitrary time

[Eric F. <efe...@ph...>]

Hi,

I would like to start a solver at an arbitrary time instead of time=3D0,
using the same initial conditions (and then continue until
IntegratorInstance_timeCourseCompleted(engine) is false, aka reaches the
simulation time).
That would be only a time translation, but could be handy for designing
cell populations. Is that possible, even after the CVOdeSettings have
been set (eg using the same IntegratorInstance, resetting it after a
first solving, and restarting from a later time but with the initial
conditions).

Thanks for your advice,
Eric Fernandez

Re: [SOSlib-discuss] changed to libSBML 3.0.1

[Rainer M. <ra...@tb...>]

Rainer Machne wrote:

> ToDos before release:
> 
> * libSBML has a completely reworked handling of SBML parse and 
> validation errors. These should be accomodated, in parallel to generally 
> stream-lining and refactor SOSlib error handling.
> 
> * make objective function related structures independent of odeModel_t 
> structure
> 
> * implement new features of SBML L2V3:
> constraints, initialAssignments etc.
> 
> * implement variable Compartment sizes

I forgot:

* test and submit the new excellent Swig and (so far) Perl bindings :)

* finally check and repair odeSolverBatch function to fully cycle 
through varySettings

Please tell us your requests and priorities for other things you'd like 
to see in the next release!

Rainer

[SOSlib-discuss] changed to libSBML 3.0.1

[Rainer M. <ra...@tb...>]

Hi All,

SOSlib has switched to libSBML 3.0.1, new code is in CVS now.

Some minor bugs had to be fixed in libSBML. To avoid potential problems, 
you should thus preferably use the current CVS version of libSBML, but 
3.0.1 should in principle also work. However, in the latter case DON'T 
use SBML Version 1 models, as these are not correctly translated (imho) 
in the 3.0.1 release of libSBML. I have not tested the 3.0.0 release.

Also a well-hidden but potentially harmful bug of the compiled r.h.s 
functions for the sensitivity and adjoint solvers has been removed. Some 
equations where misinterpreted.
The bug could have lead to wrong sensitivities for species with 
hasOnlySubstanceUnits=true, or for predefined rateRules.

Feedback welcome.

ToDos before release:

* libSBML has a completely reworked handling of SBML parse and 
validation errors. These should be accomodated, in parallel to generally 
stream-lining and refactor SOSlib error handling.

* make objective function related structures independent of odeModel_t 
structure

* implement new features of SBML L2V3:
constraints, initialAssignments etc.

* implement variable Compartment sizes

Rainer

[SOSlib-discuss] sbmlsolver-Support Requests-1807116 Installing on Mac OSX 10.4.10

[Eva S. <eva...@ya...>]

> Hi all,
> 
> I am trying to install SBML_odeSolver-1.6.0 on a Mac
> OSX 10.4.10.
> 
> I already installed the libraries:
> 
> Sundials 2.1.1 in:
> 
>  /Users/eva/Desktop/Code/sundials/lib
> 
> and libSBML 2.3.5 in:
> 
> /Users/eva/Desktop/LibSBML
> 
> I tried to configure the SBML ODE Solver by:
> 
> ./configure
> --with-libsbml="/Users/eva/Desktop/LibSBML" 
>
--with-sundials="/Users/eva/Desktop/Code/sundials/lib"
> 
> But it does not find my SBML Library. Here is the
> output:
> 
> checking for a BSD-compatible install...
> /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> checking build system type...
> powerpc-apple-darwin8.10.0
> checking host system type...
> powerpc-apple-darwin8.10.0
> checking for g++... g++
> checking for C++ compiler default output file
> name... a.out
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C++
> compiler... yes
> checking whether g++ accepts -g... yes
> checking for style of include used by make... GNU
> checking dependency style of g++... gcc3
> checking for gcc... gcc
> checking whether we are using the GNU C compiler...
> yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none
> needed
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> checking for ranlib... ranlib
> checking for a BSD-compatible install...
> /usr/bin/install -c
> checking whether make sets $(MAKE)... (cached) yes
> checking for autoconf... /usr/bin/autoconf
> checking for aclocal... /usr/bin/aclocal
> checking for make... /usr/bin/make
> checking for ar... /usr/bin/ar
> checking for swig... swig
> checking for perl... /usr/bin/perl
> checking for SBML Library Version... expr: syntax
> error
> expr: syntax error
> expr: syntax error
> ./configure: line 4175: test: -eq: unary operator
> expected
> configure: found SBML Library Version 
> checking correct functioning of SBML... no:
>                    CFLAGS=-g -O2
> -I/Users/eva/Desktop/LibSBML/include
> -I/Users/eva/Desktop/LibSBML/include/sbml
>                    LDFLAGS= 
> -L/Users/eva/Desktop/LibSBML/lib
>                    LIBS= -lxerces-c -lsbml
> configure: error: Can not link to SBML Library:
>                   Please, make sure to use libSBML
> version >= 2.3.2
> 
> Someone can please help me?
> 
> Thanks,
> 
> Eva.


      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

Re: [SOSlib-discuss] SOSlib Windows build

[John L. <jl...@he...>]

I've added "WIN32;_DEBUG;_WINDOWS;_USRDLL;SBML_ODESOLVER_EXPORTS" as 
defines 
and get a bit farther.  I am still unclear on how the exports work in 
Windows...

Thanks

John


On Mon, 11 Jun 2007, Rainer Machne wrote:

> Hi John,
>
>
> The log file contains two errors:
>
> ASTIndexNameNode.cpp:79: error: function `int ASTNode_isIndexName(ASTNode_t*)' 
> definition is marked dllimport.
>
> ASTIndexNameNode.cpp:87: error: function `unsigned int 
> ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport
>
> Unfortunately we have no knowledge here about the dll import/export in 
> Windows.
>
> However, the file src/sbmlsolver/exportdefs.h is important for that.
>
> The "marked as dllimport" probably comes from the definition of 
> SBML_ODESOLVER_API, which was introduced for such import/export issues by 
> Andrew. It is supposed to indicate functions that are exported, i.e. that 
> should be available for calling applications which use SOSlib as a libary.
>
> Both functions, ASTNode_isIndexName and ASTNode_isSetIndex, have this prefix.
>
> In exportsdefs.h:
>
> #ifdef WIN32
> #ifdef SBML_ODESOLVER_EXPORTS
> #define SBML_ODESOLVER_API __declspec(dllexport)
> #else
> #define SBML_ODESOLVER_API __declspec(dllimport)
> #endif
> #else
> #define SBML_ODESOLVER_API
> #endif
>
> So this prefix can have two values, one for export, one for import. Now, I 
> guess we only need to find out what that means :) and when/how to set 
> SBML_ODESOLVER_EXPORTS.
>
> Andrew's comment in exportdefs.h says:
>
> /* The following ifdef block is the standard way of creating macros
> which make exporting from a DLL simpler. All files within this DLL are
> compiled with the SBML_ODESOLVER_EXPORTS symbol defined on the command
> line. this symbol should not be defined on any project that uses this
> DLL. This way any other project whose source files include this file
> see SBML_ODESOLVER_API functions as being imported from a DLL, whereas
> this DLL sees symbols defined with this macro as being exported. */
>
> The symbol is also mentioned in the Win32 VisualC++ folder, in the (main?) 
> project file
> Win32/SBML_odeSolver/SBML_odeSolver/SBML_odeSolver.vcproj:
>
> PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;SBML_ODESOLVER_EXPORTS"
>
>
> Maybe it suffices to  define it on commandline (to 1 e.g.)? So the compiler 
> knows that the functions are being exported??
>
> However, I wonder if it is an (alphabetical) accident of the make process, 
> that this error occurs in our only C++ functions in ASTIndexNameNode.cpp, or 
> whether the problem is really C++-specific and import/export related.
> The code in this file imports and modifies the libSBML Abstract Syntax Tree 
> class (AST, contains math equations).
>
> Rainer
>
>
> John Legato wrote:
>> Hi Rainer,
>> 
>> We are attempting a build under mingw using the precompiled distribution of 
>> libsbml 2.3.4 (we tried to build it from source under mingw and it failed 
>> with dll export errors). We are getting dllexport errors with soslib as 
>> well. I've attached the log of the build. Do you have any insights?
>> 
>> Thanks
>> 
>> John
>> 
>>
>>  On Wed, 6 Jun 2007, Rainer Machne wrote:
>> 
>>> Hi John,
>>> 
>>> The windows/Visual C++ files (Win32 directory in source code distribution) 
>>> where made by Andrew Finney and unfortunately we have so far not found the 
>>> time to get into it and keep the windows branch up-to-date or even 
>>> understand how it works on Windows. Unfortunately Andrew is no longer 
>>> active. Christoph and James are currently at the SBML hackathon and Andrew 
>>> will be there. So maybe they can help you from there!
>>> 
>>> It is definitely something we need to understand and repair for the next 
>>> release:  installing from source under Cygwin or MinGW (have you tried 
>>> Akira's instructions for MinGW at 
>>> http://www.tbi.univie.ac.at/~raim/odeSolver/doc/installWin.html#src ?)
>>> and as a Visual C++ project.
>>> 
>>> Rainer
>>> 
>>> John Legato wrote:
>>> 
>>>> Hi Rainer,
>>>> 
>>>> We are still attempting to get a windows based DLL of soslib to use with 
>>>> Java bindings. I was wondering if you could suggest what might be the best 
>>>> route. We've tried Cygwin but got hung up on a link issue with libsbml 
>>>> which the Xerces rearranging the link flags to put -lsbml before -lxerces 
>>>> was suggested by the Xerces folks. This worked for the examples but using 
>>>> the same options building SOSlib was unsuccessful.
>>>> 
>>>> I am in the process of attempting the Visual C++ route to build a native 
>>>> library. I can successfully build WinCVODE but other modules fail due to 
>>>> missing header files. For example kinsol.h is missing, I know it's in the 
>>>> sundials distribution but it doesn't seem to be included in the sundials 
>>>> headers included with SOSlib. Do I need to build sundials from source on 
>>>> Windows to get a successful build?
>>>> 
>>>> I've tried to use SWIG with the prebuilt distribution for Windows but I 
>>>> can't seem to find the header files for SOSlib. release.zip appears to 
>>>> only include the DLLs without headers. I am also confused regarding the 
>>>> DLL names under windows. Under Linux we have libODES.a, under windows I 
>>>> see SBML_odeSolver.dll and WinCVODE.dll. Has SOSlib been split up 
>>>> differently under Windows? Is there a roadmap somewhere to the Windows 
>>>> build? I see a readme on the web but I am missing a few steps.
>>>> 
>>>> Thanks
>>>> 
>>>> John
>>>> 
>>>> 
>>>> ---
>>>> Contractor
>>> 
>> 
>> ---
>> Contractor
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> tar xzf SBML_odeSolver-1.6.0.tar.gz
>> cd SBML_odeSolver-1.6.0; \
>> export LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib" && ./configure 
>> LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib" 
>> --prefix=/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0_installed 
>> -with-sundials=/home/jlegato/SOSlibSWIG/sundials-2.1.1 
>> --with-libsbml=/home/jlegato/SOSlibSWIG/libsbml2_3_4 && \
>> patch src/Makefile ../SBML_so.patch && make 
>> LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib ";make install
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether build environment is sane... yes
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking build system type... i686-pc-mingw32
>> checking host system type... i686-pc-mingw32
>> checking for g++... g++
>> checking for C++ compiler default output file name... a.exe
>> checking whether the C++ compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables... .exe
>> checking for suffix of object files... o
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++ accepts -g... yes
>> checking for style of include used by make... GNU
>> checking dependency style of g++... gcc3
>> checking for gcc... gcc
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ANSI C... none needed
>> checking dependency style of gcc... gcc3
>> checking how to run the C preprocessor... gcc -E
>> checking for ranlib... ranlib
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether make sets $(MAKE)... (cached) yes
>> checking for autoconf... /bin/autoconf
>> checking for aclocal... /bin/aclocal
>> checking for make... /bin/make
>> checking for ar... /mingw/bin/ar
>> checking for swig... /usr/local/bin/swig
>> checking for perl... /bin/perl
>> checking for SBML Library Version... expr: syntax error
>> expr: syntax error
>> expr: syntax error
>> ./configure: test: -eq: unary operator expected
>> configure: found SBML Library Version ./configure: test: =: unary operator 
>> expected
>> checking correct functioning of SBML... yes
>> ./configure: test: -eq: unary operator expected
>> checking correct functioning of SUNDIALS CVODE... yes
>> checking for GRACE Library headers... checking for GRACE Library... checking 
>> correct functioning of GRACE... no:
>>                    CFLAGS=-g -O2 
>> LDFLAGS=-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib                    LIBS= Can not 
>> link to GRACE Library!
>> odeSolver will be installed without XMGrace functionality
>> checking for dot... no
>> configure: found Graphviz Library Version ./configure: test: -ge: unary 
>> operator expected
>> installed version of graphviz is too old!
>> disabling graphviz functionality!!!!!!!!!
>> ./configure: test: -ge: unary operator expected
>> ./configure: =no: command not found
>> ./configure: test: =: unary operator expected
>> :
>>                    CFLAGS=-g -O2
>>                    LDFLAGS=-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib
>>                    LIBS=
>> Can not link to GRAPHVIZ Library
>> odeSolver will be installed without Graphviz functionality
>> ./configure: test: =: unary operator expected
>> checking for isnan in -lm... yes
>> checking for egrep... grep -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking errno.h usability... yes
>> checking errno.h presence... yes
>> checking for errno.h... yes
>> checking math.h usability... yes
>> checking math.h presence... yes
>> checking for math.h... yes
>> checking whether byte ordering is bigendian... no
>> checking for an ANSI C-conforming const... yes
>> checking for size_t... yes
>> configure: creating ./config.status
>> config.status: creating ./Makefile
>> config.status: creating examples/Makefile
>> config.status: creating odeSolver/Makefile
>> config.status: creating src/Makefile
>> config.status: creating src/libODES.pc
>> config.status: creating bindings/Makefile
>> config.status: creating bindings/swig/Makefile
>> config.status: creating bindings/perl/Makefile
>> config.status: creating bindings/perl/Makefile.PL
>> config.status: creating src/sbmlsolver/config.h
>> config.status: executing depfiles commands
>> ./configure: test: !=: unary operator expected
>> 
>> Build Settings for SBML_odeSolver v1.6.0:
>> ----------------------------------
>>   host type            =   shared lib extension =   install dir          = 
>> /home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0_installed
>>   CC                   = gcc
>>   CFLAGS               =   LDFLAGS              =   LIBS                 = 
>> -lm   SBML Library         = yes
>>        CFLAGS          = -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml
>>        LDFLAGS         = -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib
>>        LIBS            = -lsbml
>> SUNDIALS Library         = yes
>>        CFLAGS          = -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include
>>        LDFLAGS         = -L/home/jlegato/SOSlibSWIG/sundials-2.1.1/lib
>>        LIBS            = -lsundials_kinsol -lsundials_cvodes 
>> -lsundials_cvode -lsundials_nvecserial -lsundials_shared
>>   GRACE                = no
>> XMGRACE functionality will NOT be installed!
>>   GRAPHVIZ             = no
>> GRAPHVIZ functionality will NOT be installed!
>> 
>> NOTE:
>>      Unfortunately the current version of the SBML ODE Solver
>>      only works with the libSBML version >= 2.3.2. 
>> patching file `src/Makefile'
>> make[1]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> Making all in src
>> make[2]: Entering directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver 
>> -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml -I.    -g -O2 -MT 
>> ASTIndexNameNode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o 
>> ASTIndexNameNode.o ASTIndexNameNode.cpp; \
>> then mv -f ".deps/ASTIndexNameNode.Tpo" ".deps/ASTIndexNameNode.Po"; else rm 
>> -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
>> ASTIndexNameNode.cpp:79: error: function `int 
>> ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.
>> 
>> ASTIndexNameNode.cpp:87: error: function `unsigned int 
>> ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport.
>> 
>> make[2]: *** [ASTIndexNameNode.o] Error 1
>> make[2]: Leaving directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> make[1]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> Making install in src
>> make[2]: Entering directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver 
>> -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml -I.    -g -O2 -MT 
>> ASTIndexNameNode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o 
>> ASTIndexNameNode.o ASTIndexNameNode.cpp; \
>> then mv -f ".deps/ASTIndexNameNode.Tpo" ".deps/ASTIndexNameNode.Po"; else rm 
>> -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
>> ASTIndexNameNode.cpp:79: error: function `int 
>> ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.
>> 
>> ASTIndexNameNode.cpp:87: error: function `unsigned int 
>> ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport.
>> 
>> make[2]: *** [ASTIndexNameNode.o] Error 1
>> make[2]: Leaving directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> make[1]: *** [install-recursive] Error 1
>> make[1]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> make: *** [soslib] Error 2
>

---
Contractor

Re: [SOSlib-discuss] SOSlib Windows build

[John L. <jl...@he...>]

Hi Rainer,

We saw your post regarding the CVS code base being updated to use the 
latest version of SUNDIALS. We are wondering if it might make more sense 
to use the code base in CVS for our Windows port work. If a release is 
eminent it might make sense for us to use the newer code base. If not we'd 
likely  be  more inclined to stick with the 1.6.0  code base for our 
efforts? Is a release eminent?


Thanks

John


  On Mon, 11 Jun 2007, Rainer Machne wrote:

> Hi John,
>
>
> The log file contains two errors:
>
> ASTIndexNameNode.cpp:79: error: function `int ASTNode_isIndexName(ASTNode_t*)' 
> definition is marked dllimport.
>
> ASTIndexNameNode.cpp:87: error: function `unsigned int 
> ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport
>
> Unfortunately we have no knowledge here about the dll import/export in 
> Windows.
>
> However, the file src/sbmlsolver/exportdefs.h is important for that.
>
> The "marked as dllimport" probably comes from the definition of 
> SBML_ODESOLVER_API, which was introduced for such import/export issues by 
> Andrew. It is supposed to indicate functions that are exported, i.e. that 
> should be available for calling applications which use SOSlib as a libary.
>
> Both functions, ASTNode_isIndexName and ASTNode_isSetIndex, have this prefix.
>
> In exportsdefs.h:
>
> #ifdef WIN32
> #ifdef SBML_ODESOLVER_EXPORTS
> #define SBML_ODESOLVER_API __declspec(dllexport)
> #else
> #define SBML_ODESOLVER_API __declspec(dllimport)
> #endif
> #else
> #define SBML_ODESOLVER_API
> #endif
>
> So this prefix can have two values, one for export, one for import. Now, I 
> guess we only need to find out what that means :) and when/how to set 
> SBML_ODESOLVER_EXPORTS.
>
> Andrew's comment in exportdefs.h says:
>
> /* The following ifdef block is the standard way of creating macros
> which make exporting from a DLL simpler. All files within this DLL are
> compiled with the SBML_ODESOLVER_EXPORTS symbol defined on the command
> line. this symbol should not be defined on any project that uses this
> DLL. This way any other project whose source files include this file
> see SBML_ODESOLVER_API functions as being imported from a DLL, whereas
> this DLL sees symbols defined with this macro as being exported. */
>
> The symbol is also mentioned in the Win32 VisualC++ folder, in the (main?) 
> project file
> Win32/SBML_odeSolver/SBML_odeSolver/SBML_odeSolver.vcproj:
>
> PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;SBML_ODESOLVER_EXPORTS"
>
>
> Maybe it suffices to  define it on commandline (to 1 e.g.)? So the compiler 
> knows that the functions are being exported??
>
> However, I wonder if it is an (alphabetical) accident of the make process, 
> that this error occurs in our only C++ functions in ASTIndexNameNode.cpp, or 
> whether the problem is really C++-specific and import/export related.
> The code in this file imports and modifies the libSBML Abstract Syntax Tree 
> class (AST, contains math equations).
>
> Rainer
>
>
> John Legato wrote:
>> Hi Rainer,
>> 
>> We are attempting a build under mingw using the precompiled distribution of 
>> libsbml 2.3.4 (we tried to build it from source under mingw and it failed 
>> with dll export errors). We are getting dllexport errors with soslib as 
>> well. I've attached the log of the build. Do you have any insights?
>> 
>> Thanks
>> 
>> John
>> 
>>
>>  On Wed, 6 Jun 2007, Rainer Machne wrote:
>> 
>>> Hi John,
>>> 
>>> The windows/Visual C++ files (Win32 directory in source code distribution) 
>>> where made by Andrew Finney and unfortunately we have so far not found the 
>>> time to get into it and keep the windows branch up-to-date or even 
>>> understand how it works on Windows. Unfortunately Andrew is no longer 
>>> active. Christoph and James are currently at the SBML hackathon and Andrew 
>>> will be there. So maybe they can help you from there!
>>> 
>>> It is definitely something we need to understand and repair for the next 
>>> release:  installing from source under Cygwin or MinGW (have you tried 
>>> Akira's instructions for MinGW at 
>>> http://www.tbi.univie.ac.at/~raim/odeSolver/doc/installWin.html#src ?)
>>> and as a Visual C++ project.
>>> 
>>> Rainer
>>> 
>>> John Legato wrote:
>>> 
>>>> Hi Rainer,
>>>> 
>>>> We are still attempting to get a windows based DLL of soslib to use with 
>>>> Java bindings. I was wondering if you could suggest what might be the best 
>>>> route. We've tried Cygwin but got hung up on a link issue with libsbml 
>>>> which the Xerces rearranging the link flags to put -lsbml before -lxerces 
>>>> was suggested by the Xerces folks. This worked for the examples but using 
>>>> the same options building SOSlib was unsuccessful.
>>>> 
>>>> I am in the process of attempting the Visual C++ route to build a native 
>>>> library. I can successfully build WinCVODE but other modules fail due to 
>>>> missing header files. For example kinsol.h is missing, I know it's in the 
>>>> sundials distribution but it doesn't seem to be included in the sundials 
>>>> headers included with SOSlib. Do I need to build sundials from source on 
>>>> Windows to get a successful build?
>>>> 
>>>> I've tried to use SWIG with the prebuilt distribution for Windows but I 
>>>> can't seem to find the header files for SOSlib. release.zip appears to 
>>>> only include the DLLs without headers. I am also confused regarding the 
>>>> DLL names under windows. Under Linux we have libODES.a, under windows I 
>>>> see SBML_odeSolver.dll and WinCVODE.dll. Has SOSlib been split up 
>>>> differently under Windows? Is there a roadmap somewhere to the Windows 
>>>> build? I see a readme on the web but I am missing a few steps.
>>>> 
>>>> Thanks
>>>> 
>>>> John
>>>> 
>>>> 
>>>> ---
>>>> Contractor
>>> 
>> 
>> ---
>> Contractor
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> tar xzf SBML_odeSolver-1.6.0.tar.gz
>> cd SBML_odeSolver-1.6.0; \
>> export LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib" && ./configure 
>> LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib" 
>> --prefix=/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0_installed 
>> -with-sundials=/home/jlegato/SOSlibSWIG/sundials-2.1.1 
>> --with-libsbml=/home/jlegato/SOSlibSWIG/libsbml2_3_4 && \
>> patch src/Makefile ../SBML_so.patch && make 
>> LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib ";make install
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether build environment is sane... yes
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking build system type... i686-pc-mingw32
>> checking host system type... i686-pc-mingw32
>> checking for g++... g++
>> checking for C++ compiler default output file name... a.exe
>> checking whether the C++ compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables... .exe
>> checking for suffix of object files... o
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++ accepts -g... yes
>> checking for style of include used by make... GNU
>> checking dependency style of g++... gcc3
>> checking for gcc... gcc
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ANSI C... none needed
>> checking dependency style of gcc... gcc3
>> checking how to run the C preprocessor... gcc -E
>> checking for ranlib... ranlib
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether make sets $(MAKE)... (cached) yes
>> checking for autoconf... /bin/autoconf
>> checking for aclocal... /bin/aclocal
>> checking for make... /bin/make
>> checking for ar... /mingw/bin/ar
>> checking for swig... /usr/local/bin/swig
>> checking for perl... /bin/perl
>> checking for SBML Library Version... expr: syntax error
>> expr: syntax error
>> expr: syntax error
>> ./configure: test: -eq: unary operator expected
>> configure: found SBML Library Version ./configure: test: =: unary operator 
>> expected
>> checking correct functioning of SBML... yes
>> ./configure: test: -eq: unary operator expected
>> checking correct functioning of SUNDIALS CVODE... yes
>> checking for GRACE Library headers... checking for GRACE Library... checking 
>> correct functioning of GRACE... no:
>>                    CFLAGS=-g -O2 
>> LDFLAGS=-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib                    LIBS= Can not 
>> link to GRACE Library!
>> odeSolver will be installed without XMGrace functionality
>> checking for dot... no
>> configure: found Graphviz Library Version ./configure: test: -ge: unary 
>> operator expected
>> installed version of graphviz is too old!
>> disabling graphviz functionality!!!!!!!!!
>> ./configure: test: -ge: unary operator expected
>> ./configure: =no: command not found
>> ./configure: test: =: unary operator expected
>> :
>>                    CFLAGS=-g -O2
>>                    LDFLAGS=-L/home/jlegato/SOSlibSWIG/xerces/lib 
>> -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib 
>> -L/home/jlegato/SOSlibSWIG/sundials/lib
>>                    LIBS=
>> Can not link to GRAPHVIZ Library
>> odeSolver will be installed without Graphviz functionality
>> ./configure: test: =: unary operator expected
>> checking for isnan in -lm... yes
>> checking for egrep... grep -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking errno.h usability... yes
>> checking errno.h presence... yes
>> checking for errno.h... yes
>> checking math.h usability... yes
>> checking math.h presence... yes
>> checking for math.h... yes
>> checking whether byte ordering is bigendian... no
>> checking for an ANSI C-conforming const... yes
>> checking for size_t... yes
>> configure: creating ./config.status
>> config.status: creating ./Makefile
>> config.status: creating examples/Makefile
>> config.status: creating odeSolver/Makefile
>> config.status: creating src/Makefile
>> config.status: creating src/libODES.pc
>> config.status: creating bindings/Makefile
>> config.status: creating bindings/swig/Makefile
>> config.status: creating bindings/perl/Makefile
>> config.status: creating bindings/perl/Makefile.PL
>> config.status: creating src/sbmlsolver/config.h
>> config.status: executing depfiles commands
>> ./configure: test: !=: unary operator expected
>> 
>> Build Settings for SBML_odeSolver v1.6.0:
>> ----------------------------------
>>   host type            =   shared lib extension =   install dir          = 
>> /home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0_installed
>>   CC                   = gcc
>>   CFLAGS               =   LDFLAGS              =   LIBS                 = 
>> -lm   SBML Library         = yes
>>        CFLAGS          = -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml
>>        LDFLAGS         = -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib
>>        LIBS            = -lsbml
>> SUNDIALS Library         = yes
>>        CFLAGS          = -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include
>>        LDFLAGS         = -L/home/jlegato/SOSlibSWIG/sundials-2.1.1/lib
>>        LIBS            = -lsundials_kinsol -lsundials_cvodes 
>> -lsundials_cvode -lsundials_nvecserial -lsundials_shared
>>   GRACE                = no
>> XMGRACE functionality will NOT be installed!
>>   GRAPHVIZ             = no
>> GRAPHVIZ functionality will NOT be installed!
>> 
>> NOTE:
>>      Unfortunately the current version of the SBML ODE Solver
>>      only works with the libSBML version >= 2.3.2. 
>> patching file `src/Makefile'
>> make[1]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> Making all in src
>> make[2]: Entering directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver 
>> -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml -I.    -g -O2 -MT 
>> ASTIndexNameNode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o 
>> ASTIndexNameNode.o ASTIndexNameNode.cpp; \
>> then mv -f ".deps/ASTIndexNameNode.Tpo" ".deps/ASTIndexNameNode.Po"; else rm 
>> -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
>> ASTIndexNameNode.cpp:79: error: function `int 
>> ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.
>> 
>> ASTIndexNameNode.cpp:87: error: function `unsigned int 
>> ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport.
>> 
>> make[2]: *** [ASTIndexNameNode.o] Error 1
>> make[2]: Leaving directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> make[1]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> Making install in src
>> make[2]: Entering directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver 
>> -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include 
>> -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml -I.    -g -O2 -MT 
>> ASTIndexNameNode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o 
>> ASTIndexNameNode.o ASTIndexNameNode.cpp; \
>> then mv -f ".deps/ASTIndexNameNode.Tpo" ".deps/ASTIndexNameNode.Po"; else rm 
>> -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
>> ASTIndexNameNode.cpp:79: error: function `int 
>> ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.
>> 
>> ASTIndexNameNode.cpp:87: error: function `unsigned int 
>> ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport.
>> 
>> make[2]: *** [ASTIndexNameNode.o] Error 1
>> make[2]: Leaving directory 
>> `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
>> make[1]: *** [install-recursive] Error 1
>> make[1]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
>> make: *** [soslib] Error 2
>

---
Contractor

[SOSlib-discuss] update to new SUNDIALS

[Rainer M. <ra...@tb...>]

Hi All,

James and Christoph have changed the SUNDIALS interface to use the 
latest version of SUNDIALS.

We will commit that to CVS within the next 3 days!

So please, update/commit today if you want to keep using the old 
sundials for a while.

Rainer

Re: [SOSlib-discuss] SOSlib Windows build

[Rainer M. <ra...@tb...>]

Hi John,


The log file contains two errors:

ASTIndexNameNode.cpp:79: error: function `int 
ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.

ASTIndexNameNode.cpp:87: error: function `unsigned int 
ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport

Unfortunately we have no knowledge here about the dll import/export in 
Windows.

However, the file src/sbmlsolver/exportdefs.h is important for that.

The "marked as dllimport" probably comes from the definition of 
SBML_ODESOLVER_API, which was introduced for such import/export issues 
by Andrew. It is supposed to indicate functions that are exported, i.e. 
that should be available for calling applications which use SOSlib as a 
libary.

Both functions, ASTNode_isIndexName and ASTNode_isSetIndex, have this 
prefix.

In exportsdefs.h:

#ifdef WIN32
#ifdef SBML_ODESOLVER_EXPORTS
#define SBML_ODESOLVER_API __declspec(dllexport)
#else
#define SBML_ODESOLVER_API __declspec(dllimport)
#endif
#else
#define SBML_ODESOLVER_API
#endif

So this prefix can have two values, one for export, one for import. Now, 
I guess we only need to find out what that means :) and when/how to set 
SBML_ODESOLVER_EXPORTS.

Andrew's comment in exportdefs.h says:

/* The following ifdef block is the standard way of creating macros
which make exporting from a DLL simpler. All files within this DLL are
compiled with the SBML_ODESOLVER_EXPORTS symbol defined on the command
line. this symbol should not be defined on any project that uses this
DLL. This way any other project whose source files include this file
see SBML_ODESOLVER_API functions as being imported from a DLL, whereas
this DLL sees symbols defined with this macro as being exported. */

The symbol is also mentioned in the Win32 VisualC++ folder, in the 
(main?) project file
Win32/SBML_odeSolver/SBML_odeSolver/SBML_odeSolver.vcproj:

PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;SBML_ODESOLVER_EXPORTS"


Maybe it suffices to  define it on commandline (to 1 e.g.)? So the 
compiler knows that the functions are being exported??

However, I wonder if it is an (alphabetical) accident of the make 
process, that this error occurs in our only C++ functions in 
ASTIndexNameNode.cpp, or whether the problem is really C++-specific and 
import/export related.
The code in this file imports and modifies the libSBML Abstract Syntax 
Tree class (AST, contains math equations).

Rainer


John Legato wrote:
> Hi Rainer,
> 
> We are attempting a build under mingw using the precompiled distribution 
> of libsbml 2.3.4 (we tried to build it from source under mingw and it 
> failed with dll export errors). We are getting dllexport errors with 
> soslib as well. I've attached the log of the build. Do you have any 
> insights?
> 
> Thanks
> 
> John
> 
> 
>  On Wed, 6 Jun 2007, Rainer Machne wrote:
> 
>> Hi John,
>>
>> The windows/Visual C++ files (Win32 directory in source code 
>> distribution) where made by Andrew Finney and unfortunately we have so 
>> far not found the time to get into it and keep the windows branch 
>> up-to-date or even understand how it works on Windows. Unfortunately 
>> Andrew is no longer active. Christoph and James are currently at the 
>> SBML hackathon and Andrew will be there. So maybe they can help you 
>> from there!
>>
>> It is definitely something we need to understand and repair for the 
>> next release:  installing from source under Cygwin or MinGW (have you 
>> tried Akira's instructions for MinGW at 
>> http://www.tbi.univie.ac.at/~raim/odeSolver/doc/installWin.html#src ?)
>> and as a Visual C++ project.
>>
>> Rainer
>>
>> John Legato wrote:
>>
>>> Hi Rainer,
>>>
>>> We are still attempting to get a windows based DLL of soslib to use 
>>> with Java bindings. I was wondering if you could suggest what might 
>>> be the best route. We've tried Cygwin but got hung up on a link issue 
>>> with libsbml which the Xerces rearranging the link flags to put 
>>> -lsbml before -lxerces was suggested by the Xerces folks. This worked 
>>> for the examples but using the same options building SOSlib was 
>>> unsuccessful.
>>>
>>> I am in the process of attempting the Visual C++ route to build a 
>>> native library. I can successfully build WinCVODE but other modules 
>>> fail due to missing header files. For example kinsol.h is missing, I 
>>> know it's in the sundials distribution but it doesn't seem to be 
>>> included in the sundials headers included with SOSlib. Do I need to 
>>> build sundials from source on Windows to get a successful build?
>>>
>>> I've tried to use SWIG with the prebuilt distribution for Windows but 
>>> I can't seem to find the header files for SOSlib. release.zip appears 
>>> to only include the DLLs without headers. I am also confused 
>>> regarding the DLL names under windows. Under Linux we have libODES.a, 
>>> under windows I see SBML_odeSolver.dll and WinCVODE.dll. Has SOSlib 
>>> been split up differently under Windows? Is there a roadmap somewhere 
>>> to the Windows build? I see a readme on the web but I am missing a 
>>> few steps.
>>>
>>> Thanks
>>>
>>> John
>>>
>>>
>>> ---
>>> Contractor
>>
> 
> ---
> Contractor
> 
> 
> ------------------------------------------------------------------------
> 
> tar xzf SBML_odeSolver-1.6.0.tar.gz
> cd SBML_odeSolver-1.6.0; \
> export LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib -L/home/jlegato/SOSlibSWIG/sundials/lib" && ./configure LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib -L/home/jlegato/SOSlibSWIG/sundials/lib" --prefix=/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0_installed -with-sundials=/home/jlegato/SOSlibSWIG/sundials-2.1.1 --with-libsbml=/home/jlegato/SOSlibSWIG/libsbml2_3_4 && \
> patch src/Makefile ../SBML_so.patch && make LDFLAGS="-L/home/jlegato/SOSlibSWIG/xerces/lib -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib -L/home/jlegato/SOSlibSWIG/sundials/lib ";make install
> checking for a BSD-compatible install... /bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking build system type... i686-pc-mingw32
> checking host system type... i686-pc-mingw32
> checking for g++... g++
> checking for C++ compiler default output file name... a.exe
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... .exe
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking for style of include used by make... GNU
> checking dependency style of g++... gcc3
> checking for gcc... gcc
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> checking for ranlib... ranlib
> checking for a BSD-compatible install... /bin/install -c
> checking whether make sets $(MAKE)... (cached) yes
> checking for autoconf... /bin/autoconf
> checking for aclocal... /bin/aclocal
> checking for make... /bin/make
> checking for ar... /mingw/bin/ar
> checking for swig... /usr/local/bin/swig
> checking for perl... /bin/perl
> checking for SBML Library Version... expr: syntax error
> expr: syntax error
> expr: syntax error
> ./configure: test: -eq: unary operator expected
> configure: found SBML Library Version 
> ./configure: test: =: unary operator expected
> checking correct functioning of SBML... yes
> ./configure: test: -eq: unary operator expected
> checking correct functioning of SUNDIALS CVODE... yes
> checking for GRACE Library headers... checking for GRACE Library... checking correct functioning of GRACE... no:
>                    CFLAGS=-g -O2 
>                    LDFLAGS=-L/home/jlegato/SOSlibSWIG/xerces/lib -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib -L/home/jlegato/SOSlibSWIG/sundials/lib 
>                    LIBS= 
> Can not link to GRACE Library!
> odeSolver will be installed without XMGrace functionality
> checking for dot... no
> configure: found Graphviz Library Version 
> ./configure: test: -ge: unary operator expected
> installed version of graphviz is too old!
> disabling graphviz functionality!!!!!!!!!
> ./configure: test: -ge: unary operator expected
> ./configure: =no: command not found
> ./configure: test: =: unary operator expected
> :
>                    CFLAGS=-g -O2
>                    LDFLAGS=-L/home/jlegato/SOSlibSWIG/xerces/lib -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib -L/home/jlegato/SOSlibSWIG/sundials/lib
>                    LIBS=
> Can not link to GRAPHVIZ Library
> odeSolver will be installed without Graphviz functionality
> ./configure: test: =: unary operator expected
> checking for isnan in -lm... yes
> checking for egrep... grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking errno.h usability... yes
> checking errno.h presence... yes
> checking for errno.h... yes
> checking math.h usability... yes
> checking math.h presence... yes
> checking for math.h... yes
> checking whether byte ordering is bigendian... no
> checking for an ANSI C-conforming const... yes
> checking for size_t... yes
> configure: creating ./config.status
> config.status: creating ./Makefile
> config.status: creating examples/Makefile
> config.status: creating odeSolver/Makefile
> config.status: creating src/Makefile
> config.status: creating src/libODES.pc
> config.status: creating bindings/Makefile
> config.status: creating bindings/swig/Makefile
> config.status: creating bindings/perl/Makefile
> config.status: creating bindings/perl/Makefile.PL
> config.status: creating src/sbmlsolver/config.h
> config.status: executing depfiles commands
> ./configure: test: !=: unary operator expected
> 
> Build Settings for SBML_odeSolver v1.6.0:
> ----------------------------------
>   host type            = 
>   shared lib extension = 
>   install dir          = /home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0_installed
>   CC                   = gcc
>   CFLAGS               = 
>   LDFLAGS              = 
>   LIBS                 = -lm 
>   SBML Library         = yes
>        CFLAGS          = -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml
>        LDFLAGS         = -L/home/jlegato/SOSlibSWIG/libsbml2_3_4/lib
>        LIBS            = -lsbml
> SUNDIALS Library         = yes
>        CFLAGS          = -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include
>        LDFLAGS         = -L/home/jlegato/SOSlibSWIG/sundials-2.1.1/lib
>        LIBS            = -lsundials_kinsol -lsundials_cvodes -lsundials_cvode -lsundials_nvecserial -lsundials_shared
>   GRACE                = no
> XMGRACE functionality will NOT be installed!
>   GRAPHVIZ             = no
> GRAPHVIZ functionality will NOT be installed!
> 
> NOTE:
>      Unfortunately the current version of the SBML ODE Solver
>      only works with the libSBML version >= 2.3.2.           
> 
> patching file `src/Makefile'
> make[1]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
> Making all in src
> make[2]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
> if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml -I.    -g -O2 -MT ASTIndexNameNode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o ASTIndexNameNode.o ASTIndexNameNode.cpp; \
> then mv -f ".deps/ASTIndexNameNode.Tpo" ".deps/ASTIndexNameNode.Po"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
> ASTIndexNameNode.cpp:79: error: function `int ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.
> 
> ASTIndexNameNode.cpp:87: error: function `unsigned int ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport.
> 
> make[2]: *** [ASTIndexNameNode.o] Error 1
> make[2]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
> make[1]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
> Making install in src
> make[2]: Entering directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
> if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver -I/home/jlegato/SOSlibSWIG/sundials-2.1.1/include -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include -I/home/jlegato/SOSlibSWIG/libsbml2_3_4/include/sbml -I.    -g -O2 -MT ASTIndexNameNode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o ASTIndexNameNode.o ASTIndexNameNode.cpp; \
> then mv -f ".deps/ASTIndexNameNode.Tpo" ".deps/ASTIndexNameNode.Po"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
> ASTIndexNameNode.cpp:79: error: function `int ASTNode_isIndexName(ASTNode_t*)' definition is marked dllimport.
> 
> ASTIndexNameNode.cpp:87: error: function `unsigned int ASTNode_isSetIndex(ASTNode_t*)' definition is marked dllimport.
> 
> make[2]: *** [ASTIndexNameNode.o] Error 1
> make[2]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0/src'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/home/jlegato/SOSlibSWIG/SBML_odeSolver-1.6.0'
> make: *** [soslib] Error 2

Re: [SOSlib-discuss] SOSlib Windows build

[John L. <jl...@he...>]

Hi Rainer,

We are attempting a build under mingw using the precompiled distribution 
of libsbml 2.3.4 (we tried to build it from source under mingw and it 
failed with dll export errors). We are getting dllexport errors with 
soslib as well. I've attached the log of the build. Do you have any 
insights?

Thanks

John


  On Wed, 6 Jun 2007, Rainer Machne wrote:

> Hi John,
>
> The windows/Visual C++ files (Win32 directory in source code distribution) 
> where made by Andrew Finney and unfortunately we have so far not found the 
> time to get into it and keep the windows branch up-to-date or even understand 
> how it works on Windows. Unfortunately Andrew is no longer active. Christoph 
> and James are currently at the SBML hackathon and Andrew will be there. So 
> maybe they can help you from there!
>
> It is definitely something we need to understand and repair for the next 
> release:  installing from source under Cygwin or MinGW (have you tried Akira's 
> instructions for MinGW at 
> http://www.tbi.univie.ac.at/~raim/odeSolver/doc/installWin.html#src ?)
> and as a Visual C++ project.
>
> Rainer
>
> John Legato wrote:
>
>> Hi Rainer,
>> 
>> We are still attempting to get a windows based DLL of soslib to use with 
>> Java bindings. I was wondering if you could suggest what might be the best 
>> route. We've tried Cygwin but got hung up on a link issue with libsbml which 
>> the Xerces rearranging the link flags to put -lsbml before -lxerces was 
>> suggested by the Xerces folks. This worked for the examples but using the 
>> same options building SOSlib was unsuccessful.
>> 
>> I am in the process of attempting the Visual C++ route to build a native 
>> library. I can successfully build WinCVODE but other modules fail due to 
>> missing header files. For example kinsol.h is missing, I know it's in the 
>> sundials distribution but it doesn't seem to be included in the sundials 
>> headers included with SOSlib. Do I need to build sundials from source on 
>> Windows to get a successful build?
>> 
>> I've tried to use SWIG with the prebuilt distribution for Windows but I 
>> can't seem to find the header files for SOSlib. release.zip appears to only 
>> include the DLLs without headers. I am also confused regarding the DLL names 
>> under windows. Under Linux we have libODES.a, under windows I see 
>> SBML_odeSolver.dll and WinCVODE.dll. Has SOSlib been split up differently 
>> under Windows? Is there a roadmap somewhere to the Windows build? I see a 
>> readme on the web but I am missing a few steps.
>> 
>> Thanks
>> 
>> John
>> 
>> 
>> ---
>> Contractor
>

---
Contractor

Re: [SOSlib-discuss] SOSlib Windows build

[Rainer M. <ra...@tb...>]

Hi John,

The windows/Visual C++ files (Win32 directory in source code 
distribution) where made by Andrew Finney and unfortunately we have so 
far not found the time to get into it and keep the windows branch 
up-to-date or even understand how it works on Windows. Unfortunately 
Andrew is no longer active. Christoph and James are currently at the 
SBML hackathon and Andrew will be there. So maybe they can help you from 
there!

It is definitely something we need to understand and repair for the next 
release:  installing from source under Cygwin or MinGW (have you tried 
Akira's instructions for MinGW at 
http://www.tbi.univie.ac.at/~raim/odeSolver/doc/installWin.html#src ?)
and as a Visual C++ project.

Rainer

John Legato wrote:

> Hi Rainer,
> 
> We are still attempting to get a windows based DLL of soslib to use with 
> Java bindings. I was wondering if you could suggest what might be the 
> best route. We've tried Cygwin but got hung up on a link issue with 
> libsbml which the Xerces rearranging the link flags to put -lsbml before 
> -lxerces was suggested by the Xerces folks. This worked for the examples 
> but using the same options building SOSlib was unsuccessful.
> 
> I am in the process of attempting the Visual C++ route to build a native 
> library. I can successfully build WinCVODE but other modules fail due to 
> missing header files. For example kinsol.h is missing, I know it's in 
> the sundials distribution but it doesn't seem to be included in the 
> sundials headers included with SOSlib. Do I need to build sundials from 
> source on Windows to get a successful build?
> 
> I've tried to use SWIG with the prebuilt distribution for Windows but I 
> can't seem to find the header files for SOSlib. release.zip appears to 
> only include the DLLs without headers. I am also confused regarding the 
> DLL names under windows. Under Linux we have libODES.a, under windows I 
> see  SBML_odeSolver.dll and WinCVODE.dll. Has SOSlib been split up 
> differently under Windows? Is there a roadmap somewhere to the Windows 
> build? I see a readme on the web but I am missing a few steps.
> 
> Thanks
> 
> John
> 
> 
> ---
> Contractor

Re: [SOSlib-discuss] Creating a shared library

[Rainer M. <ra...@tb...>]

Hi Colin,

sorry for the delayed reply. We had this question last month on the list, 
and John had succeeded to create a shared library by just adding -shared 
flag during build. But I haven't tested it myself yett.

Maybe Christoph can help you with that during the hackathon!
We should officially add the -shared flag to soslib build process.

Rainer

On Mon, 4 Jun 2007, Colin Gillespie wrote:

> Dear All,
>
> Is there an easy way for me to create a shared library of SBML Solver?
>
> Cheers
>
> Colin
>
> -- 
> Dr Colin Gillespie
> http://www.mas.ncl.ac.uk/~ncsg3/
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>

[SOSlib-discuss] Creating a shared library

[Colin G. <c.g...@nc...>]

Dear All,

Is there an easy way for me to create a shared library of SBML Solver?

Cheers

Colin

-- 
Dr Colin Gillespie
http://www.mas.ncl.ac.uk/~ncsg3/

Re: [SOSlib-discuss] SBML Solver 1.6.0 under Cygwin (fwd)

[Rainer M. <ra...@tb...>]

we forgot to include the SOSlib list in the follow-up email, so just for 
the sake of archive completeness: libSBML examples produced the same 
errors and thus the problem appeared to be libSBML internal.

R

John Legato wrote:
> Hi Rainer,
> 
> Thanks for the reply, I did a make install and pointed to the installed 
> directory, not sure where the line below came from.
> 
> Thanks
> 
> John
> 
> On Wed, 16 May 2007, Rainer Machne wrote:
> 
>> Hi John,
>>
>> I have never tried it on cygwin and never seen these errors but I'll 
>> try one guess:
>>
>>>
>> //biocoreserver1/jlegato/cygwin/libsbml-2.3.4/src/sbml/SBMLReader.cpp:113: 
>>
>>
>> might indicate that you are linking directly to the libsbml source 
>> directory? I somehow remember (but are not sure) that libsbml on 
>> building uses internally a different directory structure - and 
>> different include paths - then when installed. Did you do a `make 
>> install' to above libsbml directory or just `make' in libsbml's own 
>> directory? I think we had the problem once, that SOSlib needs to be 
>> linked to the libsbml install directory and not to it's main source 
>> directory. ... just guessing.
>>
>> Rainer
>>
>> On Tue, 15 May 2007, John Legato wrote:
>>
>>>
>>>
>>>
>>> We are attempting to build SBMLSolver 1.6.0 under Cygwin 1.5 and are 
>>> encountering errors during configure's detection of SBML. We've built 
>>> libsbml 2.3.4 and Xerces 2.7.0 from source  We are using the 
>>> following configure command:
>>> ./configure --with-libsbml=/cygdrive/g/public//cygwin/libsbml-2_3_4/ 
>>> --with-sundials=/cygdrive/g/public/cygwin/sundials-2_1_1/
>>>
>>> We are getting errors along the lines of:
>>>
>>> cygdrive/g/public//cygwin/libsbml-2_3_4//include/sbml 
>>> -L/cygdrive/g/public/cygwin/libxerces2_7_0/
>>> lib -Wl,-rpath,/cygdrive/g/public//cygwin/libsbml-2_3_4//lib 
>>> -L/cygdrive/g/public//cygwin/libsbml-
>>> 2_3_4//lib conftest.c  -lxerces-c -lsbml >&5
>>> /cygdrive/g/public//cygwin/libsbml-2_3_4//lib/libsbml.a(SBMLReader.o): 
>>> In function `_ZNSsC1IPcEET_
>>> S1_RKSaIcE':
>>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/basic_string.tcc:(.text+0x11): 
>>> undefined refere
>>> nce to `xercesc_2_7::XMLString::transcode(unsigned short const*)'
>>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/basic_string.tcc:(.text+0x3e): 
>>> undefined refere
>>> nce to `xercesc_2_7::XMLString::release(char**)'
>>> /cygdrive/g/public//cygwin/libsbml-2_3_4//lib/libsbml.a(SBMLReader.o): 
>>> In function `_Z16XMLReader_
>>> createPN11xercesc_2_714DefaultHandlerE':
>>> //biocoreserver1/jlegato/cygwin/libsbml-2.3.4/src/sbml/SBMLReader.cpp:113: 
>>> undefined reference to
>>> `___gxx_personality_sj0'
>>>
>>> (Compressed Full log attached)
>>>
>>> Does anyone have any insights into what is going wrong?
>>>
>>> Thanks
>>>
>>> John
>>> ---
>>> Contractor
>>
> 
> ---
> Contractor

Re: [SOSlib-discuss] SBML Solver 1.6.0 under Cygwin (fwd)

[John L. <jl...@he...>]

Hi Rainer,

Thanks for the reply, I did a make install and pointed to the installed 
directory, not sure where the line below came from.

Thanks

John

On Wed, 16 May 2007, Rainer Machne wrote:

> Hi John,
>
> I have never tried it on cygwin and never seen these errors but I'll try one 
> guess:
>
>> 
> //biocoreserver1/jlegato/cygwin/libsbml-2.3.4/src/sbml/SBMLReader.cpp:113:
>
> might indicate that you are linking directly to the libsbml source directory? 
> I somehow remember (but are not sure) that libsbml on building uses internally 
> a different directory structure - and different include paths - then when 
> installed. Did you do a `make install' to above libsbml directory or just 
> `make' in libsbml's own directory? I think we had the problem once, that 
> SOSlib needs to be linked to the libsbml install directory and not to it's 
> main source directory. ... just guessing.
>
> Rainer
>
> On Tue, 15 May 2007, John Legato wrote:
>
>> 
>> 
>> 
>> We are attempting to build SBMLSolver 1.6.0 under Cygwin 1.5 and are 
>> encountering errors during configure's detection of SBML. We've built 
>> libsbml 2.3.4 and Xerces 2.7.0 from source  We are using the following 
>> configure command:
>> ./configure --with-libsbml=/cygdrive/g/public//cygwin/libsbml-2_3_4/ 
>> --with-sundials=/cygdrive/g/public/cygwin/sundials-2_1_1/
>> 
>> We are getting errors along the lines of:
>> 
>> cygdrive/g/public//cygwin/libsbml-2_3_4//include/sbml 
>> -L/cygdrive/g/public/cygwin/libxerces2_7_0/
>> lib -Wl,-rpath,/cygdrive/g/public//cygwin/libsbml-2_3_4//lib 
>> -L/cygdrive/g/public//cygwin/libsbml-
>> 2_3_4//lib conftest.c  -lxerces-c -lsbml >&5
>> /cygdrive/g/public//cygwin/libsbml-2_3_4//lib/libsbml.a(SBMLReader.o): In 
>> function `_ZNSsC1IPcEET_
>> S1_RKSaIcE':
>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/basic_string.tcc:(.text+0x11): 
>> undefined refere
>> nce to `xercesc_2_7::XMLString::transcode(unsigned short const*)'
>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/basic_string.tcc:(.text+0x3e): 
>> undefined refere
>> nce to `xercesc_2_7::XMLString::release(char**)'
>> /cygdrive/g/public//cygwin/libsbml-2_3_4//lib/libsbml.a(SBMLReader.o): In 
>> function `_Z16XMLReader_
>> createPN11xercesc_2_714DefaultHandlerE':
>> //biocoreserver1/jlegato/cygwin/libsbml-2.3.4/src/sbml/SBMLReader.cpp:113: 
>> undefined reference to
>> `___gxx_personality_sj0'
>> 
>> (Compressed Full log attached)
>> 
>> Does anyone have any insights into what is going wrong?
>> 
>> Thanks
>> 
>> John
>> ---
>> Contractor
>

---
Contractor

Re: [SOSlib-discuss] SBML Solver 1.6.0 under Cygwin (fwd)

[Rainer M. <ra...@tb...>]

Hi John,

I have never tried it on cygwin and never seen these errors but I'll try 
one guess:

> 
//biocoreserver1/jlegato/cygwin/libsbml-2.3.4/src/sbml/SBMLReader.cpp:113:

might indicate that you are linking directly to the libsbml source 
directory? I 
somehow remember (but are not sure) that libsbml on building 
uses internally a different directory structure - and different 
include paths - then when installed. Did you do a `make install' to above 
libsbml directory or just `make' in libsbml's own directory? I think we 
had the problem once, that SOSlib needs to be linked to the libsbml 
install directory and not to it's main source directory. ... just 
guessing.

Rainer

On Tue, 15 May 2007, John Legato wrote:

>
>
>
> We are attempting to build SBMLSolver 1.6.0 under Cygwin 1.5 and are 
> encountering errors during configure's detection of SBML. We've built libsbml 
> 2.3.4 and Xerces 2.7.0 from source  We are using the following configure 
> command:
> ./configure --with-libsbml=/cygdrive/g/public//cygwin/libsbml-2_3_4/ 
> --with-sundials=/cygdrive/g/public/cygwin/sundials-2_1_1/
>
> We are getting errors along the lines of:
>
> cygdrive/g/public//cygwin/libsbml-2_3_4//include/sbml 
> -L/cygdrive/g/public/cygwin/libxerces2_7_0/
> lib -Wl,-rpath,/cygdrive/g/public//cygwin/libsbml-2_3_4//lib 
> -L/cygdrive/g/public//cygwin/libsbml-
> 2_3_4//lib conftest.c  -lxerces-c -lsbml >&5
> /cygdrive/g/public//cygwin/libsbml-2_3_4//lib/libsbml.a(SBMLReader.o): In 
> function `_ZNSsC1IPcEET_
> S1_RKSaIcE':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/basic_string.tcc:(.text+0x11): 
> undefined refere
> nce to `xercesc_2_7::XMLString::transcode(unsigned short const*)'
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/basic_string.tcc:(.text+0x3e): 
> undefined refere
> nce to `xercesc_2_7::XMLString::release(char**)'
> /cygdrive/g/public//cygwin/libsbml-2_3_4//lib/libsbml.a(SBMLReader.o): In 
> function `_Z16XMLReader_
> createPN11xercesc_2_714DefaultHandlerE':
> //biocoreserver1/jlegato/cygwin/libsbml-2.3.4/src/sbml/SBMLReader.cpp:113: 
> undefined reference to
> `___gxx_personality_sj0'
>
> (Compressed Full log attached)
>
> Does anyone have any insights into what is going wrong?
>
> Thanks
>
> John
> ---
> Contractor