sbmlsolver-devel — developer's email list for the SBML ODE Solver Library

Re: [SOSlib-devel] API reorganization[Scanned]

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

Hi Andrew

I am still confused by the current structure of header files.

E.g. in

cvodedatatype.h

there are the two  typedefs

   typedef struct cvodeData cvodeData_t ;
   typedef struct cvodeResults cvodeResults_t ;

But in cvodeDataStruct.h there is only the structure cvodeData, whereas 
cvodeResults is still in cvodedata.h

If I try to change this, i.e. move the two structures into an internal 
header and only have the typedefs in the API header, compilation fails due 
to the mutual dependencies, i.e. cvodeResults_t being a data field in 
cvodeData.

For odeModelStruct I get similar problems with

typedef int (*EventFn)(cvodeData_t *, int *);

which is required by odeModel and itself requires cvodeData.

I had to change it to
typedef int (*EventFn)(void *, int *);



So to be honest, I would prefer at the moment to just remove all the 
...datatype.h and ...Struct.h files, because they are just inconsistent 
and confusing and the mutual dependencies are very complicated.

Actually I have already done this here, because I 
thought it might be good to merge the files before splitting them up in 
internal and API headers again.

Rainer




On Mon, 12 Jun 2006, Rainer Machne wrote:

>
> Andrew
>
>> I strongly suggest you create a new directory for
>> 'internal' headers.
>
> Ok. I'll make another directory src/sbmlsolver/internal then.
>
>> ... External applications can then be built
>> without the internal header directory being on
>> their include path.
>
> Ok, so in odeModel.h I have
>
>  typedef struct odeModel odeModel_t;
>
> But then odeModel.h itself needs to have the line
>
> #include "sbmlsolver/internal/odeModelInternal.h"
>
> to find this structure?
>
> Couldn't applications which include odeModel.h still have direct access to
> the the structure because they have the internal header file included via
> odeModel.h?
>
>
>> The internal headers could be called something like
>> odeModelInternal.h or odeModel_Internal.h
>
> So these internal header files can replace both odeModelStruct.h and
> odemodeldatatype.h, right?
>
>> Note you obviously don't have to declare structures and function
>> prototypes
>> in headers.  They can be declared in .c files
>
> Most of our structures and many functions are used in several .c files, so
> these need internal header files if we want to avoid having to use the
> API functions internally, which could become quite painful.
>
>
> Rainer
>
>
>
>
>
>
>
> On Mon, 12 Jun 2006, Andrew Finney wrote:
>
>> Rainer
>>
>> Sounds good
>>
>> I strongly suggest you create a new directory for
>> 'internal' headers.  External applications can then be built
>> without the internal header directory being on
>> their include path.  This would then make it very easy to detect
>> if a dependency on the internal headers has 'drifted' into
>> the API.
>>
>> The internal headers could be called something like
>> odeModelInternal.h or odeModel_Internal.h
>>
>> Note you obviously don't have to declare structures and function
>> prototypes
>> in headers.  They can be declared in .c files
>>
>> yours Andrew
>>
>>> -----Original Message-----
>>> From: sbm...@li...
>>> [mailto:sbm...@li...] On
>>> Behalf Of Rainer Machne
>>> Sent: 12 June 2006 11:18
>>> To: SOSlib Development
>>> Subject: [SOSlib-devel] API reorganization[Scanned]
>>>
>>> Hi All
>>>
>>> the point # 1.4 API reorganization of our online development wiki
>>> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
>>>
>>> might be one thing that should be done soon, before
>>> implementing more functionality.
>>>
>>>
>>>
>>> For some c files we have three header files, e.g.
>>>
>>> odeModel.h
>>> odeModelStruct.h
>>> odemodeldatatype.h
>>>
>>> which confuses me a bit.
>>>
>>>
>>> In odeModel.h we have all the API function definitions,
>>> in odemodeldatatype.h there is only
>>>   typedef struct odeModel odeModel_t;
>>> and in odeModelStruct.h the odeModel structure is defined.
>>>
>>> It was initially thought, and I want to keep it that way, that
>>> applications include the odeModel.h file.
>>>
>>> Then we also have the
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>>   definitions in all header files.
>>>
>>> So what are the requirements for all this?
>>>
>>> The main point is to
>>>
>>> * hide structures and internal functions from calling applications.
>>>
>>> The second point is that we need to
>>>
>>> * map the C code to C++.
>>>
>>> Right?
>>>
>>>
>>>
>>> The following would be my plan:
>>>
>>> in odeModel.h
>>> * SBML_ODESOLVER_API functions
>>> * structure type definitions (only e.g. typedef struct odeModel
>>> odeModel_t)
>>>
>>> in odeModelStruct.h
>>> * the full structure declaration
>>>
>>> Questions:
>>>
>>> What about the third file in the odeModel example. Is this required?
>>>
>>> Where should we move the declarations for internal (non-API)
>>> functions?
>>>
>>> * in odeModel.h but e.g. outside of the
>>> extern "C" {
>>> definitions?
>>>
>>> * in odeModelStruct.h? Should we rename it then?
>>>
>>> happy about any suggestions,
>>> Rainer
>>>
>>>
>>>
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>>
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] variable compartment bug

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

hi Stefan


On Tue, 13 Jun 2006, Stefan Mueller wrote:

> i don't know how compartments are implemented exactly,
> but it is definitely not enough to devide the odes for the amounts by the size
> of the compartment. each amount has to be sclaed by the comportment.
> only then the rate rules for the concentrations can be used.
> i suppose a "doube bookkeeping" of amounts and concs will be necessary...
> cheers, stefan.

Yes, that is what i meant with

>> So we actually should use an ODE system in amount/time instead of
>> concentration/time, and have a second data->value array for concentrations
>> to be used in formula evaluation.

Currently, we construct ODEs and then divide them by the compartment size 
in Species_odeFromReactions.

So this last division will be removed from the ODE.

cvodeSolver then calculates in amount/time (or substance/time). However, 
in the ODE expressions, the species are written in concentrations, i.e. 
amount/volume. Thus the variables x(t) as calculated by sundials need to 
be divided by volume again for formula evaluation by evaluateAST.

You're right, we need a `double bookkeeping'.

data->value should be divided in

data->amount which can be used to initialize sundials and should 
always correspond to N_Vector y.
and
data->concentrations is data->amount / volume and used by evaluateAST and 
to store and print results.

One question is what units are used for species with an assignment rule? 
Is the one declared in the SBML, i.e. either initialAmount or 
initialConcentration, or is it always concentration?

r

>
>
> Am Dienstag 13 Juni 2006 12:42 schrieb Rainer Machne:
>> Folks
>>
>> Lukas has identified another serious bug!
>>
>> SOSlib doesn't support variable compartments.
>>
>> We initialize sundials with ODEs for concentrations d[A]/dt, and sundials
>> calculates [A] + (d[A]/dt)*h, where h is a small time step and [A] is the
>> initial condition or the current value.
>>
>> If we have a variable, e.g time-dependent compartment, then d[A]/dt will
>> change with changing compartment because the compartment size is part of
>> the right hand side.
>>
>> However, not only d[A]/dt is dependent on the volume, but also [A], i.e.
>> the current value in data->value!
>>
>> The attached example file exemplifies this.
>>
>> So we actually should use an ODE system in amount/time instead of
>> concentration/time, and have a second data->value array for concentrations
>> to be used in formula evaluation.
>>
>> Didn't we discuss this once? I remember that I had started to do this
>> (ODEs in amount/time), but then it got more complicated then I
>> thought and something else came up.
>>
>> Can you think of any problems we will run into? Andrew, how about the
>> compiling version?
>>
>> Rainer
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] wrong AST_FUNCTION_ABS implementation

[Stefan M. <ste...@oe...>]

hi rainer!

you are right. currently the implementaion is wrong.
it should be as it's written in the comment.
f(x)=abs(a(x)) => f' = sig(a)*a'

don't worry about the discontinuity at x=0! :)

cheers, s


Am Freitag 09 Juni 2006 17:46 schrieb Rainer Machne:
> Hi Stefan
>
> I am currently going through the code, implementing the style convention
> and getting familiar with SOSlib again :-)
>
> in differentiateAST we have the lines
>
>      case AST_FUNCTION_ABS:             /** ABS: WRONG */
>        /* f(x)=abs(a(x)) => f' = sig(a)*a'
>  	  WRONG: CAN RESULT IN A DISCONTINUOUS FUNCTION! */
>        ASTNode_setType(fprime, ASTNode_getType(f)); /* WRONG !!! */
>        ASTNode_addChild(fprime, differentiateAST(ASTNode_getChild(f,0),x));
>        break;
>
> So it's actually not doing what it claims in the comment, and also there
> are these uppercase WRONG warnings.
>
> What should we do about that. Should we implement it as written in the
> comment?
>
> Rainer
>
>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

Re: [SOSlib-devel] variable compartment bug

[Stefan M. <ste...@oe...>]

i don't know how compartments are implemented exactly,
but it is definitely not enough to devide the odes for the amounts by the size 
of the compartment. each amount has to be sclaed by the comportment.
only then the rate rules for the concentrations can be used.
i suppose a "doube bookkeeping" of amounts and concs will be necessary...
cheers, stefan.


Am Dienstag 13 Juni 2006 12:42 schrieb Rainer Machne:
> Folks
>
> Lukas has identified another serious bug!
>
> SOSlib doesn't support variable compartments.
>
> We initialize sundials with ODEs for concentrations d[A]/dt, and sundials
> calculates [A] + (d[A]/dt)*h, where h is a small time step and [A] is the
> initial condition or the current value.
>
> If we have a variable, e.g time-dependent compartment, then d[A]/dt will
> change with changing compartment because the compartment size is part of
> the right hand side.
>
> However, not only d[A]/dt is dependent on the volume, but also [A], i.e.
> the current value in data->value!
>
> The attached example file exemplifies this.
>
> So we actually should use an ODE system in amount/time instead of
> concentration/time, and have a second data->value array for concentrations
> to be used in formula evaluation.
>
> Didn't we discuss this once? I remember that I had started to do this
> (ODEs in amount/time), but then it got more complicated then I
> thought and something else came up.
>
> Can you think of any problems we will run into? Andrew, how about the
> compiling version?
>
> Rainer

