Re: gcc

[Francesco Pietra <frapietra@alice.it>]

On Thursday 08 June 2006 18:14, A J Stiles wrote:
> On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> > Finally, I issued #make (from root) and then changed the ownership of all
> > *.c, *.o, *.h, and *.prm files, including the directory containing them.
> > It works perfectly at truly 64bit (of course it has no graphics, to this
> > end, but on the 32bit pc I have a sister program to examine graphically
> > the output). Impressive speed. The most tricky part is to create the
> > input on the 32bit pc and transfer to the 64bit workstation through a usb
> > card reader, complex because of the strict adherence of debian to
> > ownerships and permissions.
>
> Is there a good reason why you can't set up an NFS share between the two
> machines?

Really not.  I am just at the beginning, with recoursing problems. NFS will be 
the solution. And may be even vetter to create a 32bit chroot to run there my 
pre-program. It may be useful in case of pc32 down. I never created a chroot 
and take into account that I am a chemist (one of the very few scientists in 
my country who does not know about Microsoft), I have to do chemistry. Time 
is short.

I am experiencing unusual difficulties with these particular file transfers 
from the 64bit side. Root is not allowed to transfer with preservation of 
properties of output files (may be I am using wrong commands, however) and 
files on the card reader refuse to be changed of ownership (here I am sure to 
use the right commands). Moreover, umount does not work and occupancy pid is 
both to user (why, he was  only involved in the property of output files) and 
root, and a simple kill pid does not work, I had to make recourse to the 
dangerous kill -kill pid (always, not only once). In contrast, everything 
flows smoothly with the same card and same file on the 32bit pc (either from 
terminal window or kde). On the 64bit machine I had even a suggestion to 
report a bug about malfunction of -p --preserve. Unfortunately I did nothing 
and I did not take notice.

> > > If `make install` is not working,
> >
> > There is no makeinstall in the Makefile. Things are arranged that make
> > creates the executable that can be placed everywhere (with its needed
> > companions)
>
> Ah.  Well, this is the sort of thing I should have expected from a
> programmer who is still using gets() .....  ;-)

I would be more cautious about that.  That person was able to transfer 
computational programs from mainframe to the first IBM PC (and I was using 
them from the beginning), and he wrote ones that still have no equivalent on 
earth. But I understand, he do not know him.
>
> > I believe you have grasped the point [about user #500] perfectly. Who
> > wrote
>
> the program is a
>
> > RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> > that, on my solicitation, he has installed debian too, but he was
> > probably pressed by the time. I was looking at 500: is that the decimal
> > corresponding to octal 764?
>
> 7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
>
> > At any event, I am happy to have the first important piece for my
> > calculations at 64bit with multiprocessor. Now I have to check if the
> > program is bug-free. A molecule of my repertoire will test that fully.
> >
> > Could you please help me further? I posed to the mpqc list the question
> > (unanswered) if it is safe to install on amd64 debian etch mpqc (the
> > second part of my calculations) made available for debian sid at
> >
> > http://packages.debian.org/unstable/science/mpqc
> >
> > What do you think? If safe, should I add a repository to my sources.list
> > for etch or there is another less risky way?
>
> What I've mostly done in the past, when wanting packages not available in
> the distribution I am using  {e.g.  my 32-bit Etch at home, when some KDE
> packages were unavailable},  has been to download the .dsc, .diff.gz and
> .orig.tar.gz files by hand, build the package:
> # dpkg-source -x foo.dsc
> # cd foo
> # dpkg-buildpackage
> and install the resulting .deb using
> # dpkg -i foo.deb
>
> Unstable  {sid}  packages generally will build fine on testing  {etch at
> time of writing}  except when a huge transition is taking place  {eg. KDE2
> to KDE3, XFree86 to Xorg} and a dependency hasn't made it through the
> system yet.  Depending upon how actively mpqc is being developed, you may
> even find that the Etch and Sid versions are the same.
>
> Good luck with it!
>
Thanks a lot

> --
> AJS
> delta echo bravo six four at earthshod dot co dot uk