Re: gcc

[Francesco Pietra <frapietra@alice.it>]

On Thursday 08 June 2006 11:35, Adam Stiles wrote:
> On Wednesday 07 June 2006 20:06, Francesco Pietra wrote:
> > Yes, it was compiled OK. However, because make was from root, the
> > property of all compiled *.o files is root root. This makes some problems
> > in the use of the program, such as in deleting files.


> > Issuing
> >
> > ln -s /usr/bin/gcc-41 /usr/local/bin/gcc
> >
> > either as $ or #, followed by
> >
> > $ make
> >
> > reports
> > gcc -g -02 -c -o active.o active.c
> > cc1: error: active.c: Permission denied
> > make: *** [active.o] Error 1
> >
> > Perhaps, unless link/make can be arranged differently, the easiest would
> > be to change the property of all *.o files. Don'y remember how this could
> > be done with a single command.
>
> When you do
> # make install
> all the important files are copied somewhere sensible, usually
> /usr/local/bin which is in the standard path and out of reach of the
> package management system.  You have to be root to do this, because
> ordinary users really should not be writing to such places.
>
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.
> >
> 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)


> then that indicates an error  {as opposed 
> to a warning; errors are serious enough actually to stop the compilation}
> somewhere.  So you probably want to capture the full output to analyse at
> your leisure.  Type
> $ script [filename]
> to begin capturing the terminal output into a file  {if you don't give a
> filename the default will be 'typescript'};  then
> $ make
> to start the make process.  Press ctrl+D at the end, to stop writing to the
> script file and save it.
>
> Now you can look through the file with an editor and see where the error
> occurred.
>
> > Incidentally, in previous compilation the proprty of *.c files was
> > francesco francesco. Now it is 500 500; I imagine that 500 stands for
> > francesco. True? You know, when such affaris are carried out
> > sporadically, memory about tends to vanish to make room to other storage.
>
> Unix stores the users and groups associated with files numerically, and
> looks them up for display.  It's conventional that the low numbers are used
> for system users and "artificial" users, and higher numbers are the "real"
> users. On Red Hat systems and derivatives, non-system users start at 500;
> on Debian systems, non-system users start at 1000.
>
> What probably happened is that someone generated the tarball as the first
> non-system user on a Red Hat-ish system, who would have been numbered 500.
> One of the times that you extracted it, you took over ownership of the
> files; the other time, you preserved the original file ownerships  {perhaps
> you extracted it as root or something}.  Your Debian system doesn't have a
> user #500, so it can't give you a username.

I believe you have grasped the point 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?
>
> Not that it matters much because only root can do `make install`, and root
> can always read files belonging to anyone regardless of permission modes.

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?

Thanks a lot

francesco pietra


>
> --
> AJS