Re: [SOSlib-devel] variable compartment bug[Scanned]

[Andrew F. <af...@ph...>]

Rainer

the complied version will be to be changed as well

yours Andrew=20

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 13 June 2006 11:42
> To: SOSlib Development
> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>=20
> Folks
>=20
> Lukas has identified another serious bug!
>=20
> SOSlib doesn't support variable compartments.
>=20
> We initialize sundials with ODEs for concentrations d[A]/dt,=20
> and sundials calculates [A] + (d[A]/dt)*h, where h is a small=20
> time step and [A] is the initial condition or the current value.
>=20
> If we have a variable, e.g time-dependent compartment, then=20
> d[A]/dt will change with changing compartment because the=20
> compartment size is part of the right hand side.
>=20
> However, not only d[A]/dt is dependent on the volume, but=20
> also [A], i.e.=20
> the current value in data->value!
>=20
> The attached example file exemplifies this.
>=20
> So we actually should use an ODE system in amount/time=20
> instead of concentration/time, and have a second data->value=20
> array for concentrations to be used in formula evaluation.
>=20
> Didn't we discuss this once? I remember that I had started to=20
> do this (ODEs in amount/time), but then it got more=20
> complicated then I thought and something else came up.
>=20
> Can you think of any problems we will run into? Andrew, how=20
> about the compiling version?
>=20
> Rainer
>=20

[SOSlib-devel] variable compartment bug

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

Folks

Lukas has identified another serious bug!

SOSlib doesn't support variable compartments.

We initialize sundials with ODEs for concentrations d[A]/dt, and sundials 
calculates [A] + (d[A]/dt)*h, where h is a small time step and [A] is the 
initial condition or the current value.

If we have a variable, e.g time-dependent compartment, then d[A]/dt will 
change with changing compartment because the compartment size is part of 
the right hand side.

However, not only d[A]/dt is dependent on the volume, but also [A], i.e. 
the current value in data->value!

The attached example file exemplifies this.

So we actually should use an ODE system in amount/time instead of 
concentration/time, and have a second data->value array for concentrations 
to be used in formula evaluation.

Didn't we discuss this once? I remember that I had started to do this 
(ODEs in amount/time), but then it got more complicated then I 
thought and something else came up.

Can you think of any problems we will run into? Andrew, how about the 
compiling version?

Rainer

Re: [SOSlib-devel] API reorganization[Scanned]

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

Andrew,


where do we need the

