[mesa-users] Using MESA modules in external program

[Francis Timmes]

hi everyone,

this issue has been resolved, mainly due to aaron's keen eye.

if mesa puts its libraries in a certain order, you should too.
ordering of the libraries matter because linkers do not make 
multiple passes through the list of libraries to resolve references. 
if a symbol is referenced and it hasn't seen the library that 
contains the reference, then an error is emitted.

in this particular case, -lnet was moved from first in the list
to third in the list. hence the linker error.

fxt





On Jun 15, 2012, at 1:53 PM, Ryan J Orvedahl wrote:

> Hi Aaron,
> 
> That is what I thought too, but those files are in the appropriate directories and are up to date.
> 
> -Ryan
> 
> ----- Original Message -----
> From: Aaron Dotter <aaron.dotter at gmail.com>
> Date: Friday, June 15, 2012 4:44 pm
> Subject: Re: [mesa-users] Using MESA modules in external program
> To: Ryan J Orvedahl <rorvedahl at ic.sunysb.edu>
> Cc: Bill Paxton <paxton at kitp.ucsb.edu>, mesa-users at lists.sourceforge.net
> 
> > Hi Ryan,
> 
> > Do you have libeos.a in mesa/lib and eos_def.mod and eos_lib.mod in mesa/include?
> > 
> > It seems to be an issue related to not knowing where the compiled eos files are.
> > 
> > Aaron
> > 
> > 
> > 
> > On Fri, Jun 15, 2012 at 3:20 PM, Ryan J Orvedahl <rorvedahl at ic.sunysb.edu> wrote:
> > Thanks for the advice Bill.
> > 
> > I went back to the beginning and the only change I made to the one_zone_burn.f code was changing it from a program to a subroutine with no arguments. I still found the following error on compiling:
> 
> > 
> > gfortran -fno-range-check -ffree-form -c ../src/main_driver.f90
> > gfortran -fno-range-check -ffree-form -I../../mesa/include -c ../src/one_zone_burn.f
> > gfortran  -o ../xtest main_driver.o one_zone_burn.o \
> > -L../../mesa/lib -leos -lchem -lnet -lrates -lweak -lreaclib -lneu -lscreen -linterp_2d -linterp_1d -lnum -lutils -lalert -lconst -lmtx -lmesaklu /usr/lib/liblapack.a /usr/lib/libblas.a
> > ../../mesa/lib/libnet.a(net_burn_const_P.o): In function `__net_burn_const_p_MOD_burn_jacob':
> > net_burn_const_P.f:(.text+0xcca): undefined reference to `__eos_lib_MOD_radiation_pressure'
> > net_burn_const_P.f:(.text+0xeec): undefined reference to `__eos_lib_MOD_eospt_get'
> > net_burn_const_P.f:(.text+0x2567): undefined reference to `__eos_lib_MOD_eos_theta_e'
> > collect2: error: ld returned 1 exit status
> > make: *** [xtest] Error 1
> > 
> > Any help would be greatly appreciated.
> > 
> > Thanks,
> > Ryan
> 
> > 
> > ----- Original Message -----
> > From: Bill Paxton <paxton at kitp.ucsb.edu>
> > Date: Friday, June 15, 2012 12:02 pm
> > Subject: Re: [mesa-users] Using MESA modules in external program
> > To: Ryan J Orvedahl <rorvedahl at ic.sunysb.edu>
> > Cc: mesa-users at lists.sourceforge.net
> > 
> > > Hi Ryan,
> > > 
> > > > I am trying to use the MESA network in an external program.
> > > 
> > > excellent!
> > > 
> > > > To start, I wrote a simple driver routine to call the 
> > > one_zone_burn.f code contained in the mesa/net/test directory. I 
> > > slightly modified the main program in one_zone_burn.f 
> > > 
> > > Go back to the beginning and start with an unedited copy of 
> > > one_zone_burn.f to make sure that you can run with that okay 
> > > before you make any changes.
> > > Then make one small change and recheck to see if it still works.
> > > Continue until something breaks -- then perhaps we can figure 
> > > out why it broke.
> > > 
> > > At some point you'll perhaps want to call net_1_zone_burn 
> > > directly so that you can use the "dxdt_source_term" source term.
> > > Ask Mike about it.  ;-)
> > > 
> > > Cheers,
> > > Bill
> > > 
> > > 
> > 
> > Ryan J Orvedahl
> > Undergrad Student
> > Stony Brook University