On 11/9/06, Douglas Kojetin <douglas.kojetin@xxxxxxxxx> wrote:
I worked out some settings so that I no longer receive the error.
The steps I used are outlined below:
(1) grabbed a clean 1.3 source via svn
(2) changed the first in the 'relax' file to read:
#! /usr/bin/env python
which by default will use /sw/bin/python instead of /usr/bin/python
on my system
(3) edited the gnulink.py in the scons distribution (line 49):
elif env['PLATFORM'] == 'darwin':
#env['SHLINKFLAGS'] = SCons.Util.CLVar('$LINKFLAGS -
dynamiclib')
env['SHLINKFLAGS'] = SCons.Util.CLVar('$LINKFLAGS')
I should be able to put this into the SCons configuration script.
Actually, something which would be useful would be to test what
happens if you compile it on the command line replacing the '-dynamic'
flag with the '-dynamiclib' flag. The error was when both was used,
but if it works with just '-dynamiclib', then the fix is simple.
(4) invoked 'scons' in the main directory
(5) moved 'maths_fns/relax_fit.dylib' to 'maths_fns/relax_fit.so' to
match the file name that is present after linux complication
I wonder if this is functional though? Unfortunately no one has coded
tests for relaxation curve fitting into the test suite yet. Do you
have data you can test it on?
Would it be possible to change the
#! /usr/bin/env python
line in relax to
#! /usr/bin/env python
or would that break functionality?
That's a great idea. I was always wondering how a python installation
not located in '/usr/bin' should be handled. This shouldn't cause any
problems. The question is though, is the program 'env' always in
'/usr/bin' or is there something else which can be put there which is
even more cross-platform compatible?
Edward