#ifdef __cplusplus
extern "C" {
#endif

tags?

Only around SBML_ODESOLVER_API functions and typdefs, i.e. in the new API 
headers?

How does it relate to our internal C++ code, and the plan to move 
structures and their interfaces to C++?

Rainer


On Mon, 12 Jun 2006, Andrew Finney wrote:

> Rainer
>
>> But then odeModel.h itself needs to have the line
>>
>> #include "sbmlsolver/internal/odeModelInternal.h"
>>
>> to find this structure?
>>
>
> No.  This line only needs to be present in .c files and in other
> *Internal.h files.
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 12 June 2006 12:05
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: Re: [SOSlib-devel] API reorganization[Scanned]
>>
>>
>> Andrew
>>
>>> I strongly suggest you create a new directory for
>> 'internal' headers.
>>
>> Ok. I'll make another directory src/sbmlsolver/internal then.
>>
>>> ... External applications can then be built without the internal
>>> header directory being on their include path.
>>
>> Ok, so in odeModel.h I have
>>
>>   typedef struct odeModel odeModel_t;
>>
>> But then odeModel.h itself needs to have the line
>>
>> #include "sbmlsolver/internal/odeModelInternal.h"
>>
>> to find this structure?
>>
>> Couldn't applications which include odeModel.h still have
>> direct access to the the structure because they have the
>> internal header file included via odeModel.h?
>>
>>
>>> The internal headers could be called something like
>> odeModelInternal.h
>>> or odeModel_Internal.h
>>
>> So these internal header files can replace both
>> odeModelStruct.h and odemodeldatatype.h, right?
>>
>>> Note you obviously don't have to declare structures and function
>>> prototypes in headers.  They can be declared in .c files
>>
>> Most of our structures and many functions are used in several
>> .c files, so these need internal header files if we want to
>> avoid having to use the API functions internally, which could
>> become quite painful.
>>
>>
>> Rainer
>>
>>
>>
>>
>>
>>
>>
>> On Mon, 12 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> Sounds good
>>>
>>> I strongly suggest you create a new directory for
>> 'internal' headers.
>>> External applications can then be built without the internal header
>>> directory being on their include path.  This would then
>> make it very
>>> easy to detect if a dependency on the internal headers has
>> 'drifted'
>>> into the API.
>>>
>>> The internal headers could be called something like
>> odeModelInternal.h
>>> or odeModel_Internal.h
>>>
>>> Note you obviously don't have to declare structures and function
>>> prototypes in headers.  They can be declared in .c files
>>>
>>> yours Andrew
>>>
>>>> -----Original Message-----
>>>> From: sbm...@li...
>>>> [mailto:sbm...@li...] On
>> Behalf Of
>>>> Rainer Machne
>>>> Sent: 12 June 2006 11:18
>>>> To: SOSlib Development
>>>> Subject: [SOSlib-devel] API reorganization[Scanned]
>>>>
>>>> Hi All
>>>>
>>>> the point # 1.4 API reorganization of our online development wiki
>>>> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
>>>>
>>>> might be one thing that should be done soon, before
>> implementing more
>>>> functionality.
>>>>
>>>>
>>>>
>>>> For some c files we have three header files, e.g.
>>>>
>>>> odeModel.h
>>>> odeModelStruct.h
>>>> odemodeldatatype.h
>>>>
>>>> which confuses me a bit.
>>>>
>>>>
>>>> In odeModel.h we have all the API function definitions, in
>>>> odemodeldatatype.h there is only
>>>>   typedef struct odeModel odeModel_t; and in odeModelStruct.h the
>>>> odeModel structure is defined.
>>>>
>>>> It was initially thought, and I want to keep it that way, that
>>>> applications include the odeModel.h file.
>>>>
>>>> Then we also have the
>>>> #ifdef __cplusplus
>>>> extern "C" {
>>>> #endif
>>>>   definitions in all header files.
>>>>
>>>> So what are the requirements for all this?
>>>>
>>>> The main point is to
>>>>
>>>> * hide structures and internal functions from calling applications.
>>>>
>>>> The second point is that we need to
>>>>
>>>> * map the C code to C++.
>>>>
>>>> Right?
>>>>
>>>>
>>>>
>>>> The following would be my plan:
>>>>
>>>> in odeModel.h
>>>> * SBML_ODESOLVER_API functions
>>>> * structure type definitions (only e.g. typedef struct odeModel
>>>> odeModel_t)
>>>>
>>>> in odeModelStruct.h
>>>> * the full structure declaration
>>>>
>>>> Questions:
>>>>
>>>> What about the third file in the odeModel example. Is this
>> required?
>>>>
>>>> Where should we move the declarations for internal (non-API)
>>>> functions?
>>>>
>>>> * in odeModel.h but e.g. outside of the extern "C" { definitions?
>>>>
>>>> * in odeModelStruct.h? Should we rename it then?
>>>>
>>>> happy about any suggestions,
>>>> Rainer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sbmlsolver-devel mailing list
>>>> sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] [SOSlib-discuss] test

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

sorry. as we don't use the sbmlsolver-discuss list, i removed all 
subscribers there and added the sbmlsolver-devel address as the only 
subscriber. so emails to this public list (by soslib users with questions) 
are forwarded to this list. Ok?


_______________________________________________
sbmlsolver-discuss mailing list
sbm...@li...
https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

Re: [SOSlib-devel] API reorganization[Scanned]

[Andrew F. <af...@ph...>]

Rainer

> But then odeModel.h itself needs to have the line
>=20
> #include "sbmlsolver/internal/odeModelInternal.h"
>=20
> to find this structure?
>=20

No.  This line only needs to be present in .c files and in other
*Internal.h files.

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 12 June 2006 12:05
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] API reorganization[Scanned]
>=20
>=20
> Andrew
>=20
> > I strongly suggest you create a new directory for=20
> 'internal' headers.
>=20
> Ok. I'll make another directory src/sbmlsolver/internal then.
>=20
> > ... External applications can then be built without the internal=20
> > header directory being on their include path.
>=20
> Ok, so in odeModel.h I have
>=20
>   typedef struct odeModel odeModel_t;
>=20
> But then odeModel.h itself needs to have the line
>=20
> #include "sbmlsolver/internal/odeModelInternal.h"
>=20
> to find this structure?
>=20
> Couldn't applications which include odeModel.h still have=20
> direct access to the the structure because they have the=20
> internal header file included via odeModel.h?
>=20
>=20
> > The internal headers could be called something like=20
> odeModelInternal.h=20
> > or odeModel_Internal.h
>=20
> So these internal header files can replace both=20
> odeModelStruct.h and odemodeldatatype.h, right?
>=20
> > Note you obviously don't have to declare structures and function=20
> > prototypes in headers.  They can be declared in .c files
>=20
> Most of our structures and many functions are used in several=20
> .c files, so these need internal header files if we want to=20
> avoid having to use the API functions internally, which could=20
> become quite painful.
>=20
>=20
> Rainer
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Mon, 12 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > Sounds good
> >
> > I strongly suggest you create a new directory for=20
> 'internal' headers. =20
> > External applications can then be built without the internal header=20
> > directory being on their include path.  This would then=20
> make it very=20
> > easy to detect if a dependency on the internal headers has=20
> 'drifted'=20
> > into the API.
> >
> > The internal headers could be called something like=20
> odeModelInternal.h=20
> > or odeModel_Internal.h
> >
> > Note you obviously don't have to declare structures and function=20
> > prototypes in headers.  They can be declared in .c files
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: sbm...@li...
> >> [mailto:sbm...@li...] On=20
> Behalf Of=20
> >> Rainer Machne
> >> Sent: 12 June 2006 11:18
> >> To: SOSlib Development
> >> Subject: [SOSlib-devel] API reorganization[Scanned]
> >>
> >> Hi All
> >>
> >> the point # 1.4 API reorganization of our online development wiki
> >> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
> >>
> >> might be one thing that should be done soon, before=20
> implementing more=20
> >> functionality.
> >>
> >>
> >>
> >> For some c files we have three header files, e.g.
> >>
> >> odeModel.h
> >> odeModelStruct.h
> >> odemodeldatatype.h
> >>
> >> which confuses me a bit.
> >>
> >>
> >> In odeModel.h we have all the API function definitions, in=20
> >> odemodeldatatype.h there is only
> >>   typedef struct odeModel odeModel_t; and in odeModelStruct.h the=20
> >> odeModel structure is defined.
> >>
> >> It was initially thought, and I want to keep it that way, that=20
> >> applications include the odeModel.h file.
> >>
> >> Then we also have the
> >> #ifdef __cplusplus
> >> extern "C" {
> >> #endif
> >>   definitions in all header files.
> >>
> >> So what are the requirements for all this?
> >>
> >> The main point is to
> >>
> >> * hide structures and internal functions from calling applications.
> >>
> >> The second point is that we need to
> >>
> >> * map the C code to C++.
> >>
> >> Right?
> >>
> >>
> >>
> >> The following would be my plan:
> >>
> >> in odeModel.h
> >> * SBML_ODESOLVER_API functions
> >> * structure type definitions (only e.g. typedef struct odeModel
> >> odeModel_t)
> >>
> >> in odeModelStruct.h
> >> * the full structure declaration
> >>
> >> Questions:
> >>
> >> What about the third file in the odeModel example. Is this=20
> required?
> >>
> >> Where should we move the declarations for internal (non-API)=20
> >> functions?
> >>
> >> * in odeModel.h but e.g. outside of the extern "C" { definitions?
> >>
> >> * in odeModelStruct.h? Should we rename it then?
> >>
> >> happy about any suggestions,
> >> Rainer
> >>
> >>
> >>
> >> _______________________________________________
> >> sbmlsolver-devel mailing list
> >> sbm...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>
> >
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20

Re: [SOSlib-devel] API reorganization[Scanned]

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

Andrew

> I strongly suggest you create a new directory for
> 'internal' headers.

Ok. I'll make another directory src/sbmlsolver/internal then.

> ... External applications can then be built
> without the internal header directory being on
> their include path.

Ok, so in odeModel.h I have

  typedef struct odeModel odeModel_t;

But then odeModel.h itself needs to have the line

#include "sbmlsolver/internal/odeModelInternal.h"

to find this structure?

Couldn't applications which include odeModel.h still have direct access to 
the the structure because they have the internal header file included via 
odeModel.h?


> The internal headers could be called something like
> odeModelInternal.h or odeModel_Internal.h

So these internal header files can replace both odeModelStruct.h and 
odemodeldatatype.h, right?

> Note you obviously don't have to declare structures and function
> prototypes
> in headers.  They can be declared in .c files

Most of our structures and many functions are used in several .c files, so 
these need internal header files if we want to avoid having to use the 
API functions internally, which could become quite painful.


Rainer







On Mon, 12 Jun 2006, Andrew Finney wrote:

> Rainer
>
> Sounds good
>
> I strongly suggest you create a new directory for
> 'internal' headers.  External applications can then be built
> without the internal header directory being on
> their include path.  This would then make it very easy to detect
> if a dependency on the internal headers has 'drifted' into
> the API.
>
> The internal headers could be called something like
> odeModelInternal.h or odeModel_Internal.h
>
> Note you obviously don't have to declare structures and function
> prototypes
> in headers.  They can be declared in .c files
>
> yours Andrew
>
>> -----Original Message-----
>> From: sbm...@li...
>> [mailto:sbm...@li...] On
>> Behalf Of Rainer Machne
>> Sent: 12 June 2006 11:18
>> To: SOSlib Development
>> Subject: [SOSlib-devel] API reorganization[Scanned]
>>
>> Hi All
>>
>> the point # 1.4 API reorganization of our online development wiki
>> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
>>
>> might be one thing that should be done soon, before
>> implementing more functionality.
>>
>>
>>
>> For some c files we have three header files, e.g.
>>
>> odeModel.h
>> odeModelStruct.h
>> odemodeldatatype.h
>>
>> which confuses me a bit.
>>
>>
>> In odeModel.h we have all the API function definitions,
>> in odemodeldatatype.h there is only
>>   typedef struct odeModel odeModel_t;
>> and in odeModelStruct.h the odeModel structure is defined.
>>
>> It was initially thought, and I want to keep it that way, that
>> applications include the odeModel.h file.
>>
>> Then we also have the
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>>   definitions in all header files.
>>
>> So what are the requirements for all this?
>>
>> The main point is to
>>
>> * hide structures and internal functions from calling applications.
>>
>> The second point is that we need to
>>
>> * map the C code to C++.
>>
>> Right?
>>
>>
>>
>> The following would be my plan:
>>
>> in odeModel.h
>> * SBML_ODESOLVER_API functions
>> * structure type definitions (only e.g. typedef struct odeModel
>> odeModel_t)
>>
>> in odeModelStruct.h
>> * the full structure declaration
>>
>> Questions:
>>
>> What about the third file in the odeModel example. Is this required?
>>
>> Where should we move the declarations for internal (non-API)
>> functions?
>>
>> * in odeModel.h but e.g. outside of the
>> extern "C" {
>> definitions?
>>
>> * in odeModelStruct.h? Should we rename it then?
>>
>> happy about any suggestions,
>> Rainer
>>
>>
>>
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] API reorganization[Scanned]

[Andrew F. <af...@ph...>]

Rainer

Sounds good

I strongly suggest you create a new directory for=20
'internal' headers.  External applications can then be built
without the internal header directory being on
their include path.  This would then make it very easy to detect
if a dependency on the internal headers has 'drifted' into
the API.

The internal headers could be called something like
odeModelInternal.h or odeModel_Internal.h

Note you obviously don't have to declare structures and function
prototypes
in headers.  They can be declared in .c files

yours Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 12 June 2006 11:18
> To: SOSlib Development
> Subject: [SOSlib-devel] API reorganization[Scanned]
>=20
> Hi All
>=20
> the point # 1.4 API reorganization of our online development wiki
> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
>=20
> might be one thing that should be done soon, before=20
> implementing more functionality.
>=20
>=20
>=20
> For some c files we have three header files, e.g.
>=20
> odeModel.h
> odeModelStruct.h
> odemodeldatatype.h
>=20
> which confuses me a bit.
>=20
>=20
> In odeModel.h we have all the API function definitions,
> in odemodeldatatype.h there is only
>   typedef struct odeModel odeModel_t;
> and in odeModelStruct.h the odeModel structure is defined.
>=20
> It was initially thought, and I want to keep it that way, that=20
> applications include the odeModel.h file.
>=20
> Then we also have the
> #ifdef __cplusplus
> extern "C" {
> #endif
>   definitions in all header files.
>=20
> So what are the requirements for all this?
>=20
> The main point is to
>=20
> * hide structures and internal functions from calling applications.
>=20
> The second point is that we need to
>=20
> * map the C code to C++.
>=20
> Right?
>=20
>=20
>=20
> The following would be my plan:
>=20
> in odeModel.h
> * SBML_ODESOLVER_API functions=20
> * structure type definitions (only e.g. typedef struct odeModel=20
> odeModel_t)
>=20
> in odeModelStruct.h=20
> * the full structure declaration
>=20
> Questions:
>=20
> What about the third file in the odeModel example. Is this required?
>=20
> Where should we move the declarations for internal (non-API)=20
> functions?
>=20
> * in odeModel.h but e.g. outside of the
> extern "C" {
> definitions?
>=20
> * in odeModelStruct.h? Should we rename it then?
>=20
> happy about any suggestions,
> Rainer
>=20
>=20
>=20
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

[SOSlib-devel] API reorganization

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

Hi All

the point # 1.4 API reorganization of our online development wiki
(http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)

might be one thing that should be done soon, before implementing more 
functionality.



For some c files we have three header files, e.g.

odeModel.h
odeModelStruct.h
odemodeldatatype.h

which confuses me a bit.


In odeModel.h we have all the API function definitions,
in odemodeldatatype.h there is only
  typedef struct odeModel odeModel_t;
and in odeModelStruct.h the odeModel structure is defined.

It was initially thought, and I want to keep it that way, that 
applications include the odeModel.h file.

Then we also have the
#ifdef __cplusplus
extern "C" {
#endif
  definitions in all header files.

So what are the requirements for all this?

The main point is to

* hide structures and internal functions from calling applications.

The second point is that we need to

* map the C code to C++.

Right?



The following would be my plan:

in odeModel.h
* SBML_ODESOLVER_API functions 
* structure type definitions (only e.g. typedef struct odeModel 
odeModel_t)

in odeModelStruct.h 
* the full structure declaration

Questions:

What about the third file in the odeModel example. Is this required?

Where should we move the declarations for internal (non-API) functions?

* in odeModel.h but e.g. outside of the
extern "C" {
definitions?

* in odeModelStruct.h? Should we rename it then?

happy about any suggestions,
Rainer

[SOSlib-devel] wrong AST_FUNCTION_ABS implementation

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

Hi Stefan

I am currently going through the code, implementing the style convention 
and getting familiar with SOSlib again :-)

in differentiateAST we have the lines

     case AST_FUNCTION_ABS:             /** ABS: WRONG */
       /* f(x)=abs(a(x)) => f' = sig(a)*a'
 	  WRONG: CAN RESULT IN A DISCONTINUOUS FUNCTION! */
       ASTNode_setType(fprime, ASTNode_getType(f)); /* WRONG !!! */
       ASTNode_addChild(fprime, differentiateAST(ASTNode_getChild(f,0),x));
       break;

So it's actually not doing what it claims in the comment, and also there 
are these uppercase WRONG warnings.

What should we do about that. Should we implement it as written in the 
comment?

Rainer

Re: [SOSlib-devel] more fun on AIX[Scanned]

[Andrew F. <af...@ph...>]

xtof

Many thanks
I seem to be making progress again!

I ran the autogen.sh again
and then repeated the xerces-c for expat substitution

The configure run was successful.
And I have managed to build some files!!!

In fact libODES.a is built which I guess is libSOS!!

I've run into a problem with getopt.h in odeSolver
but its early days with that!

Thanks

Andrew

> -----Original Message-----
> From: Christoph Flamm [mailto:xt...@tb...]=20
> Sent: 09 June 2006 16:15
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] more fun on AIX[Scanned]
>=20
> hi andrew,
>=20
> yes this seems to be the problem.
> you can look into the autogen.sh script in the source of=20
> ODE_solver the right order is
>=20
> aclocal -I config
> autoheader
> automake --add-missing --gnu --copy
>=20
> =3D;) xtof
>=20
> Andrew Finney writes:
>  > xtof
>  >
>  > Thanks for your help
>  >
>  > I think I have buggered up the configuration process.
>  > what is the correct set of commands to setup a=20
> configuration from  > scratch (i.e. generate all the=20
> configure and Makefile.in files) assuming  > a valid set of=20
> config and Makefile.am files?  I'm not a UNIX guru  >  > I=20
> have automake 1.9.6 and autoconf 2.59  >  > (I had to=20
> download and build my own copies as  > the system ones were=20
> too old for libSBML)  >  > I suspect that the lack of macro=20
> expansion in the makefile is causing  > the g++ error :-(  > =20
> > yours Andrew  >  > > -----Original Message-----  > > From:=20
> Christoph Flamm [mailto:xt...@tb...]  > > Sent: 09=20
> June 2006 15:58  > > To: Andrew Finney  > > Cc: SOSlib=20
> Development  > > Subject: Re: [SOSlib-devel] more fun on=20
> AIX[Scanned]  > >  > > hi andrew,  > >  > > g++ (GCC) 3.3.2=20
> is rather old, the current version is g++ (GCC) 4.0.2  > >=20
> which should be available for AIX.
>  > >
>  > > you still have problems with the=20
> automake/autoconf/configure  > > process; your configure=20
> script has not properly substituted  > > the @WHATEVER@=20
> variables from the Makefile.in with the values  > >=20
> determined by the configure script!
>  > >
>  > > which version of automake/autoconf are you using?
>  > > the current one's are:
>  > > automake (GNU automake) 1.9.5
>  > > autoconf (GNU Autoconf) 2.59
>  > >
>  > > =3D;) xtof
>  > >
>  > > Andrew Finney writes:
>  > >  > Rainer
>  > >  >
>  > >  > trying to get SOS lib to compile on AIX has been  >=20
> one  > > long hack and I have not got there yet...
>  > >  >
>  > >  > first:
>  > >  >
>  > >  > - I couldn't get xerces to link with libSBML
>  > >  >    so I'm using expat=20
>  > >  >=20
>  > >  > 	so I replaced xerces-c with expat as you described
>  > >  >
>  > >  > - I removed -Wl,-rpath from sbml.m4  > >  >=20
>  > >  > 	not supported
>  > >  >
>  > >  > - I added libstdc++ and libm to sbml.m4  >=20
>  > >  > 	not there by default
>  > >  >
>  > >  > - one of the makefile.in was missing which required
>  > >  > 	the following:
>  > >  >=20
>  > >  > 	touch src/sbmlsolver/config.h.in
>  > >  > 	aclocal
>  > >  > 	autoconf
>  > >  > 	automake --all-missing
>  > >  >
>  > >  > The above enabled me to complete ./configure  >  >=20
> However  > > when I run gmake at the top level I get:
>  > >  >
>  > >  > ----------------------------------------
>  > >  >
>  > >  > bash-2.05a$ gmake
>  > >  > Making all in src
>  > >  >         if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
>  > >  > @SUNDIALS_CFLAGS@  @G
>  > >  > RAPHVIZ_CFLAGS@  @SBML_CFLAGS@  @GRACE_CFLAGS@  -I.  =20
>   -g -O2 -MT
>  > >  > ASTIndexNameN
>  > >  > ode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o =20
> > > ASTIndexNameNode.o  > ASTIndex  > NameNode.cpp;  then mv=20
> -f  > > ".deps/ASTIndexNameNode.Tpo"
>  > >  > ".deps/ASTIndexNameNode.P
>  > >  > o"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1;=20
> fi  >  > > g++: cannot specify -o with -c or -S and multiple =20
> > > compilations  > make: 1254-004 The error code from the=20
> last  > > command is 1.
>  > >  >
>  > >  >
>  > >  > Stop.
>  > >  > gmake: *** [all-recursive] Error 1  > >  >=20
> bash-2.05a$ g++ --version  > >  > g++ (GCC) 3.3.2  > >  >=20
> Copyright (C) 2003 Free Software Foundation, Inc.
>  > >  > This is free software; see the source for copying  >=20
> > conditions.  There is  > NO  > warranty; not even for  > >=20
> MERCHANTABILITY or FITNESS FOR A PARTICULAR  > PURPOSE.
>  > >  >
>  > >  > -----------------------------
>  > >  >
>  > >  > Is the version of g++ I'm using too old?
>  > >  > Is this make output correct?
>  > >  >
>  > >  > Any ideas would be most helpful
>  > >  >
>  > >  > yours Andrew
>  > >  >
>  > >  >
>  > >  >
>  > >  > _______________________________________________
>  > >  > sbmlsolver-devel mailing list
>  > >  > sbm...@li...
>  > >  > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>  > >
>  > > --
>  > > Christoph Flamm
>  > > Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
>  > >   www: http://www.tbi.univie.ac.at/~xtof
>  > > phone: ++49 341 97-16688 fax: ++49 341 97-16709  > >=20
> email: xt...@bi...  > > smail: Haertelstrasse=20
> 16-18, D-04107 Leipzig, Germany  > >=20
>=20
> --
> Christoph Flamm
> Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
>   www: http://www.tbi.univie.ac.at/~xtof
> phone: ++49 341 97-16688 fax: ++49 341 97-16709
> email: xt...@bi...
> smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany
>=20

Re: [SOSlib-devel] more fun on AIX

[Christoph F. <xt...@tb...>]

hi andrew,

yes this seems to be the problem.
you can look into the autogen.sh script in the source of ODE_solver
the right order is

aclocal -I config
autoheader
automake --add-missing --gnu --copy

=;) xtof

Andrew Finney writes:
 > xtof
 > 
 > Thanks for your help
 > 
 > I think I have buggered up the configuration process.
 > what is the correct set of commands to setup a configuration from
 > scratch (i.e. generate all the configure and Makefile.in files) assuming
 > a valid set of config and Makefile.am files?  I'm not a UNIX guru
 > 
 > I have automake 1.9.6 and autoconf 2.59
 > 
 > (I had to download and build my own copies as
 > the system ones were too old for libSBML)
 > 
 > I suspect that the lack of macro expansion in the makefile is causing
 > the g++ error :-(
 > 
 > yours Andrew
 > 
 > > -----Original Message-----
 > > From: Christoph Flamm [mailto:xt...@tb...] 
 > > Sent: 09 June 2006 15:58
 > > To: Andrew Finney
 > > Cc: SOSlib Development
 > > Subject: Re: [SOSlib-devel] more fun on AIX[Scanned]
 > > 
 > > hi andrew,
 > > 
 > > g++ (GCC) 3.3.2 is rather old, the current version is g++ (GCC) 4.0.2
 > > which should be available for AIX.
 > > 
 > > you still have problems with the automake/autoconf/configure 
 > > process; your configure script has not properly substituted 
 > > the @WHATEVER@ variables from the Makefile.in with the values 
 > > determined by the configure script!
 > > 
 > > which version of automake/autoconf are you using?
 > > the current one's are:
 > > automake (GNU automake) 1.9.5
 > > autoconf (GNU Autoconf) 2.59
 > > 
 > > =;) xtof
 > > 
 > > Andrew Finney writes:
 > >  > Rainer
 > >  >
 > >  > trying to get SOS lib to compile on AIX has been  > one 
 > > long hack and I have not got there yet...
 > >  >
 > >  > first:
 > >  >
 > >  > - I couldn't get xerces to link with libSBML
 > >  >    so I'm using expat 
 > >  > 
 > >  > 	so I replaced xerces-c with expat as you described
 > >  >
 > >  > - I removed -Wl,-rpath from sbml.m4
 > >  > 
 > >  > 	not supported
 > >  >
 > >  > - I added libstdc++ and libm to sbml.m4  > 
 > >  > 	not there by default
 > >  >
 > >  > - one of the makefile.in was missing which required
 > >  > 	the following:
 > >  > 
 > >  > 	touch src/sbmlsolver/config.h.in
 > >  > 	aclocal
 > >  > 	autoconf
 > >  > 	automake --all-missing
 > >  >
 > >  > The above enabled me to complete ./configure  >  > However 
 > > when I run gmake at the top level I get:
 > >  >
 > >  > ----------------------------------------
 > >  >
 > >  > bash-2.05a$ gmake
 > >  > Making all in src
 > >  >         if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
 > >  > @SUNDIALS_CFLAGS@  @G
 > >  > RAPHVIZ_CFLAGS@  @SBML_CFLAGS@  @GRACE_CFLAGS@  -I.     -g -O2 -MT
 > >  > ASTIndexNameN
 > >  > ode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o 
 > > ASTIndexNameNode.o  > ASTIndex  > NameNode.cpp;  then mv -f 
 > > ".deps/ASTIndexNameNode.Tpo"
 > >  > ".deps/ASTIndexNameNode.P
 > >  > o"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi  > 
 > > g++: cannot specify -o with -c or -S and multiple 
 > > compilations  > make: 1254-004 The error code from the last 
 > > command is 1.
 > >  >
 > >  >
 > >  > Stop.
 > >  > gmake: *** [all-recursive] Error 1
 > >  > bash-2.05a$ g++ --version
 > >  > g++ (GCC) 3.3.2
 > >  > Copyright (C) 2003 Free Software Foundation, Inc.
 > >  > This is free software; see the source for copying 
 > > conditions.  There is  > NO  > warranty; not even for 
 > > MERCHANTABILITY or FITNESS FOR A PARTICULAR  > PURPOSE.
 > >  >
 > >  > -----------------------------
 > >  >
 > >  > Is the version of g++ I'm using too old?
 > >  > Is this make output correct?
 > >  >
 > >  > Any ideas would be most helpful
 > >  >
 > >  > yours Andrew
 > >  >
 > >  >
 > >  >
 > >  > _______________________________________________
 > >  > sbmlsolver-devel mailing list
 > >  > sbm...@li...
 > >  > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
 > > 
 > > --
 > > Christoph Flamm
 > > Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
 > >   www: http://www.tbi.univie.ac.at/~xtof
 > > phone: ++49 341 97-16688 fax: ++49 341 97-16709
 > > email: xt...@bi...
 > > smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany
 > > 

-- 
Christoph Flamm
Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
  www: http://www.tbi.univie.ac.at/~xtof
phone: ++49 341 97-16688 fax: ++49 341 97-16709
email: xt...@bi...
smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany

Re: [SOSlib-devel] more fun on AIX

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

hi Andrew and Xtof

> you still have problems with the automake/autoconf/configure process;
> your configure script has not properly substituted the @WHATEVER@ variables
> from the Makefile.in with the values determined by the configure script!

Maybe you take a look in the Makefile. It should have lines like:

SUNDIALS_CFLAGS = -I/scr/fremdling/raim/include

What are the final lines of the ./configure output?
Do you see the paths there? The output there also uses these variables.

> g++ (GCC) 3.3.2 is rather old, the current version is g++ (GCC) 4.0.2
> which should be available for AIX.

Svrci - the compilation expert here sharing the room with me - said 3.3.2 
should be Ok. Fedora Core 4 still had 3.3 versions, he said.

Rainer



On Fri, 9 Jun 2006, Christoph Flamm wrote:

> hi andrew,
>
> g++ (GCC) 3.3.2 is rather old, the current version is g++ (GCC) 4.0.2
> which should be available for AIX.
>
> you still have problems with the automake/autoconf/configure process;
> your configure script has not properly substituted the @WHATEVER@ variables
> from the Makefile.in with the values determined by the configure script!
>
> which version of automake/autoconf are you using?
> the current one's are:
> automake (GNU automake) 1.9.5
> autoconf (GNU Autoconf) 2.59
>
> =;) xtof
>
> Andrew Finney writes:
> > Rainer
> >
> > trying to get SOS lib to compile on AIX has been
> > one long hack and I have not got there yet...
> >
> > first:
> >
> > - I couldn't get xerces to link with libSBML
> >    so I'm using expat
> >
> > 	so I replaced xerces-c with expat as you described
> >
> > - I removed -Wl,-rpath from sbml.m4
> >
> > 	not supported
> >
> > - I added libstdc++ and libm to sbml.m4
> >
> > 	not there by default
> >
> > - one of the makefile.in was missing which required
> > 	the following:
> >
> > 	touch src/sbmlsolver/config.h.in
> > 	aclocal
> > 	autoconf
> > 	automake --all-missing
> >
> > The above enabled me to complete ./configure
> >
> > However when I run gmake at the top level I get:
> >
> > ----------------------------------------
> >
> > bash-2.05a$ gmake
> > Making all in src
> >         if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
> > @SUNDIALS_CFLAGS@  @G
> > RAPHVIZ_CFLAGS@  @SBML_CFLAGS@  @GRACE_CFLAGS@  -I.     -g -O2 -MT
> > ASTIndexNameN
> > ode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o ASTIndexNameNode.o
> > ASTIndex
> > NameNode.cpp;  then mv -f ".deps/ASTIndexNameNode.Tpo"
> > ".deps/ASTIndexNameNode.P
> > o"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
> > g++: cannot specify -o with -c or -S and multiple compilations
> > make: 1254-004 The error code from the last command is 1.
> >
> >
> > Stop.
> > gmake: *** [all-recursive] Error 1
> > bash-2.05a$ g++ --version
> > g++ (GCC) 3.3.2
> > Copyright (C) 2003 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is
> > NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> >
> > -----------------------------
> >
> > Is the version of g++ I'm using too old?
> > Is this make output correct?
> >
> > Any ideas would be most helpful
> >
> > yours Andrew
> >
> >
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>
>

Re: [SOSlib-devel] more fun on AIX

[Andrew F. <af...@ph...>]

xtof

Thanks for your help

I think I have buggered up the configuration process.
what is the correct set of commands to setup a configuration from
scratch (i.e. generate all the configure and Makefile.in files) assuming
a valid set of config and Makefile.am files?  I'm not a UNIX guru

I have automake 1.9.6 and autoconf 2.59

(I had to download and build my own copies as
the system ones were too old for libSBML)

I suspect that the lack of macro expansion in the makefile is causing
the g++ error :-(

yours Andrew

> -----Original Message-----
> From: Christoph Flamm [mailto:xt...@tb...]=20
> Sent: 09 June 2006 15:58
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] more fun on AIX[Scanned]
>=20
> hi andrew,
>=20
> g++ (GCC) 3.3.2 is rather old, the current version is g++ (GCC) 4.0.2
> which should be available for AIX.
>=20
> you still have problems with the automake/autoconf/configure=20
> process; your configure script has not properly substituted=20
> the @WHATEVER@ variables from the Makefile.in with the values=20
> determined by the configure script!
>=20
> which version of automake/autoconf are you using?
> the current one's are:
> automake (GNU automake) 1.9.5
> autoconf (GNU Autoconf) 2.59
>=20
> =3D;) xtof
>=20
> Andrew Finney writes:
>  > Rainer
>  >
>  > trying to get SOS lib to compile on AIX has been  > one=20
> long hack and I have not got there yet...
>  >
>  > first:
>  >
>  > - I couldn't get xerces to link with libSBML
>  >    so I'm using expat=20
>  >=20
>  > 	so I replaced xerces-c with expat as you described
>  >
>  > - I removed -Wl,-rpath from sbml.m4
>  >=20
>  > 	not supported
>  >
>  > - I added libstdc++ and libm to sbml.m4  >=20
>  > 	not there by default
>  >
>  > - one of the makefile.in was missing which required
>  > 	the following:
>  >=20
>  > 	touch src/sbmlsolver/config.h.in
>  > 	aclocal
>  > 	autoconf
>  > 	automake --all-missing
>  >
>  > The above enabled me to complete ./configure  >  > However=20
> when I run gmake at the top level I get:
>  >
>  > ----------------------------------------
>  >
>  > bash-2.05a$ gmake
>  > Making all in src
>  >         if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
>  > @SUNDIALS_CFLAGS@  @G
>  > RAPHVIZ_CFLAGS@  @SBML_CFLAGS@  @GRACE_CFLAGS@  -I.     -g -O2 -MT
>  > ASTIndexNameN
>  > ode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o=20
> ASTIndexNameNode.o  > ASTIndex  > NameNode.cpp;  then mv -f=20
> ".deps/ASTIndexNameNode.Tpo"
>  > ".deps/ASTIndexNameNode.P
>  > o"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi  >=20
> g++: cannot specify -o with -c or -S and multiple=20
> compilations  > make: 1254-004 The error code from the last=20
> command is 1.
>  >
>  >
>  > Stop.
>  > gmake: *** [all-recursive] Error 1
>  > bash-2.05a$ g++ --version
>  > g++ (GCC) 3.3.2
>  > Copyright (C) 2003 Free Software Foundation, Inc.
>  > This is free software; see the source for copying=20
> conditions.  There is  > NO  > warranty; not even for=20
> MERCHANTABILITY or FITNESS FOR A PARTICULAR  > PURPOSE.
>  >
>  > -----------------------------
>  >
>  > Is the version of g++ I'm using too old?
>  > Is this make output correct?
>  >
>  > Any ideas would be most helpful
>  >
>  > yours Andrew
>  >
>  >
>  >
>  > _______________________________________________
>  > sbmlsolver-devel mailing list
>  > sbm...@li...
>  > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20
> --
> Christoph Flamm
> Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
>   www: http://www.tbi.univie.ac.at/~xtof
> phone: ++49 341 97-16688 fax: ++49 341 97-16709
> email: xt...@bi...
> smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany
>=20

Re: [SOSlib-devel] more fun on AIX

[Christoph F. <xt...@tb...>]

hi andrew,

g++ (GCC) 3.3.2 is rather old, the current version is g++ (GCC) 4.0.2
which should be available for AIX.

you still have problems with the automake/autoconf/configure process;
your configure script has not properly substituted the @WHATEVER@ variables
from the Makefile.in with the values determined by the configure script!

which version of automake/autoconf are you using?
the current one's are:
automake (GNU automake) 1.9.5
autoconf (GNU Autoconf) 2.59

=;) xtof

