In theory could do (it would have to be in the update scripts), although
I'm not that keen on this.
And note that the rm error in the initial compilation is ignorable (it's
just trying to remove the *.so files which don't yet exist).
Wayne
On Thu, 1 Nov 2007, Murali Vadivelu wrote:
> Dear Wayne,
>
> It is a fink related problem. As the .so files are linked with
> relative paths in a build directory and moved elsewhere to create
> the .deb files and installed somewhere else (the final destination)
> the .so files get copied instead of the links or something like that!
> I have fixed it in the Fink packaging now. I am not sure whether it
> would be more appropriate to be fixed in your scripts(?).
>
> Best regards,
> Murali.
>
> On 1 Nov 2007, at 11:42, Murali Vadivelu wrote:
>
> > Dear Wayne,
> >
> > That did work. However, I do not understand why it does not do the
> > same during the initial compile, instead of complaining that the
> > script does not find any .so files! See below for the output from
> > the initial compile (the reason for absence of symbolic links):
> > gcc -L/sw/lib -bundle -bundle_loader /sw/bin/python2.5 "-Wl,-
> > dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/
> > Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/
> > Versions/A/Libraries/libGL.dylib" -o Bacus.so bacus.o py_bacus.o \
> > ../../memops/global/python_util.o ../../memops/global/utility.o -lm
> > make links
> > cd ../python/memops/c; sh linkSharedObjs
> > rm: *.so: No such file or directory
> > cd ../python/ccp/c; sh linkSharedObjs
> > rm: *.so: No such file or directory
> > cd ../python/ccpnmr/c; sh linkSharedObjs
> > rm: *.so: No such file or directory
> >
> > It works fine when I do it manually after the initial compile! A bit
> > confusing... See below:
> > cd ../python/memops/c; sh linkSharedObjs
> > cd ../python/ccp/c; sh linkSharedObjs
> > cd ../python/ccpnmr/c; sh linkSharedObjs
> >
> > Many thanks.
> >
> > Best regards,
> > Murali.
> >
> > On 1 Nov 2007, at 10:51, Wayne Boucher wrote:
> >
> >> It's probably easiest to do the following:
> >>
> >> cd ccpnmr1.0/c
> >> make links
> >>
> >> That *should* remove the *.so files that are there and then create
> >> the
> >> symbolic links. But this is assuming that the linkSharedObjs
> >> scripts in
> >> ccpnmr1.0/python/memops/c, ccpnmr1.0/python/ccp/c and
> >> ccpnmr1.0/python/ccpnmr/c are the same as in the release (so do the
> >> above).
> >>
> >> Wayne
> >>
> >> On Thu, 1 Nov 2007, Murali Vadivelu wrote:
> >>
> >>> How do we fix that? Fixing the 'makefile' or so?
> >>>
> >>> Many thanks.
> >>>
> >>> On 1 Nov 2007, at 10:05, Wayne Boucher wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> We could do, only it should have been a symbolic link in the first
> >>>> place!
> >>>> (As should all the other *.so files in the Python c directories.)
> >>>> And if
> >>>> for some reason there are some systems where those symbolic links
> >>>> do
> >>>> not
> >>>> work then we ought to copy the *.so files over each time. But on
> >>>> your Mac
> >>>> I'm not sure why they were not symbolic links, Macs can cope with
> >>>> those
> >>>> perfectly well.
> >>>>
> >>>> Wayne
> >>>>
> >>>> On Thu, 1 Nov 2007, Murali Vadivelu wrote:
> >>>>
> >>>>> Dear Wayne,
> >>>>>
> >>>>> That fixed the issue. Is it possible for the update mechanism to
> >>>>> perform the task of replacing that physical file by a symbolic
> >>>>> link,
> >>>>> and thus avoiding manual intervention.
> >>>>>
> >>>>> Many thanks.
> >>>>>
> >>>>> Best regards,
> >>>>> Murali.
> >>>>>
> >>>>> On 31 Oct 2007, at 20:27, Wayne Boucher wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Someone else just had this problem and the underlying fault in
> >>>>>> that
> >>>>>> case
> >>>>>> was that the file ccpnmr1.0/python/memops/c/FitMethod.so was
> >>>>>> not a
> >>>>>> symbolic link to ccpnmr1.0/c/memops/global/FitMethod.so, but a
> >>>>>> copy of
> >>>>>> some previous version, so the latter was being updated by the
> >>>>>> update
> >>>>>> mechanism but not the former. (We have to have this symbolic
> >>>>>> link
> >>>>>> so that
> >>>>>> the Python picks up the C library.) It's possible this is what
> >>>>>> the
> >>>>>> problem below is, rather than a compilation issue.
> >>>>>>
> >>>>>> Wayne
> >>>>>>
> >>>>>> On Wed, 31 Oct 2007, Wayne Boucher wrote:
> >>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I think something must be going wrong with the update mechanism,
> >>>>>>> but I
> >>>>>>> don't know what. The function runFit was added recently, and I
> >>>>>>> just
> >>>>>>> checked and it is on the update server, so it should have been
> >>>>>>> installed
> >>>>>>> with your latest update, and it should have compiled. My guess
> >>>>>>> right now
> >>>>>>> is that it didn't compile for some reason. So first of all,
> >>>>>>> let's
> >>>>>>> check
> >>>>>>> that runFit is there:
> >>>>>>>
> >>>>>>> cd /sw/lib/python2.5/site-packages/ccpnmr/ccpnmr1.0/c/memops/
> >>>>>>> global
> >>>>>>> grep runFit py_fit.c
> >>>>>>>
> >>>>>>> And see if that gets any hits. If it's not there then somehow
> >>>>>>> py_fit.c
> >>>>>>> has not been downloaded. If it is there then my guess is that
> >>>>>>> it's
> >>>>>>> not
> >>>>>>> being compiled. To do the latter do:
> >>>>>>>
> >>>>>>> cd /sw/lib/python2.5/site-packages/ccpnmr/ccpnmr1.0/c
> >>>>>>> make
> >>>>>>>
> >>>>>>> And then try again.
> >>>>>>>
> >>>>>>> Wayne
> >>>>>>>
> >>>>>>> On Wed, 31 Oct 2007, Murali Vadivelu wrote:
> >>>>>>>
> >>>>>>>> Dear Dan,
> >>>>>>>>
> >>>>>>>> I used the patch and the Fink package built properly. I was
> >>>>>>>> able
> >>>>>>>> to
> >>>>>>>> install and run the package. However, once I updated it, in
> >>>>>>>> spite of
> >>>>>>>> the proper compilation of the updated C code, I get the
> >>>>>>>> following
> >>>>>>>> error:
> >>>>>>>> Error, the DataAnalysisBasic module will not work, something is
> >>>>>>>> wrong
> >>>>>>>> with the C code.
> >>>>>>>> Traceback (most recent call last):
> >>>>>>>> File "/sw/lib/python2.5/site-packages/ccpnmr/ccpnmr1.0/python/
> >>>>>>>> ccpnmr/analysis/AnalysisGui.py", line 72, in <module>
> >>>>>>>> from ccpnmr.analysis.AnalysisPopup import AnalysisPopup
> >>>>>>>> File "/sw/lib/python2.5/site-packages/ccpnmr/ccpnmr1.0/python/
> >>>>>>>> ccpnmr/analysis/AnalysisPopup.py", line 103, in <module>
> >>>>>>>> from ccpnmr.analysis.CalcHeteroNoePopup import
> >>>>>>>> CalcHeteroNoePopup
> >>>>>>>> File "/sw/lib/python2.5/site-packages/ccpnmr/ccpnmr1.0/python/
> >>>>>>>> ccpnmr/analysis/CalcHeteroNoePopup.py", line 69, in <module>
> >>>>>>>> from ccpnmr.analysis.DataAnalysisBasic import matchHnoePeaks
> >>>>>>>> File "/sw/lib/python2.5/site-packages/ccpnmr/ccpnmr1.0/python/
> >>>>>>>> ccpnmr/analysis/DataAnalysisBasic.py", line 63, in <module>
> >>>>>>>> from memops.c.FitMethod import runFit
> >>>>>>>> ImportError: cannot import name runFit
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>> I tried to manually recompile the C code after a 'make
> >>>>>>>> clean', and
> >>>>>>>> still get the same error.
> >>>>>>>>
> >>>>>>>> Many thanks.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> Murali.
> >>>>>>>>
> >>>>>>>> On 29 Oct 2007, at 19:37, Murali Vadivelu wrote:
> >>>>>>>>
> >>>>>>>>> There is a new patch file fixing this issue on the tracker - https://sourceforge.net/tracker/index.php?func=detail&aid=1822306&group_id=17203&atid=414256
> >>>>>>>>>
> >>>>>>>>> A description of the problem is here - http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug
> >>>>>>>>>
> >>>>>>>>> On 29 Oct 2007, at 10:43, Daniel O'Donovan wrote:
> >>>>>>>>>
> >>>>>>>>>> ** ONLY OF INTEREST TO APPLE USERS **
> >>>>>>>>>>
> >>>>>>>>>> Dear all,
> >>>>>>>>>>
> >>>>>>>>>> We've been testing the new OS X release, leopard (10.5) and
> >>>>>>>>>> it's
> >>>>>>>>>> compatibility with CCPN Analysis here in the lab. Thanks to
> >>>>>>>>>> the
> >>>>>>>>>> fink people acting sprightly almost everything seems to be
> >>>>>>>>>> running
> >>>>>>>>>> happily. Unfortunately though, there is an issue with the GL
> >>>>>>>>>> libraries which will prevent Analysis from compiling an
> >>>>>>>>>> running.
> >>>>>>>>>> We're working on a fix for this which should be out soon,
> >>>>>>>>>> but a
> >>>>>>>>>> word of warning to any adventurous users - tread carefully!
> >>>>>>>>>> (It is
> >>>>>>>>>> possible to run Analysis without these libraries)
> >>>>>>>>>>
> >>>>>>>>>> Of course, if anyone has already tried compiling with Leopard
> >>>>>>>>>> and
> >>>>>>>>>> had success please let us know! Many thanks,
> >>>>>>>>>>
> >>>>>>>>>> Dan
> >>>>>>>>>>
> >>>>>>>>>> Daniel O'Donovan CCPN PhD Student
> >>>>>>>>>> Dept. of Biochemistry
> >>>>>>>>>> University of Cambridge
> >>>>>>>>>> +44 1223 766 018
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
>
|