Ah, FAT = Windows, the operating system of the devil.
If anyone really wants to use an operating system without symbolic links
then we would have to change the linkSharedObjs to copy instead of link
(and the name would be wrong, but that's not so important). So in
ccpnmr1.0/python/memops/c, the linkSharedObjs file now says:
#!/bin/sh
\rm *.so
ln -s ../../../c/memops/global/BlockFile.so BlockFile.so
ln -s ../../../c/memops/global/FitMethod.so FitMethod.so
ln -s ../../../c/memops/global/GlHandler.so GlHandler.so
ln -s ../../../c/memops/global/MemCache.so MemCache.so
ln -s ../../../c/memops/global/PdfHandler.so PdfHandler.so
ln -s ../../../c/memops/global/PsHandler.so PsHandler.so
ln -s ../../../c/memops/global/StoreFile.so StoreFile.so
ln -s ../../../c/memops/global/StoreHandler.so StoreHandler.so
ln -s ../../../c/memops/global/TkHandler.so TkHandler.so
and for FAT it ought to say:
#!/bin/sh
\rm *.so
cp ../../../c/memops/global/BlockFile.so BlockFile.so
cp ../../../c/memops/global/FitMethod.so FitMethod.so
cp ../../../c/memops/global/GlHandler.so GlHandler.so
cp ../../../c/memops/global/MemCache.so MemCache.so
cp ../../../c/memops/global/PdfHandler.so PdfHandler.so
cp ../../../c/memops/global/PsHandler.so PsHandler.so
cp ../../../c/memops/global/StoreFile.so StoreFile.so
cp ../../../c/memops/global/StoreHandler.so StoreHandler.so
cp ../../../c/memops/global/TkHandler.so TkHandler.so
and similarly in the directories ccpnmr1.0/python/ccp/c and
ccpnmr1.0/python/ccpnmr/c.
Wayne
On Sat, 8 Dec 2007, Andy Herbert wrote:
>
>
> Hi,
>
>
>
> I may be wrong, but I was under the impression that you can't make sym.
> links on a FAT (or FAT32) filesystem.
>
>
>
> Cheers
>
>
>
> Andy
>
>
>
> Dr Andy Herbert
>
> Department of Chemistry
>
> University of Edinburgh
>
> West Mains Road
>
> Edinburgh
>
> UK
>
> EH9 3JJ
>
> Tel: +44 (0)131 650 4704 or 650 7372
>
> Email: [log in to unmask]
>
>
>
> -----Original Message-----
> From: CcpNmr software mailing list [mailto:[log in to unmask]] On Behalf
> Of Vitaliy Gorbatyuk
> Sent: 08 December 2007 03:43
> To: [log in to unmask]
> Subject: Re: memcache crash after upgrade a story
>
>
>
> Yes, I did do 'source linkShareObjs' as this was suggested in February
> e-mails. It produced the same errors.
>
> Now, ls command lists nine *.so files.
>
> Well, I have done a test. I have successfully installed Analysis in my home
> directory (which is on the NFS drive) as opposite to the unsuccessful
> installation in the fat32 partition of the local drive
> (/mnt/fat32/LinuxApps...). So I wonder if it has something to do with
> SElinux configurations.
>
> Thank you,
> Vitaliy
>
> > Date: Sat, 8 Dec 2007 01:41:35 +0000
> > From: [log in to unmask]
> > Subject: Re: Fwd: memcache crash after upgrade a story
> > To: [log in to unmask]
> >
> > Hmmm, that looks like a new error. So it seems the OS is not letting you
> > create the symbolic links, and that seems odd. But I wonder if this is an
> > NFS mount problem (it was confused about where it was).
> >
> > If you go into
> >
> > /mnt/fat32/LinuxApps/ccpnmr/ccpnmr1.0/python/memops/c
> >
> > try if you can do
> >
> > source linkSharedObjs
> >
> > and see if you still get those linking errors. If you do get those
> > errors, what happens if you do, from inside this directory,
> >
> > ls ../../../c/memops/global/*.so
> >
> > Is anything listed or does it claim the directory doesn't exist?
> >
> > If the "source" command does work (for some reason) then try the same in
> >
> > /mnt/fat32/LinuxApps/ccpnmr/ccpnmr1.0/python/ccp/c
> >
> > and
> >
> > /mnt/fat32/LinuxApps/ccpnmr/ccpnmr1.0/python/ccpnmr/c
> >
> > Wayne
> >
> > On Fri, 7 Dec 2007, Vitaliy wrote:
> >
> > > Hello:
> > >
> > > I've got the similar errors while installing Analysis1.0.15 from scratch
> > > under a freshly installed CentOS 5.0. I have attached the log file with
> the
> > > installation messages. Also, there is no the linkSharedObjs file inside
> > > memops, ccp and ccpnmr as it is mentioned bellow.
> > >
> > > I will appreciate your help.
> > >
> > > Thank you,
> > > Vitaliy
> > >
>
>
|