Andrew Finney writes:
 > Rainer
 > 
 > trying to get SOS lib to compile on AIX has been 
 > one long hack and I have not got there yet...
 > 
 > first:
 > 
 > - I couldn't get xerces to link with libSBML
 >    so I'm using expat 
 > 
 > 	so I replaced xerces-c with expat as you described
 > 
 > - I removed -Wl,-rpath from sbml.m4
 > 
 > 	not supported
 >  
 > - I added libstdc++ and libm to sbml.m4
 > 
 > 	not there by default
 > 
 > - one of the makefile.in was missing which required
 > 	the following:
 > 
 > 	touch src/sbmlsolver/config.h.in
 > 	aclocal
 > 	autoconf
 > 	automake --all-missing
 > 
 > The above enabled me to complete ./configure
 > 
 > However when I run gmake at the top level I get:
 > 
 > ----------------------------------------
 > 
 > bash-2.05a$ gmake
 > Making all in src
 >         if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
 > @SUNDIALS_CFLAGS@  @G
 > RAPHVIZ_CFLAGS@  @SBML_CFLAGS@  @GRACE_CFLAGS@  -I.     -g -O2 -MT
 > ASTIndexNameN
 > ode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o ASTIndexNameNode.o
 > ASTIndex
 > NameNode.cpp;  then mv -f ".deps/ASTIndexNameNode.Tpo"
 > ".deps/ASTIndexNameNode.P
 > o"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
 > g++: cannot specify -o with -c or -S and multiple compilations
 > make: 1254-004 The error code from the last command is 1.
 > 
 > 
 > Stop.
 > gmake: *** [all-recursive] Error 1
 > bash-2.05a$ g++ --version
 > g++ (GCC) 3.3.2
 > Copyright (C) 2003 Free Software Foundation, Inc.
 > This is free software; see the source for copying conditions.  There is
 > NO
 > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
 > PURPOSE.
 > 
 > -----------------------------
 > 
 > Is the version of g++ I'm using too old?
 > Is this make output correct?
 > 
 > Any ideas would be most helpful
 > 
 > yours Andrew
 > 
 > 
 > 
 > _______________________________________________
 > sbmlsolver-devel mailing list
 > sbm...@li...
 > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

-- 
Christoph Flamm
Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
  www: http://www.tbi.univie.ac.at/~xtof
phone: ++49 341 97-16688 fax: ++49 341 97-16709
email: xt...@bi...
smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany

[SOSlib-devel] more fun on AIX

[Andrew F. <af...@ph...>]

Rainer

trying to get SOS lib to compile on AIX has been=20
one long hack and I have not got there yet...

first:

- I couldn't get xerces to link with libSBML
   so I'm using expat=20

	so I replaced xerces-c with expat as you described

- I removed -Wl,-rpath from sbml.m4

	not supported
=20
- I added libstdc++ and libm to sbml.m4

	not there by default

- one of the makefile.in was missing which required
	the following:

	touch src/sbmlsolver/config.h.in
	aclocal
	autoconf
	automake --all-missing

The above enabled me to complete ./configure

However when I run gmake at the top level I get:

----------------------------------------

bash-2.05a$ gmake
Making all in src
        if g++ -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
@SUNDIALS_CFLAGS@  @G
RAPHVIZ_CFLAGS@  @SBML_CFLAGS@  @GRACE_CFLAGS@  -I.     -g -O2 -MT
ASTIndexNameN
ode.o -MD -MP -MF ".deps/ASTIndexNameNode.Tpo" -c -o ASTIndexNameNode.o
ASTIndex
NameNode.cpp;  then mv -f ".deps/ASTIndexNameNode.Tpo"
".deps/ASTIndexNameNode.P
o"; else rm -f ".deps/ASTIndexNameNode.Tpo"; exit 1; fi
g++: cannot specify -o with -c or -S and multiple compilations
make: 1254-004 The error code from the last command is 1.


Stop.
gmake: *** [all-recursive] Error 1
bash-2.05a$ g++ --version
g++ (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

-----------------------------

Is the version of g++ I'm using too old?
Is this make output correct?

Any ideas would be most helpful

yours Andrew

Re: [SOSlib-devel] building SBML ODE Solver for AIX - can Iuse expat?[Scanned]

[Andrew F. <af...@ph...>]

Akira

you were right.  I removed the rpath option and got gcc to run however
I now have a whole load of undefined symbols that seems to be form the
standard template library. =20

Is there any obvious STL or runtime libraries I might be missing?

yours Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Akira Funahashi
> Sent: 08 June 2006 15:39
> To: Andrew Finney
> Cc: sbm...@li...
> Subject: Re: [SOSlib-devel] building SBML ODE Solver for AIX=20
> - can Iuse expat?[Scanned]
>=20
> Hi,=20
>=20
> At Thu, 8 Jun 2006 15:20:05 +0100,
> "Andrew Finney" <af...@ph...> wrote:
> > configure:4220: result: no:
> >                    CFLAGS=3D-g -O2=20
> -I/hpc/home/finneya/programs/include
> >                    LDFLAGS=3D=20
> -Wl,-rpath,/hpc/home/finneya/programs/lib
> > -L/hpc/home/finneya/programs/lib
> >                    LIBS=3D -lexpat -lsbml
> > configure:4228: error: Can not link to SBML Library:
> > 		  Please, make sure to use libSBML version >=3D 2.3.2
> >=20
> > ------------------
> >=20
> > It looks as if the loader (ld) isn't performing as expected :-(
> >=20
> > what's the -rpath supposed to do?
>=20
> "-Wl,-rpath" is used to specify the library path which is=20
> used by the compiled binary at runtime.
>=20
> On the other hand, "-L" is used to specify the library path=20
> which is used at its compile.
>=20
> For example, if you compile a binary as follows:
>=20
>   gcc -L/home/funa/ -lsbml -Wl,-rpath=3D/usr/local/lib
>=20
> the gcc will try to find libsbml in /home/funa at the=20
> compile, and the compiled binary/library will look for=20
> libsbml in /usr/local/lib at its execution.
>=20
> Some platform doesn't support "-Wl,-rpath" option. It depends=20
> on the version of gcc or ld (correct me if I'm wrong).
> So try removing -Wl,-rpath in the configure script.
>=20
> Hope this helps,
> --
> Akira Funahashi, Ph.D. | Kitano Symbiotic Systems Project,=20
> [fu...@sy...]| ERATO-SORST, JST
>=20
>=20
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

Re: [SOSlib-devel] building SBML ODE Solver for AIX - can I use expat?[Scanned]

[Christoph F. <xt...@tb...>]

hi rainer, andrew,

yes some of the libsbml versions need the
-I/hpc/home/finneya/programs/include/sbml added to the CFLAGS.

you can remove the -rpath from the LDFLAGS and put the specified paths
into your LD_LIBRARY_PATH variable, so that the shared libraries are
found at runtime.

=;) xtof

Rainer Machne writes:
 > Andrew
 > 
 > On Thu, 8 Jun 2006, Andrew Finney wrote:
 > 
 > > This is a not so recent version of 1.6.0
 > 
 > If it's not the official release version, then it might be missing
 > included the work-around for libSBML version inconsistencies.
 > 
 > Your CFLAGS where
 > 
 > >>  CFLAGS=-g -O2 -I/hpc/home/finneya/programs/include
 > 
 > The latest version of the configure process two values for the include 
 > path for libSBML. 
 > The second value in your case would be
 > 
 >   -I/hpc/home/finneya/programs/include/sbml
 > 
 > I think this was necessary because of different structuring of the header 
 > files in different libSBML versions. Is this correct, Christoph?
 > 
 > You could try to add the second path to the CFLAGS or just use the 
 > official release version.
 > 
 > Rainer
 > 
 > >
 > > Andrew
 > >> -----Original Message-----
 > >> From: Rainer Machne [mailto:ra...@tb...]
 > >> Sent: 08 June 2006 15:25
 > >> To: Andrew Finney; Christoph Flamm
 > >> Cc: SOSlib Development
 > >> Subject: Re: [SOSlib-devel] building SBML ODE Solver for AIX
 > >> - can I use expat?[Scanned]
 > >>
 > >>
 > >>>
 > >>> It looks as if the loader (ld) isn't performing as expected :-(
 > >>>
 > >>> what's the -rpath supposed to do?
 > >>
 > >>
 > >> Maybe Xtof can help out here.
 > >>
 > >> Just a short question: are you trying to compile version
 > >> 1.5.0 or is there an old version number hidden somewhere in
 > >> the configure process?
 > >>
 > >> Rainer
 > >>
 > >> On Thu, 8 Jun 2006, Andrew Finney wrote:
 > >>
 > >>> Rainer
 > >>>
 > >>> I managed to substitute expat for xerces
 > >>>
 > >>> But I still can't link to libsbml in the config.log
 > >>> (attached)
 > >>> I get the following:
 > >>>
 > >>> ---------------------------------
 > >>>
 > >>> configure:4155: checking correct functioning of SBML
 > >>> configure:4185: gcc -o conftest -g -O2
 > >>> -I/hpc/home/finneya/programs/include
 > >>> -Wl,-rpath,/hpc/home/finneya/programs/lib
 > >>> -L/hpc/home/finneya/programs/lib conftest.c  -lexpat -lsbml >&5
 > >>> ld: 0706-012 The -p flag is not recognized.
 > >>> ld: 0706-012 The -a flag is not recognized.
 > >>> ld: 0706-012 The -t flag is not recognized.
 > >>> ld: 0706-012 The -h flag is not recognized.
 > >>> collect2: ld returned 255 exit status
 > >>> configure:4191: $? = 1
 > >>> configure: failed program was:
 > >>> | /* confdefs.h.  */
 > >>> |
 > >>> | #define PACKAGE_NAME "odeSolver"
 > >>> | #define PACKAGE_TARNAME "SBML_odeSolver"
 > >>> | #define PACKAGE_VERSION "1.5.0"
 > >>> | #define PACKAGE_STRING "odeSolver 1.5.0"
 > >>> | #define PACKAGE_BUGREPORT "{raim,xtof}@tbi.univie.ac.at"
 > >>> | #define PACKAGE "SBML_odeSolver"
 > >>> | #define VERSION "1.5.0"
 > >>> | #ifdef __cplusplus
 > >>> | extern "C" void std::exit (int) throw (); using std::exit; #endif
 > >>> | /* end confdefs.h.  */
 > >>> | #include <sbml/SBMLTypes.h>
 > >>> | int
 > >>> | main ()
 > >>> | {
 > >>> | SBMLReader_t *sr; sr = SBMLReader_create(); SBMLReader_free(sr);
 > >>> |   ;
 > >>> |   return 0;
 > >>> | }
 > >>> configure:4220: result: no:
 > >>>                   CFLAGS=-g -O2 -I/hpc/home/finneya/programs/include
 > >>>                   LDFLAGS= -Wl,-rpath,/hpc/home/finneya/programs/lib
 > >>> -L/hpc/home/finneya/programs/lib
 > >>>                   LIBS= -lexpat -lsbml
 > >>> configure:4228: error: Can not link to SBML Library:
 > >>> 		  Please, make sure to use libSBML version >= 2.3.2
 > >>>
 > >>> ------------------
 > >>>
 > >>> It looks as if the loader (ld) isn't performing as expected :-(
 > >>>
 > >>> what's the -rpath supposed to do?
 > >>>
 > >>> yours Andrew
 > >>>
 > >>>
 > >>>> -----Original Message-----
 > >>>> From: Rainer Machne [mailto:ra...@tb...]
 > >>>> Sent: 08 June 2006 14:13
 > >>>> To: Andrew Finney
 > >>>> Cc: SOSlib Development
 > >>>> Subject: Re: building SBML ODE Solver for AIX - can I use
 > >>>> expat?[Scanned]
 > >>>>
 > >>>> Hi Andrew
 > >>>>
 > >>>> Unfortunately we completely forgot about libSBML with expat.
 > >>>>
 > >>>> There is a bug report in sourceforge with short instructions.
 > >>>> http://sourceforge.net/tracker/index.php?func=detail&aid=14204
 > >>>> 89&group_id=139893&atid=744811
 > >>>>
 > >>>>
 > >>>> Copied from there, with slight corrections:
 > >>>>
 > >>>> This bug can temporarily be solved simply by replacing all
 > >> occurences
 > >>>> of
 > >>>>
 > >>>> `-lxerces-c'
 > >>>>
 > >>>> in the files:
 > >>>>
 > >>>> configure
 > >>>> src/Makefile.am
 > >>>> src/Makefile.in
 > >>>> examples/Makefile.am
 > >>>> examples/Makefile.in
 > >>>> odeSolver/Makefile.am
 > >>>> odeSolver/Makefile.in
 > >>>>
 > >>>> with `-lexpat'
 > >>>>
 > >>>> e.g. by usind sed:
 > >>>>
 > >>>> sed 's/xerces-c/expat/g' configure >configure.new mv configure.new
 > >>>> configure
 > >>>>
 > >>>> for all above files.
 > >>>>
 > >>>>
 > >>>> I tried it once and it worked! Please let me know if you suceed!
 > >>>>
 > >>>> Rainer
 > >>>>
 > >>>>
 > >>>>
 > >>>> On Thu, 8 Jun 2006, Andrew Finney wrote:
 > >>>>
 > >>>>> Rainer
 > >>>>>
 > >>>>> I'm trying to build SOS on AIX
 > >>>>>
 > >>>>> for some reason I'm having problems linking with xerces for that
 > >>>>> platform
 > >>>>>
 > >>>>> Is there a way to configure SOS to use expat?
 > >>>>>
 > >>>>> Andrew
 > >>>>>
 > >>>>
 > >>>
 > >>
 > >
 > 
 > 
 > _______________________________________________
 > sbmlsolver-devel mailing list
 > sbm...@li...
 > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

-- 
Christoph Flamm
Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
  www: http://www.tbi.univie.ac.at/~xtof
phone: ++49 341 97-16688 fax: ++49 341 97-16709
email: xt...@bi...
smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany

Re: [SOSlib-devel] building SBML ODE Solver for AIX - can I use expat?[Scanned]

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

Andrew

On Thu, 8 Jun 2006, Andrew Finney wrote:

> This is a not so recent version of 1.6.0

If it's not the official release version, then it might be missing
included the work-around for libSBML version inconsistencies.

Your CFLAGS where

>>  CFLAGS=-g -O2 -I/hpc/home/finneya/programs/include

The latest version of the configure process two values for the include 
path for libSBML. 
The second value in your case would be

  -I/hpc/home/finneya/programs/include/sbml

I think this was necessary because of different structuring of the header 
files in different libSBML versions. Is this correct, Christoph?

You could try to add the second path to the CFLAGS or just use the 
official release version.

Rainer

>
> Andrew
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 08 June 2006 15:25
>> To: Andrew Finney; Christoph Flamm
>> Cc: SOSlib Development
>> Subject: Re: [SOSlib-devel] building SBML ODE Solver for AIX
>> - can I use expat?[Scanned]
>>
>>
>>>
>>> It looks as if the loader (ld) isn't performing as expected :-(
>>>
>>> what's the -rpath supposed to do?
>>
>>
>> Maybe Xtof can help out here.
>>
>> Just a short question: are you trying to compile version
>> 1.5.0 or is there an old version number hidden somewhere in
>> the configure process?
>>
>> Rainer
>>
>> On Thu, 8 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> I managed to substitute expat for xerces
>>>
>>> But I still can't link to libsbml in the config.log
>>> (attached)
>>> I get the following:
>>>
>>> ---------------------------------
>>>
>>> configure:4155: checking correct functioning of SBML
>>> configure:4185: gcc -o conftest -g -O2
>>> -I/hpc/home/finneya/programs/include
>>> -Wl,-rpath,/hpc/home/finneya/programs/lib
>>> -L/hpc/home/finneya/programs/lib conftest.c  -lexpat -lsbml >&5
>>> ld: 0706-012 The -p flag is not recognized.
>>> ld: 0706-012 The -a flag is not recognized.
>>> ld: 0706-012 The -t flag is not recognized.
>>> ld: 0706-012 The -h flag is not recognized.
>>> collect2: ld returned 255 exit status
>>> configure:4191: $? = 1
>>> configure: failed program was:
>>> | /* confdefs.h.  */
>>> |
>>> | #define PACKAGE_NAME "odeSolver"
>>> | #define PACKAGE_TARNAME "SBML_odeSolver"
>>> | #define PACKAGE_VERSION "1.5.0"
>>> | #define PACKAGE_STRING "odeSolver 1.5.0"
>>> | #define PACKAGE_BUGREPORT "{raim,xtof}@tbi.univie.ac.at"
>>> | #define PACKAGE "SBML_odeSolver"
>>> | #define VERSION "1.5.0"
>>> | #ifdef __cplusplus
>>> | extern "C" void std::exit (int) throw (); using std::exit; #endif
>>> | /* end confdefs.h.  */
>>> | #include <sbml/SBMLTypes.h>
>>> | int
>>> | main ()
>>> | {
>>> | SBMLReader_t *sr; sr = SBMLReader_create(); SBMLReader_free(sr);
>>> |   ;
>>> |   return 0;
>>> | }
>>> configure:4220: result: no:
>>>                   CFLAGS=-g -O2 -I/hpc/home/finneya/programs/include
>>>                   LDFLAGS= -Wl,-rpath,/hpc/home/finneya/programs/lib
>>> -L/hpc/home/finneya/programs/lib
>>>                   LIBS= -lexpat -lsbml
>>> configure:4228: error: Can not link to SBML Library:
>>> 		  Please, make sure to use libSBML version >= 2.3.2
>>>
>>> ------------------
>>>
>>> It looks as if the loader (ld) isn't performing as expected :-(
>>>
>>> what's the -rpath supposed to do?
>>>
>>> yours Andrew
>>>
>>>
>>>> -----Original Message-----
>>>> From: Rainer Machne [mailto:ra...@tb...]
>>>> Sent: 08 June 2006 14:13
>>>> To: Andrew Finney
>>>> Cc: SOSlib Development
>>>> Subject: Re: building SBML ODE Solver for AIX - can I use
>>>> expat?[Scanned]
>>>>
>>>> Hi Andrew
>>>>
>>>> Unfortunately we completely forgot about libSBML with expat.
>>>>
>>>> There is a bug report in sourceforge with short instructions.
>>>> http://sourceforge.net/tracker/index.php?func=detail&aid=14204
>>>> 89&group_id=139893&atid=744811
>>>>
>>>>
>>>> Copied from there, with slight corrections:
>>>>
>>>> This bug can temporarily be solved simply by replacing all
>> occurences
>>>> of
>>>>
>>>> `-lxerces-c'
>>>>
>>>> in the files:
>>>>
>>>> configure
>>>> src/Makefile.am
>>>> src/Makefile.in
>>>> examples/Makefile.am
>>>> examples/Makefile.in
>>>> odeSolver/Makefile.am
>>>> odeSolver/Makefile.in
>>>>
>>>> with `-lexpat'
>>>>
>>>> e.g. by usind sed:
>>>>
>>>> sed 's/xerces-c/expat/g' configure >configure.new mv configure.new
>>>> configure
>>>>
>>>> for all above files.
>>>>
>>>>
>>>> I tried it once and it worked! Please let me know if you suceed!
>>>>
>>>> Rainer
>>>>
>>>>
>>>>
>>>> On Thu, 8 Jun 2006, Andrew Finney wrote:
>>>>
>>>>> Rainer
>>>>>
>>>>> I'm trying to build SOS on AIX
>>>>>
>>>>> for some reason I'm having problems linking with xerces for that
>>>>> platform
>>>>>
>>>>> Is there a way to configure SOS to use expat?
>>>>>
>>>>> Andrew
>>>>>
>>>>
>>>
>>
>

Re: [SOSlib-devel] building SBML ODE Solver for AIX - can I use expat?[Scanned]

[Akira F. <fu...@sy...>]

Hi, 

At Thu, 8 Jun 2006 15:20:05 +0100,
"Andrew Finney" <af...@ph...> wrote:
> configure:4220: result: no:
>                    CFLAGS=-g -O2 -I/hpc/home/finneya/programs/include
>                    LDFLAGS= -Wl,-rpath,/hpc/home/finneya/programs/lib
> -L/hpc/home/finneya/programs/lib
>                    LIBS= -lexpat -lsbml
> configure:4228: error: Can not link to SBML Library:
> 		  Please, make sure to use libSBML version >= 2.3.2
> 
> ------------------
> 
> It looks as if the loader (ld) isn't performing as expected :-(
> 
> what's the -rpath supposed to do?

"-Wl,-rpath" is used to specify the library path which is used by
the compiled binary at runtime.

On the other hand, "-L" is used to specify the library path which is
used at its compile.

For example, if you compile a binary as follows:

  gcc -L/home/funa/ -lsbml -Wl,-rpath=/usr/local/lib

the gcc will try to find libsbml in /home/funa at the compile, and the
compiled binary/library will look for libsbml in /usr/local/lib at its
execution.

Some platform doesn't support "-Wl,-rpath" option. It depends on the
version of gcc or ld (correct me if I'm wrong).
So try removing -Wl,-rpath in the configure script.

Hope this helps,
-- 
Akira Funahashi, Ph.D. | Kitano Symbiotic Systems Project,
[fu...@sy...]| ERATO-SORST, JST

Re: [SOSlib-devel] building SBML ODE Solver for AIX - can I use expat?[Scanned]

[Andrew F. <af...@ph...>]

This is a not so recent version of 1.6.0=20

Andrew
> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 08 June 2006 15:25
> To: Andrew Finney; Christoph Flamm
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] building SBML ODE Solver for AIX=20
> - can I use expat?[Scanned]
>=20
>=20
> >
> > It looks as if the loader (ld) isn't performing as expected :-(
> >
> > what's the -rpath supposed to do?
>=20
>=20
> Maybe Xtof can help out here.
>=20
> Just a short question: are you trying to compile version=20
> 1.5.0 or is there an old version number hidden somewhere in=20
> the configure process?
>=20
> Rainer
>=20
> On Thu, 8 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > I managed to substitute expat for xerces
> >
> > But I still can't link to libsbml in the config.log
> > (attached)
> > I get the following:
> >
> > ---------------------------------
> >
> > configure:4155: checking correct functioning of SBML
> > configure:4185: gcc -o conftest -g -O2=20
> > -I/hpc/home/finneya/programs/include
> > -Wl,-rpath,/hpc/home/finneya/programs/lib
> > -L/hpc/home/finneya/programs/lib conftest.c  -lexpat -lsbml >&5
> > ld: 0706-012 The -p flag is not recognized.
> > ld: 0706-012 The -a flag is not recognized.
> > ld: 0706-012 The -t flag is not recognized.
> > ld: 0706-012 The -h flag is not recognized.
> > collect2: ld returned 255 exit status
> > configure:4191: $? =3D 1
> > configure: failed program was:
> > | /* confdefs.h.  */
> > |
> > | #define PACKAGE_NAME "odeSolver"
> > | #define PACKAGE_TARNAME "SBML_odeSolver"
> > | #define PACKAGE_VERSION "1.5.0"
> > | #define PACKAGE_STRING "odeSolver 1.5.0"
> > | #define PACKAGE_BUGREPORT "{raim,xtof}@tbi.univie.ac.at"
> > | #define PACKAGE "SBML_odeSolver"
> > | #define VERSION "1.5.0"
> > | #ifdef __cplusplus
> > | extern "C" void std::exit (int) throw (); using std::exit; #endif
> > | /* end confdefs.h.  */
> > | #include <sbml/SBMLTypes.h>
> > | int
> > | main ()
> > | {
> > | SBMLReader_t *sr; sr =3D SBMLReader_create(); SBMLReader_free(sr);
> > |   ;
> > |   return 0;
> > | }
> > configure:4220: result: no:
> >                   CFLAGS=3D-g -O2 =
-I/hpc/home/finneya/programs/include
> >                   LDFLAGS=3D =
-Wl,-rpath,/hpc/home/finneya/programs/lib
> > -L/hpc/home/finneya/programs/lib
> >                   LIBS=3D -lexpat -lsbml
> > configure:4228: error: Can not link to SBML Library:
> > 		  Please, make sure to use libSBML version >=3D 2.3.2
> >
> > ------------------
> >
> > It looks as if the loader (ld) isn't performing as expected :-(
> >
> > what's the -rpath supposed to do?
> >
> > yours Andrew
> >
> >
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 08 June 2006 14:13
> >> To: Andrew Finney
> >> Cc: SOSlib Development
> >> Subject: Re: building SBML ODE Solver for AIX - can I use=20
> >> expat?[Scanned]
> >>
> >> Hi Andrew
> >>
> >> Unfortunately we completely forgot about libSBML with expat.
> >>
> >> There is a bug report in sourceforge with short instructions.
> >> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D14204
> >> 89&group_id=3D139893&atid=3D744811
> >>
> >>
> >> Copied from there, with slight corrections:
> >>
> >> This bug can temporarily be solved simply by replacing all=20
> occurences=20
> >> of
> >>
> >> `-lxerces-c'
> >>
> >> in the files:
> >>
> >> configure
> >> src/Makefile.am
> >> src/Makefile.in
> >> examples/Makefile.am
> >> examples/Makefile.in
> >> odeSolver/Makefile.am
> >> odeSolver/Makefile.in
> >>
> >> with `-lexpat'
> >>
> >> e.g. by usind sed:
> >>
> >> sed 's/xerces-c/expat/g' configure >configure.new mv configure.new=20
> >> configure
> >>
> >> for all above files.
> >>
> >>
> >> I tried it once and it worked! Please let me know if you suceed!
> >>
> >> Rainer
> >>
> >>
> >>
> >> On Thu, 8 Jun 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>> I'm trying to build SOS on AIX
> >>>
> >>> for some reason I'm having problems linking with xerces for that=20
> >>> platform
> >>>
> >>> Is there a way to configure SOS to use expat?
> >>>
> >>> Andrew
> >>>
> >>
> >
>=20

Re: [SOSlib-devel] building SBML ODE Solver for AIX - can I use expat?[Scanned]

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

>
> It looks as if the loader (ld) isn't performing as expected :-(
>
> what's the -rpath supposed to do?


Maybe Xtof can help out here.

Just a short question: are you trying to compile version 1.5.0 or is there 
an old version number hidden somewhere in the configure process?

Rainer

On Thu, 8 Jun 2006, Andrew Finney wrote:

> Rainer
>
> I managed to substitute expat for xerces
>
> But I still can't link to libsbml in the config.log
> (attached)
> I get the following:
>
> ---------------------------------
>
> configure:4155: checking correct functioning of SBML
> configure:4185: gcc -o conftest -g -O2
> -I/hpc/home/finneya/programs/include
> -Wl,-rpath,/hpc/home/finneya/programs/lib
> -L/hpc/home/finneya/programs/lib conftest.c  -lexpat -lsbml >&5
> ld: 0706-012 The -p flag is not recognized.
> ld: 0706-012 The -a flag is not recognized.
> ld: 0706-012 The -t flag is not recognized.
> ld: 0706-012 The -h flag is not recognized.
> collect2: ld returned 255 exit status
> configure:4191: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> |
> | #define PACKAGE_NAME "odeSolver"
> | #define PACKAGE_TARNAME "SBML_odeSolver"
> | #define PACKAGE_VERSION "1.5.0"
> | #define PACKAGE_STRING "odeSolver 1.5.0"
> | #define PACKAGE_BUGREPORT "{raim,xtof}@tbi.univie.ac.at"
> | #define PACKAGE "SBML_odeSolver"
> | #define VERSION "1.5.0"
> | #ifdef __cplusplus
> | extern "C" void std::exit (int) throw (); using std::exit;
> | #endif
> | /* end confdefs.h.  */
> | #include <sbml/SBMLTypes.h>
> | int
> | main ()
> | {
> | SBMLReader_t *sr; sr = SBMLReader_create(); SBMLReader_free(sr);
> |   ;
> |   return 0;
> | }
> configure:4220: result: no:
>                   CFLAGS=-g -O2 -I/hpc/home/finneya/programs/include
>                   LDFLAGS= -Wl,-rpath,/hpc/home/finneya/programs/lib
> -L/hpc/home/finneya/programs/lib
>                   LIBS= -lexpat -lsbml
> configure:4228: error: Can not link to SBML Library:
> 		  Please, make sure to use libSBML version >= 2.3.2
>
> ------------------
>
> It looks as if the loader (ld) isn't performing as expected :-(
>
> what's the -rpath supposed to do?
>
> yours Andrew
>
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 08 June 2006 14:13
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: Re: building SBML ODE Solver for AIX - can I use
>> expat?[Scanned]
>>
>> Hi Andrew
>>
>> Unfortunately we completely forgot about libSBML with expat.
>>
>> There is a bug report in sourceforge with short instructions.
>> http://sourceforge.net/tracker/index.php?func=detail&aid=14204
>> 89&group_id=139893&atid=744811
>>
>>
>> Copied from there, with slight corrections:
>>
>> This bug can temporarily be solved simply by replacing all
>> occurences of
>>
>> `-lxerces-c'
>>
>> in the files:
>>
>> configure
>> src/Makefile.am
>> src/Makefile.in
>> examples/Makefile.am
>> examples/Makefile.in
>> odeSolver/Makefile.am
>> odeSolver/Makefile.in
>>
>> with `-lexpat'
>>
>> e.g. by usind sed:
>>
>> sed 's/xerces-c/expat/g' configure >configure.new mv
>> configure.new configure
>>
>> for all above files.
>>
>>
>> I tried it once and it worked! Please let me know if you suceed!
>>
>> Rainer
>>
>>
>>
>> On Thu, 8 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> I'm trying to build SOS on AIX
>>>
>>> for some reason I'm having problems linking with xerces for that
>>> platform
>>>
>>> Is there a way to configure SOS to use expat?
>>>
>>> Andrew
>>>
>>
>