Home > Archive > Fortran > October 2004 > Installing g95 on OS X
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Installing g95 on OS X
|
|
|
| Hi, I'm attempting to install g95 on OS X (Jaguar), but being a
complete Darwin newbie, I really don't understand the instructions
that go with it. What does it mean by saying "G95 and friends expect
to live under /tmp/g95"? Does that mean I have to move files around
into some new directory that I've created? Can I do this in the GUI?
I'm actually quite scared of poking around in Darwin because I was
once told that I could completely wreck it if I didn't know what I was
doing...
I'd be really grateful if anyone can help me out here. Thanks!
Nat
| |
| Richard E Maine 2004-10-18, 8:56 pm |
| sebire@hotmail.com (Nat) writes:
I don't know anything about the particular g95-related question you asked,
but...
> I'm actually quite scared of poking around in Darwin because I was
> once told that I could completely wreck it if I didn't know what I was
> doing...
Somebody appears to have oversensitized you to this. While it is true,
the same thing is true of pretty much every operating system out there.
Proofs by demonstration exist. I have first-hand evidence of this
on both Windows-based and Unix systems. :-( It happens that I haven't
completely trashed any of my Macs, but I certainly know ways that it
could happen. Probably the only thing that has "saved" me is that I've
only been using them for about a year and a half I think it has been.
I have trashed some apps, but not the whole system...yet.
I've trashed my Windows boxes several times. Heck, it has been argued
(with some merit) that one should rebuild a Windows box from scratch
about every other year anyway in order to remove "cruft" that will
have accumulated.
Unix boxes tend to be harder in that it tends to take sy min
permission for most ways of trashing them. But I symin several. :-(
The usual (and very good) advice is to keep separate accounts for
daily use and for symin stuff.
OS X is a Unix box, well at least for current purposes, and the same
caveat applies. The only way in which I might say it was particularly
easy to wreck it is that most people will set themselves up so that
the account they use for daily use has symin privileges. Doesn't
have to be that way, but that's how most systems are (because it's
what happens by default if you don't set it up otherwise). But your
typical Windows box has the same kind of setup. Most other Unix boxes
aren't set up like this... but the added danger is when you *AREN'T*
intentionally using the system privileges. As soon as you are intentionally
doing symin work, you have the same kinds of potential problems.
If you are really worried, it would be a lot more constructive to
make 2 accounts - one for daily use and one for symin - than to
be afraid of ever touching the machine. I did that for a while...
but got lazy.
In any case, have backups. No matter what. No matter what OS or
how you use it. I've sympathized with no end of people who lost
huge amounts of work because they thought they didn't need backups
(or most often, just didn't think about it at all). Usually sympathy
is about all I can offer. Yep, some of them were on Macs.
It is probably a corollary of Murphy's law that the only people who
don't need backups are the people who do them... but it is worth doing
the backups just to make sure that you won't need them. :-)
If you are going to be quite a scared of touching the system as you
describe, then I shouldn't tell you that I've trashed a Windows/Linux
(dual-boot) system by just touching the keyboard without even
depressing a key. :-( Darned static electricity. Fried the keyboard
controller, which meant a new motherboard.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Dave Seaman 2004-10-18, 8:56 pm |
| On 18 Oct 2004 15:05:34 -0700, Nat wrote:
> Hi, I'm attempting to install g95 on OS X (Jaguar), but being a
> complete Darwin newbie, I really don't understand the instructions
> that go with it. What does it mean by saying "G95 and friends expect
> to live under /tmp/g95"? Does that mean I have to move files around
> into some new directory that I've created? Can I do this in the GUI?
> I'm actually quite scared of poking around in Darwin because I was
> once told that I could completely wreck it if I didn't know what I was
> doing...
> I'd be really grateful if anyone can help me out here. Thanks!
Do you really need g95 rather than gfortran? Both are f95 compilers, but
gfortran is easier to install on the Mac. If you have fink installed, all you
need to do is type
sudo fink install gfortran
and let it build. See <http://fink.sourceforge.net> if you need to install
fink. This assumes that you have Apple's Developer Tools (known as Xcode in
Panther) already installed. You may be able to install a prebuilt binary using
the apt-get command (that's not necessarily available for all fink products,
and I haven't tried it).
If you really need g95, then you need to know that there are some standard
locations that are recognized by all versions of Unix and Linux (including
Darwin):
/tmp Temporaries. It's ok to place files here, but you
should understand that they may be deleted the next
time you reboot. Why they would insist on having a
symbolic link in /tmp is beyond me.
/usr/local Traditionally a place to install things that are not
provided as part of the operating system. For example,
you could create a directory /usr/local/g95-install
by untaring the distribution file.
To install in /usr/local you will need to use the 'sudo' command, which gives
you root access for a single command. You will probably also want to create a
/usr/local/bin directory if you don't have one yet, and place a symbolic link
g95 in that directory as described in the INSTALL file. You also need to make
sure /usr/local/bin is in your PATH, where PATH is a shell variable that
controls where the shell looks for executable programs that you call from the
command line.
If the preceding paragraph looks like gibberish to you, you may want to
consider installing fink and using gfortran instead, since more of the process
is automated when you go that route.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Jason Nielsen 2004-10-18, 8:56 pm |
| >
>
> On 18 Oct 2004 15:05:34 -0700, Nat wrote:
>
To get the g95 binary working do the following:
1) Download g95-powerpc-osx.tgz and put it in /tmp
2) type: su
in a shell, it will ask you for the admin password.. type it in.
3) type: cd /tmp
4) type: tar -zxf g95-powerpc-osx.tgz
5) type: ln -s /tmp/g95-install/bin/powerpc-apple-darwin6.8-g95
/usr/local/bin/g95
all this in one line. It makes a link from /usr/local/bin/g95 to the
compiler binary in /tmp/ so you can just type g95 to compile something.
5) type: exit
6) type: g95 -c myprog.f90
where myprog.f90 is some simple program (make sure you are in the
directory where the program lives). If it produces an a.out file you are
golden. If it doesn't let me know and it means that /usr/local/bin isn't
in your path... if that is the case which I doubt e-mail again and I'll
give you directions (/usr/local/bin is a pretty standard dir for a user
account on *NIX machines and should be in your path by default).
The reason why you should untar the file in /tmp is that the compiler
thinks all its important libraries are there so it can link them at
compile time. If you don't put it in /tmp you will have to tell the
compiler where they are using environmental variables.. so my suggestion
is to simply use /tmp... when the compiler is complete I'm sure a better
directory will be chosen.
Cheers,
Jason
| |
| Dave Seaman 2004-10-19, 4:01 am |
| On Tue, 19 Oct 2004 00:10:25 GMT, Jason Nielsen wrote:
[color=darkred]
> To get the g95 binary working do the following:
> 1) Download g95-powerpc-osx.tgz and put it in /tmp
> 2) type: su
> in a shell, it will ask you for the admin password.. type it in.
That won't work unless you have gone to the trouble of enabling root
logins, a procedure that is definitely not recommended on the Mac. For
one thing, it's rather difficult to undo, once done.
Instead of 'su' you should use a command like
sudo bash
where you may substitute your favorite shell for 'bash', if desired. You
will be asked for your account password. You must be running under an
account that has admin privileges for this to work.
From here on until you type 'exit' you will see '#' as your prompt, which
is a reminder that you are running with root privileges and therefore you
should carefully verify each command you type before you press <return>.
> 3) type: cd /tmp
> 4) type: tar -zxf g95-powerpc-osx.tgz
This is not quite what the INSTALL file recommends. I suggest using the
following instead:
3) cd /usr/local
4) tar -zxf /tmp/g95-powerpc-osx.tgz
and then type the following (this is between steps 4 and 5):
ln -s /usr/local/g95-install /tmp/g95
> 5) type: ln -s /tmp/g95-install/bin/powerpc-apple-darwin6.8-g95 /usr/local/bin/g95
> all this in one line. It makes a link from /usr/local/bin/g95 to the
> compiler binary in /tmp/ so you can just type g95 to compile something.
First you should make sure the directory /usr/local/bin exists. It
doesn't on a stock Macintosh:
mkdir -p /usr/local/bin
Next, you should modify the command 5) to specify a path beginning with
/usr/local in place of /tmp:
5) ln -s /usr/local/g95-install/bin/powerpc-apple-darwin6.8-g95 /usr/local/bin/g95
That's supposed to be all on one line.
> 5) type: exit
After this you are no longer running with root privileges.
> 6) type: g95 -c myprog.f90
Assuming you have a fortran program in the file myprog.f90 in your
current directory. If you see a response like "g95: command not found"
at this point, it means you need to add /usr/local/bin to your PATH. The
exact method for doing that depends on your shell. If you are using
bash, you can add the line
export PATH=/usr/local/bin:$PATH
to the file .bash_profile in your home directory (or create a new file by
that name if it doesn't exist). From that point on, each new Terminal
window that you open will have your PATH initialized so that g95 can be
found.
> where myprog.f90 is some simple program (make sure you are in the
> directory where the program lives). If it produces an a.out file you are
> golden. If it doesn't let me know and it means that /usr/local/bin isn't
> in your path... if that is the case which I doubt e-mail again and I'll
> give you directions (/usr/local/bin is a pretty standard dir for a user
> account on *NIX machines and should be in your path by default).
> The reason why you should untar the file in /tmp is that the compiler
> thinks all its important libraries are there so it can link them at
> compile time. If you don't put it in /tmp you will have to tell the
> compiler where they are using environmental variables.. so my suggestion
> is to simply use /tmp... when the compiler is complete I'm sure a better
> directory will be chosen.
I don't see how you can count on /tmp/g95-install staying put after the
next reboot. I installed in /usr/local/g95-install and then placed a
symbolic link in /tmp, as described in the INSTALL file. It works fine.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Jason Nielsen 2004-10-19, 4:01 am |
| >>
>
> Thanks for clearing up my non-Macness... I was simply trying to help out the
> OP with some how-to type instructions... obviously not quite correct.
>
> As for /tmp/g95-install staying put I don't see why you would assume that it
> wouldn't ... there is an extremely small possibility that it might get
> over-written (i.e. if some program actually writes to /tmp/g95-install) but
> not deleted. Maybe this is the case for Mac.. does it actually run a cron
> job to clear out /tmp from time to time? Using a sym link of course is the
> better option as you say.. I'm just lazy that way.. if it ain't broke why fix
> it ;-)!
>
I know it is bad form to respond to your own post... but hey I have bad
form ;-)! What I said about the sym link is bumkiss. If something gets
written to /tmp/g95-install then it will write it to where you happen to
have it sym liked too.. just as if the dir lived in /tmp. What it does do
is save you if your computer whips out /tmp then all you have lost is the
sym link and not the directory.. which is likely why they suggest this and
perhaps kills my /tmp theory ;-). If this does actually happen though
your g95 would stop working and you would have to re-enable the sym link.
Well ... enough of me for today... must be the beer .. if you were here
I'd offer you one... the garden variety Canadian beer isn't overly tasty
but it does pack a punch ;-)!
Cheers,
Jason
| |
| Dave Seaman 2004-10-19, 4:01 am |
| On Tue, 19 Oct 2004 03:24:12 GMT, Jason Nielsen wrote:
> Thanks for clearing up my non-Macness... I was simply trying to help out
> the OP with some how-to type instructions... obviously not quite correct.
Understood.
> As for /tmp/g95-install staying put I don't see why you would assume that
> it wouldn't ... there is an extremely small possibility that it might get
> over-written (i.e. if some program actually writes to /tmp/g95-install)
> but not deleted. Maybe this is the case for Mac.. does it actually run a
> cron job to clear out /tmp from time to time? Using a sym link of course
> is the better option as you say.. I'm just lazy that way.. if it ain't
> broke why fix it ;-)!
Unfortunately, it *is* broke. Badly.
Files in /tmp are automatically cleaned out at boot time, as is standard
practice on Unix boxes. The reason it's called "tmp" is to serve as a
warning that everything you put there is temporary. The code for the
cleanup on the Mac is in the file /etc/rc.cleanup. Keep in mind that
/tmp on a Macintosh is a symbolic link to /private/tmp:
# Clean out /private/tmp.
if [ -d /private/tmp ]; then
# blow away any _tmp_ in case it exists as well
if [ -f /private/_tmp_ ]; then
chflags -R nouchg /private/_tmp_ && rm -rf /private/_tmp_
fi
echo -n " /private/tmp"
mv /private/tmp /private/_tmp_
(chflags -R nouchg /private/_tmp_ && rm -rf /private/_tmp_) &
fi
mkdir -m 1777 /private/tmp
I just tested it by creating a /tmp/g95 symbolic link on my Powerbook
(owned by root). I then rebooted and found the link was gone.
Making g95 depend on a symbolic link in /tmp is a horrible design
decision. Even though it could be doctored up to make it work (perhaps
by inserting code in /etc/rc.local), such a practice simply cuts against
the grain. Nobody installs software in /tmp for permanent use, for
gawd's sake.
Aside from that, your method definitely does not work, because you didn't
do what it says in step 2) of the INSTALL file, which is:
2) Create a symbolic link from /tmp/g95 to the g95-install directory.
G95 and friends expect to live under /tmp/g95:
Notice it doesn't say where the g95-install directory actually is; that's
up to you. All that's required is that you install a symbolic link in
/tmp/g95 to make it *appear* that the software is there. That is, you
should type something like
ln -s /whatever/path/you/choose/to/g95-install /tmp/g95
which you didn't do. Note that this is not the same symbolic link as the
one mentioned in step 3) of the INSTALL file (which you took care of in
your step 5).
The advantage of choosing /usr/local/g95-install rather than
/tmp/g95-install is that you don't have to recreate the entire directory
each time you reboot. You only need to re-install the link, which is
somewhat easier, but not as easy as doing it right in the first place.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Madhusudan Singh 2004-10-19, 4:01 am |
| Dave Seaman wrote:
> On 18 Oct 2004 15:05:34 -0700, Nat wrote:
>
>
> Do you really need g95 rather than gfortran? Both are f95 compilers, but
> gfortran is easier to install on the Mac. If you have fink installed, all
> you need to do is type
g95 is far more complete than gfortran.
| |
| Helge Avlesen 2004-10-19, 4:01 am |
| sebire@hotmail.com (Nat) writes:
| Hi, I'm attempting to install g95 on OS X (Jaguar), but being a
| complete Darwin newbie, I really don't understand the instructions
| that go with it. What does it mean by saying "G95 and friends expect
| to live under /tmp/g95"? Does that mean I have to move files around
| into some new directory that I've created? Can I do this in the GUI?
| I'm actually quite scared of poking around in Darwin because I was
| once told that I could completely wreck it if I didn't know what I was
| doing...
no it means you can have the actual g95 files anywhere, but that you
need to make a symbolic link from /tmp/g95 to that directory.
since everyone are allowed to write to /tmp, you can install g95
without needing to be the system administrator, root or whatever it is
called in the OS X world.
so the quickest way to install g95 are
1) open the terminal application
2) download g95 and install in current directory with this command
line:
wget -O - http://www.g95.org/g95-powerpc-osx.tgz | tar xvfz -
3) ln -s $PWD/g95-install /tmp/g95
finally to make an alias for the compiler in the current directory
4) ln -s /tmp/g95/bin/i686-pc-linux-gnu-g95 ./g95
you may now invoke g95 with
./g95
Helge
| |
| Helge Avlesen 2004-10-19, 4:01 am |
| Dave Seaman <dseaman@no.such.host> writes:
| Files in /tmp are automatically cleaned out at boot time, as is standard
| practice on Unix boxes. The reason it's called "tmp" is to serve as
| a
so what. most programs need some initialization of the environment, in
g95's case the only thing you need to make it work all the time is to
set a symlink to the install directory. this can trivially be done in
..bashrc or similar init script. the point is that you can install g95
without having to fiddle around as the sym...
Helge
| |
| Jason Nielsen 2004-10-19, 4:01 am |
|
> Files in /tmp are automatically cleaned out at boot time, as is standard
> practice on Unix boxes. The reason it's called "tmp" is to serve as a
> warning that everything you put there is temporary. The code for the
> cleanup on the Mac is in the file /etc/rc.cleanup. Keep in mind that
> /tmp on a Macintosh is a symbolic link to /private/tmp:
>
This certainly isn't true at least not on my FreeBSD box (adding
clear_tmp_enable="YES" to rc.conf will do the trick) or my Linux boxes. I
use /tmp all the time to dump cruft that I'm not sure I want to delete.
That Mac uses /etc/rc.cleanup to remove stuff in /tmp does not make
deleting the contents of /tmp standard. Granted if you are using a long
running server it might be good practice to run a cron job once a month to
clean out /tmp but that is a different matter! So the instructions I gave
in fact work just fine on the *NIX boxes I have... none of which is a
Mac.. and for that I agree my instructions were a bit off ... just trying
to help.
Cheers,
Jason
| |
| Dave Seaman 2004-10-19, 4:01 am |
| On Tue, 19 Oct 2004 06:40:50 GMT, Jason Nielsen wrote:
[color=darkred]
> This certainly isn't true at least not on my FreeBSD box (adding
> clear_tmp_enable="YES" to rc.conf will do the trick) or my Linux boxes. I
> use /tmp all the time to dump cruft that I'm not sure I want to delete.
> That Mac uses /etc/rc.cleanup to remove stuff in /tmp does not make
> deleting the contents of /tmp standard. Granted if you are using a long
> running server it might be good practice to run a cron job once a month to
> clean out /tmp but that is a different matter! So the instructions I gave
> in fact work just fine on the *NIX boxes I have... none of which is a
> Mac.. and for that I agree my instructions were a bit off ... just trying
> to help.
Most of the Unix/Linux boxes that I deal with are running the Portable
Batch Server (PBS) for scheduling long jobs, and on those machines it is
standard practice to clean out /tmp each time a job finishes -- not just
at boot time. Regardless of the exact policy in effect, it is sheer
madness to consider the contents of /tmp to be anything other than
temporary.
If you want to keep it, put it in /usr/local, unless your local policy
designates a different directory for that purpose. A permanent
directory, that is.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Paul Van Delst 2004-10-19, 3:58 pm |
| Dave Seaman wrote:
> On Tue, 19 Oct 2004 03:24:12 GMT, Jason Nielsen wrote:
>
>
>
>
>
> Understood.
>
>
>
>
> Unfortunately, it *is* broke. Badly.
>
> Files in /tmp are automatically cleaned out at boot time, as is standard
> practice on Unix boxes.
Ahh. That explains why g95 no longer works on my box. That's too bad. I'm not going to
reinstall g95 (or recreate a symlink) every time I reboot - that's ridiculous. Reboots
here happen quite regularly due to the constant patches/updates to OS and app software.
> Making g95 depend on a symbolic link in /tmp is a horrible design
> decision. Even though it could be doctored up to make it work (perhaps
> by inserting code in /etc/rc.local), such a practice simply cuts against
> the grain. Nobody installs software in /tmp for permanent use, for
> gawd's sake.
So it wasn't just me who thought that was weird. Phew.
cheers,
paulv
| |
| Dick Hendrickson 2004-10-19, 3:58 pm |
| Does anybody besides me see a problem here? *nix systems
are apparently unusable by people with normal computer
skills! This stuff is complicated beyond words. Jason
gives a seven step program (with an error that's even
obvious to me!) and Dave write a couple hundred lines
of explanation/correction/improvements. And I see there
are 3 or 4 follow-ups to his post.
Maybe I just need another cup of coffee, but after 20+
years of unix development(?), why is it so hard to
install a $%^&ing compiler?
Dick (needs a Gin & Tonic) Hendrickson
Dave Seaman wrote:
> On Tue, 19 Oct 2004 00:10:25 GMT, Jason Nielsen wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> That won't work unless you have gone to the trouble of enabling root
> logins, a procedure that is definitely not recommended on the Mac. For
> one thing, it's rather difficult to undo, once done.
>
> Instead of 'su' you should use a command like
>
> sudo bash
>
> where you may substitute your favorite shell for 'bash', if desired. You
> will be asked for your account password. You must be running under an
> account that has admin privileges for this to work.
>
> From here on until you type 'exit' you will see '#' as your prompt, which
> is a reminder that you are running with root privileges and therefore you
> should carefully verify each command you type before you press <return>.
>
>
>
>
>
>
> This is not quite what the INSTALL file recommends. I suggest using the
> following instead:
>
> 3) cd /usr/local
> 4) tar -zxf /tmp/g95-powerpc-osx.tgz
>
> and then type the following (this is between steps 4 and 5):
>
> ln -s /usr/local/g95-install /tmp/g95
>
>
>
>
>
>
> First you should make sure the directory /usr/local/bin exists. It
> doesn't on a stock Macintosh:
>
> mkdir -p /usr/local/bin
>
> Next, you should modify the command 5) to specify a path beginning with
> /usr/local in place of /tmp:
>
> 5) ln -s /usr/local/g95-install/bin/powerpc-apple-darwin6.8-g95 /usr/local/bin/g95
>
> That's supposed to be all on one line.
>
>
>
>
> After this you are no longer running with root privileges.
>
>
>
>
>
> Assuming you have a fortran program in the file myprog.f90 in your
> current directory. If you see a response like "g95: command not found"
> at this point, it means you need to add /usr/local/bin to your PATH. The
> exact method for doing that depends on your shell. If you are using
> bash, you can add the line
>
> export PATH=/usr/local/bin:$PATH
>
> to the file .bash_profile in your home directory (or create a new file by
> that name if it doesn't exist). From that point on, each new Terminal
> window that you open will have your PATH initialized so that g95 can be
> found.
>
>
>
>
>
>
> I don't see how you can count on /tmp/g95-install staying put after the
> next reboot. I installed in /usr/local/g95-install and then placed a
> symbolic link in /tmp, as described in the INSTALL file. It works fine.
>
>
| |
| Richard E Maine 2004-10-19, 3:58 pm |
| Paul Van Delst <paul.vandelst@noaa.gov> writes:
>
> So it wasn't just me who thought that was weird. Phew.
I sure thought it strange. Regardless of whether any particular
system does or doesn't happen to clear out /tmp at any particular
time, the explicit purpose of /tmp is temporary files (thus the name).
Some systems do clean it out regularly by default. On other systems
where it isn't the default, symins add a cleanup script. *IF*
this were the production install location, I'd think that such a
questionable default that I'd be lead to seriously wonder whether
I wanted to use software from someone whose judgement I found so
wanting.
As far as I know, the only reason /tmp is used is that that is a
hard-wired path where anyone probably has permisssion to write.
But if you don't have symin privileges, then most likely it is
a multi-user box, in which case lots of "fun" can ensue if two
different users end up "battling" over the same hard-wired path
(whoever gets there first after a reboot "wins"). So I just don't
think it a very good production solution to the permission issue.
*HOWEVER*, do note the "for permanent use" and similar qualifications
above. This is a beta version, and a fairly early beta at that.
You aren't *SUPPOSED* to be using it for production or permament use.
I know that a lot of people tend to complete ignore beta status, even
on commercial products (where doing so could technically leave you
open to lawsuits, not that I recall seeing any such lawsuits actually
happen). Witness things like the questions we occasionally get here
from people still using IBM's beta of xlf for the Mac.
It does matter and I'm quite willing to make diffferent judgements
based on the beta status of something. One might even consider it
a feature that you have to redefine the symlink after every reboot;
it helps remind you that you aren't using production software.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Paul Van Delst 2004-10-19, 3:58 pm |
| Richard E Maine wrote:
> Paul Van Delst <paul.vandelst@noaa.gov> writes:
>
>
>
>
> *IF* this were the production install location, I'd think that such a
> questionable default that I'd be lead to seriously wonder whether
> I wanted to use software from someone whose judgement I found so
> wanting.
I was going to say something like that also, but worded in a way that appeared less
forgiving (e.g. no *IF*). I snipped it from my reply since I didin't want any
usenet-misunderstanding leading to the g95 folks thinking I was dissing them.
> As far as I know, the only reason /tmp is used is that that is a
> hard-wired path where anyone probably has permisssion to write.
> But if you don't have symin privileges, then most likely it is
> a multi-user box,
Nope - single user. In fact, I think I'm one of the few people here who actually uses
their linux box for number-crunching/computing in general. Most folks just use them as
dumb terminals to the supercomputer. Effectively, we're not allowed to install *anything*
on our linux boxes. Things like netCDF libraries are o.k. (I think!) but compilers and
such are not to be installed without IT approval. *No one* is allowed root access to their
linux desktop. I really can't argue with the policy since if someone hacked into a desktop
they probably would have an easy time getting into the NWS supercomputer(s) and *that*
would be disastrous. But I can't help thinking that user installation of compilers into
their local directories (as a regular user, not root) should still be secure. Maybe not -
I don't know.
Some other offices 'round here are even more restrictive. To communicate data and software
with a guy two cubes down (but affiliated with a different NOAA line office) I used to ftp
everything to my own anon ftp site (across the country) for him to grab (email attachments
are restricted to a too small size.) Since then I've bought a thumbdrive that I use since
network connections are bureaucratically not allowed. Of course you can get a connection,
but the procedure is so convoluted as to be unusable. It's quite silly and there's plenty
of eyerolling about it all but, with the state of the world as it is, it seems to be
securely entrenched red-tape. And the red-tape is supa-sticky too - for some groups it can
take months to get some IT tickets attended to. One guy in the building here (but
different office) is retiring *next June* and he's not even bothering to ask for an
upgrade to his CVF install (it's pretty old) because the assumption is nothing will happen
before he leaves. Cripes!
[apologies for the symbolic stack dump...]
> *HOWEVER*, do note the "for permanent use" and similar qualifications
> above. This is a beta version, and a fairly early beta at that.
> You aren't *SUPPOSED* to be using it for production or permament use.
> I know that a lot of people tend to complete ignore beta status, even
> on commercial products (where doing so could technically leave you
> open to lawsuits, not that I recall seeing any such lawsuits actually
> happen). Witness things like the questions we occasionally get here
> from people still using IBM's beta of xlf for the Mac.
>
> It does matter and I'm quite willing to make diffferent judgements
> based on the beta status of something. One might even consider it
> a feature that you have to redefine the symlink after every reboot;
> it helps remind you that you aren't using production software.
A very good point. I retract any actual or implied criticism of the current g95
installation procedure in my original post.
cheers,
paulv
| |
| Richard E Maine 2004-10-19, 3:58 pm |
| Paul Van Delst <paul.vandelst@noaa.gov> writes:
> Effectively, we're not allowed to install *anything* on
> our linux boxes.
That can "work" if you have sufficiently responsive symin support.
I admin several linux boxes here and I'm happy to say that my users
don't *WANT* symin permissions. That's because they are more
comfortable with having me take care of such things... and I try to
keep them happy with that state of affairs.
On the other hand, we have a lot of systems here that were "supported"
by a big central outsourced contract. You don't want me to do a data
dump on all the problems we had. One set of problems is much like you
describe - the users can't install software and basically the support
staff won't either. Well, in theory you can get them to install stuff
after a lot of paperwork (and money), only to find that they are
incompetent to do it. I've had our paid support staff call me up more
than once to ask me how to install commercial software that they had
been paid to install - those are the good cases, where the support staff
at least did manage to get the job done (with my help - but that beats
not getting it done at all).
After much pain, we finally dumped that contractor from the engineering
workstations. Couldn't convince management to bring it in house, but
at least we got a different contractor who seems more willing to work
with us. I sat down with them to help specify the standard set of software
to be installed on the Macs, and they do install additional software as
needed for particular workstations. All is not perfect, but it is at
least workable now.
Hm.. Lets's see. Gotta be something clf-relevant here... :-) Ah. Did
I mention that apart of the standard install I helped specify includes
the NAG compiler (which we have a site license for)?
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Dave Seaman 2004-10-19, 3:58 pm |
| On Tue, 19 Oct 2004 17:50:41 GMT, Gordon Sande wrote:
> Dick Hendrickson wrote:
[color=darkred]
[color=darkred]
> Good question!
Agreed. But not all compilers require such fiddling. Commercial-quality
compilers tend to come with fancy installers that make the process
painless.
> I followed the recipe given for gfortran and found
> 0. I can only sudo fink ... from my admin account and not my
> user account. Probably a good thing in the large except
> I though the sudo/password fuss was intended to avoid
> the the extra fuss.
Using the 'sudo' command gives you root privileges. Do you want everyone
on your machine to have root privileges? Maybe you have no other users
to worry about, but the whole idea is that user accounts are for those
who have only user privileges and no admin or root privileges.
> 1. I needed to fiddle a low level file because FINK was
> not set to use UNSTABLE packages "out of the box".
> The fix was in the FAQ under "Why doesn't it work"!
> And there was some sort of problem with the path
> settings for fink so it was /sw/bin/fink instead of
> just fink.
If fink fixed up your shell initialization to add /sw/bin to your PATH,
which it should do by default, then all you need to do is open a new
Terminal window and then use the fink command. It will work from that
point on. The fink installer should have checked for that and printed a
message about your shell initialization.
> 2. The results have some sort of conflict between the Apple's
> supplied X11 and the older do-it-yourself X11. The fixes
> suggested in the diagnostics appear to do nothing. Why
> does a compiler require X11?
The compiler doesn't require X11, but some fink packages depend on X11.
You can't get fink to build those packages unless you have X11 installed
and configured as fink expects. Other fink packages are not affected.
> Why does having the Apple
> supplied Aqua compatible X11 grind things to a halt?
It's been a while since I looked at this, but I think you just need to
install the X11 SDK from the system install disks (it's an optional
install) and fink should be happy.
> (I am sure that if I wanted to be a full time symin
> the answer would be interesting but ...). Apple's slick
> X11 arrived circa Os X.3 and the fink scripts are probably
> older so I will have to wait for the fixes to work their way
> through the system.
> So now I do not have gfortran and I am reinforced in the notion
> that if and only if I fiddled full with Unix/Open Software/etc
> would I be able to get it to work. I will leave the explanation
> of why a compiler needs X11 as one of the great mysteries of the
> universe. It is clear that fink has a lot of ingenuity behind it
> as does gfortran, but at the end of the session all I have is a
> lot of wasted disk space that I may get around to clearing out.
Some fink packages require X11 and some do not. That's a feature of the
individual packages, not of fink or of the compiler. If a program
expects to display things in X windows when you run it, then it's going
to need access to X11 headers and libraries when you build it.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Gordon Sande 2004-10-19, 8:56 pm |
|
Dave Seaman wrote:
> On Tue, 19 Oct 2004 17:50:41 GMT, Gordon Sande wrote:
>
>
>
>
>
>
>
>
>
>
> Agreed. But not all compilers require such fiddling. Commercial-quality
> compilers tend to come with fancy installers that make the process
> painless.
>
Painless is exactly what I have observed for several things that
I have installed on Mac Os X that are clearly Unix (as well as Mac).
fink/gfortran did not make it into that company.
>
>
>
>
>
> Using the 'sudo' command gives you root privileges. Do you want everyone
> on your machine to have root privileges? Maybe you have no other users
> to worry about, but the whole idea is that user accounts are for those
> who have only user privileges and no admin or root privileges.
>
SUDO requires that the symin set up files so that the user gives his
account/password and proceeds. Mac Os X authentication asks for an
admin account/password and then proceeds. Much slicker. SUDO wants
someone to vouch for the user in advance and then for the user to
give a good account of himself. I have the impression that the usual
hack is to preapprove everyone for everything. Mac Os X authenticate
wants to hear about an admin account/password on the spot. Less
intrusive and less prone to the global bypass. SUDO makes sense
for admin of 100 user machines as in time shared Unices of yore.
Makes much less sense for a single user desktop microcomputer
where admin/user is more to prevent accidents.
>
>
>
> If fink fixed up your shell initialization to add /sw/bin to your PATH,
> which it should do by default, then all you need to do is open a new
> Terminal window and then use the fink command. It will work from that
> point on. The fink installer should have checked for that and printed a
> message about your shell initialization.
>
fink "out of the box" uses STABLE. One has to fiddle some file to get
it to look at UNSTABLE. Since gfortran is UNSTABLE one seems to be
told that it is not ready for prime time. The fink recipe as given
was for use with UNSTABLE and not as it arrives. The fink installation
reports that it is having trouble with paths which seems a bit curious
as it only has to deal with the Apple supplied Unix. Apple changed its
mind about the default shell so other aspects of account configuration
have undoubedly changed and the path problem goes with the territory.
>
>
>
> The compiler doesn't require X11, but some fink packages depend on X11.
> You can't get fink to build those packages unless you have X11 installed
> and configured as fink expects. Other fink packages are not affected.
>
>
>
>
> It's been a while since I looked at this, but I think you just need to
> install the X11 SDK from the system install disks (it's an optional
> install) and fink should be happy.
>
Open Office plays nicely with Apple's X11. Why do the other
folks get upset with it? You are right that one has to install
it separately and that is exactly what fink/gfortran was so unhappy
to find. Installing the Aqua X11 is a double click and authenticate
painless exercise. Likewise Xcode. etc
>
>
>
>
>
> Some fink packages require X11 and some do not. That's a feature of the
> individual packages, not of fink or of the compiler. If a program
> expects to display things in X windows when you run it, then it's going
> to need access to X11 headers and libraries when you build it.
>
The fink installation scripts for gfortran are the things that want
an X11 and object to the existing one supplied by Apple. Net result
is that after
"sudo fink install gfortran"
there is no gfortran after the reams and reams of compilations of
various X11 pieces. The only reason that makes sense to me fo the X11
stuff is that someone is trying to be helpful and it has backfired
badly. Perhaps gfortran only works for versions of Mac Os X that are
earlier than the version that came preinstalled. Not a helpful
situation.
>
| |
| Dave Seaman 2004-10-19, 8:56 pm |
| On Tue, 19 Oct 2004 20:52:29 GMT, Gordon Sande wrote:
> Dave Seaman wrote:
[color=darkred]
[color=darkred]
[color=darkred]
> Painless is exactly what I have observed for several things that
> I have installed on Mac Os X that are clearly Unix (as well as Mac).
> fink/gfortran did not make it into that company.
Agreed. I was thinking more of CodeWarrior. Compilers tend to be more
complicated to install than most other products.
[color=darkred]
[color=darkred]
[color=darkred]
> SUDO requires that the symin set up files so that the user gives his
> account/password and proceeds. Mac Os X authentication asks for an
> admin account/password and then proceeds. Much slicker. SUDO wants
> someone to vouch for the user in advance and then for the user to
> give a good account of himself. I have the impression that the usual
> hack is to preapprove everyone for everything. Mac Os X authenticate
> wants to hear about an admin account/password on the spot. Less
> intrusive and less prone to the global bypass. SUDO makes sense
> for admin of 100 user machines as in time shared Unices of yore.
> Makes much less sense for a single user desktop microcomputer
> where admin/user is more to prevent accidents.
You have a point, but perhaps that's part of what Apple had in mind when
they implemented fast user switching in Panther. I just run everything
on an admin account, since that is what I am used to in the Unix
environment, and therefore it is not a problem.
By that last statement I take it you mean that /sw/bin was not in your
PATH. But it should be, starting the first time you open a new Terminal
window after installing fink. Either that, or something went wrong with
the fink installation. The stable/unstable business has nothing to do
with that at all.
[color=darkred]
[color=darkred]
> fink "out of the box" uses STABLE. One has to fiddle some file to get
> it to look at UNSTABLE. Since gfortran is UNSTABLE one seems to be
> told that it is not ready for prime time. The fink recipe as given
> was for use with UNSTABLE and not as it arrives.
That has nothing to do with what I was talking about. I also use
UNSTABLE, but my paths are fine. I use "fink", not "/sw/bin/fink".
Is that the path problem you mean, or is there something else?
> The fink installation
> reports that it is having trouble with paths which seems a bit curious
> as it only has to deal with the Apple supplied Unix. Apple changed its
> mind about the default shell so other aspects of account configuration
> have undoubedly changed and the path problem goes with the territory.
When did you see this message about a "path problem"? Was it during the
fink installation, or was it later on when you tried to use a fink
command?
Fink looks at your shell startup file and attempts to patch it during the
installation in order set up your environment appropriately. Mine has
the statement
if [ -f /sw/bin/init.sh ]
then
. /sw/bin/init.sh
fi
which works in any of the Bourne-style shells (basically, anything other
than csh or tcsh). If fink successfully patched your startup file like
this, then you only need to open a new Terminal window in order to have
/sw/bin and /sw/sbin in your PATH. If you don't see a statement like
that, you will need to add it manually. See the fink documentation for
instructions.
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> Open Office plays nicely with Apple's X11. Why do the other
> folks get upset with it? You are right that one has to install
> it separately and that is exactly what fink/gfortran was so unhappy
> to find. Installing the Aqua X11 is a double click and authenticate
> painless exercise. Likewise Xcode. etc
Install what separately? Do you mean the optional X11 SDK from the Apple
installation disks? If you installed that, then I don't know what the
problem is, since I installed using "sudo fink install gfortran" and it
installed successfully. There were no complaints about Apple's X11. Try
the following command:
[gemini:dseaman] $ fink list system-xfree86
Information about 3921 packages read in 1 seconds.
i system-xfree86 2:4.3-2 [placeholder for user installed x11]
i system-xfree... 2:4.3-2 [placeholder for user installed x11 devel...
i system-xfree... 2:4.3-2 [placeholder for user installed x11 share...
If you don't see the three letter "i"'s in column 2, indicating that
those three packages are installed, then perhaps your Apple packages are
not properly installed.
[gemini:dseaman] $ fink describe system-xfree86
Information about 3921 packages read in 1 seconds.
system-xfree86-4.3-2: [placeholder for user installed x11]
This package represents a pre-existing installation
of X11 on your system that is not installed through
Fink.
| |
|
| On Tue, 19 Oct 2004 at 15:29 GMT, Dick Hendrickson (aka Bruce)
was almost, but not quite, entirely unlike tea:
> Does anybody besides me see a problem here? *nix systems
> are apparently unusable by people with normal computer
> skills! This stuff is complicated beyond words. Jason
> gives a seven step program (with an error that's even
> obvious to me!) and Dave write a couple hundred lines
> of explanation/correction/improvements. And I see there
> are 3 or 4 follow-ups to his post.
>
> Maybe I just need another cup of coffee, but after 20+
> years of unix development(?), why is it so hard to
> install a $%^&ing compiler?
It's not.
sudo apt-get install gcc
Easier to use that windows, IMNSHO.
Of course, there's ease of learn vs ease of use.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Unsubscribing from a mailing list you subscribed to is a basic IQ
test for Internet users. -- Author unknown, seen on the PCR-1000 list
| |
| Dave Seaman 2004-10-20, 4:06 pm |
| On Tue, 19 Oct 2004 20:52:29 GMT, Gordon Sande wrote:
[color=darkred]
I thought about this some more and I think I remember once encountering a
problem with this. I solved it by copying the files from /usr/X11R6 on
another Mac. Those files, in turn, probably date back to a time before
Apple's X11.app became available and originated from a separate
installation of XDarwin that I once obtained from www.xdarwin.org.
As I said, it's been a while since I looked at this. Looking again at
what's in fink, I notice there is a package called fix-apple-x11. I
don't have it installed, myself, but if nothing else works, you might try
installing that.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Richard E Maine 2004-10-20, 4:06 pm |
| Dave Seaman <dseaman@no.such.host> writes:
[color=darkred]
> On Tue, 19 Oct 2004 20:52:29 GMT, Gordon Sande wrote:
>
Not sure what's up here. Prompted by this discussion, I just installed
gfortran using fink myself. The only problem I had was of purely
local origin. (I first updated fink to 0.7.1, which was non-trivial
because of our facist firewall; I managed to get them to allow wget
and curl, so normal fink installs work, but fink's selfupdate doesn't
make it through).
I've got OSX 10.3.5 with Apple's X11. Nothing secial related to
X11 done in fink at all. I do recall some X11-fink related things
in the past. Hmm, do I still have notes on it? Ah yes - brief ones.
Back in Dec 2003 I have a note saying that I needed to do a
fink selfupdate (I had a workaround for the firewall facism at the
time) or "x stuff fails" (my note isn't any more explicit). But that
was on a fink 0.6.2 install. New machine since then (to go with our
new support contractor).
By the way, in seraching the package list on the fink web site,
I see an entry for g95 as well as gfortran. But my installed fink
doesn't see any such thing, even with unstable/main configured.
Maybe the web site is a bit premature.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
|
| Dave Seaman <dseaman@no.such.host> wrote in message news:<cl1jto$dga$1@mozo.cc.purdue.edu>...
>
> To install in /usr/local you will need to use the 'sudo' command, which gives
> you root access for a single command. You will probably also want to create a
> /usr/local/bin directory if you don't have one yet, and place a symbolic link
> g95 in that directory as described in the INSTALL file. You also need to make
> sure /usr/local/bin is in your PATH, where PATH is a shell variable that
> controls where the shell looks for executable programs that you call from the
> command line.
>
> If the preceding paragraph looks like gibberish to you, you may want to
> consider installing fink and using gfortran instead, since more of the process
> is automated when you go that route.
I don't understand most of what has been written so far in response to
my original question, as I can't seem to find any agreement on the
steps on how to install g95. I also tried your sudo fink install
gfortran, but that didn't seem to work either. I downloaded the tar.gz
and then double clicked it, and it installed a folder usr/local in my
home with loads of stuff in it. I changed directories to usr/local/bin
because gfortran was there, and then attempted the sudo command, but
then it came up with "Failed: no package found for procedure
'gfortran'!".
I really just don't get why it's so difficult! Even following the
gfortran instructions, it fails at the last bit when it says "to
invoke gfortran just type gfortran", which is all very well, except I
keep getting "does not recognise command" or something like that.
Argh!
| |
| Dave Seaman 2004-10-24, 3:56 pm |
| On 24 Oct 2004 05:25:12 -0700, Nat wrote:
> Dave Seaman <dseaman@no.such.host> wrote in message news:<cl1jto$dga$1@mozo.cc.purdue.edu>...
[color=darkred]
[color=darkred]
> I don't understand most of what has been written so far in response to
> my original question, as I can't seem to find any agreement on the
> steps on how to install g95.
Did you try any of them? There were some who advocated installing in
your home directory, which avoids any need to use 'sudo'. That method
might work if it's a single-user machine.
The steps that I posted should work for installing in
/usr/local/g95-install. As far as I am aware, the only problem anyone
pointed out in the steps I posted is that I did not mention the need to
use the unstable trees, as I will explain.
> I also tried your sudo fink install
> gfortran, but that didn't seem to work either.
What message did you get? If gfortran was not found by fink, it's
probably because you need to use the unstable tree in order for fink to
find the package. I was not aware of that, because I was already using
the unstable tree before I installed gfortran.
If you have fink installed, edit the file /sw/etc/fink.conf (using a
command such as 'sudo vi /sw/etc/fink.conf', or substituting your
favorite editor for 'vi'). Look for the the line beginning with
'Trees:', about 4 lines down. It probably looks like:
Trees: local/main stable/main stable/crypto local/bootstrap
You can change this to read:
Trees: local/main stable/main stable/crypto local/bootstrap unstable/main unstable/crypto
(all on one line), and then try 'sudo fink install gfortran' again. Fink
assures us that the use of the unstable trees is reasonably safe, and I
have been using it for years with no problem. It's possible you may need
to do a 'sudo fink selfupdate' at some point.
>I downloaded the tar.gz
> and then double clicked it, and it installed a folder usr/local in my
> home with loads of stuff in it. I changed directories to usr/local/bin
> because gfortran was there, and then attempted the sudo command, but
> then it came up with "Failed: no package found for procedure
> 'gfortran'!".
I take it you downloaded manually and therefore fink didn't find it where
it expected (in /sw/src). If you add the unstable trees and then repeat
the 'sudo fink install gfortran', fink should be able to find it.
There's still the question of whether fink will accept your X11 setup.
Remember from the previous discussion that you need to install the
X11.SDK from the system installation disks, since it is not installed by
default.
> I really just don't get why it's so difficult! Even following the
> gfortran instructions, it fails at the last bit when it says "to
> invoke gfortran just type gfortran", which is all very well, except I
> keep getting "does not recognise command" or something like that.
> Argh!
That's probably a path problem. Try using the full pathname for gfortran
and see if that helps. If so, you need to add the directory to your PATH
environment variable, as was discussed previously. If it's in /sw/bin,
then it may be that all you need to do is open a new Terminal window,
assuming that the fink installation inserted the proper initialization
code into your shell startup file, as it should. See the fink
documentation at
<
http://fink.sourceforge.net/doc/use...hpLang=en#setup>
for more about this.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Dave Seaman 2004-10-24, 3:56 pm |
| On Sun, 24 Oct 2004 15:27:04 +0000 (UTC), Dave Seaman wrote:
> On 24 Oct 2004 05:25:12 -0700, Nat wrote:
[color=darkred]
> Did you try any of them? There were some who advocated installing in
> your home directory, which avoids any need to use 'sudo'. That method
> might work if it's a single-user machine.
> The steps that I posted should work for installing in
> /usr/local/g95-install. As far as I am aware, the only problem anyone
> pointed out in the steps I posted is that I did not mention the need to
> use the unstable trees, as I will explain.
I got a little  there between gfortran (which is a fink install
and needs the unstable tree) and g95 (which is not a fink install and can
be installed in /usr/local/g95-install, as I suggested, or perhaps in
your own home directory, as others suggested).
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Mike Zulauf 2004-10-25, 4:01 pm |
| In article <clgtj0$ssu$1@mozo.cc.purdue.edu>,
Dave Seaman <dseaman@no.such.host> wrote:
> I got a little there between gfortran (which is a fink install
> and needs the unstable tree) and g95 (which is not a fink install and can
> be installed in /usr/local/g95-install, as I suggested, or perhaps in
> your own home directory, as others suggested).
You can now install g95 through fink. I've got both g95 and gfortran
installed, in fact.
Mike
--
Mike Zulauf
mazulauf@met.utah.edu
| |
| Richard E Maine 2004-10-25, 4:01 pm |
| Mike Zulauf <mazulauf@met.utah.edu> writes:
> You can now install g95 through fink. I've got both g95 and gfortran
> installed, in fact.
What's the trick for g95 via fink then? I saw g95 mentioned in the
package list on the fink web site, but fink doesn't actualy find it
when I try. I installed gfortran through fink fine, and g95 manually,
but can't get fink to see a g95. I just retried right before posting
this to see if perhaps things have changed since last w .
Yes, I configured fink to look in unstable/main as well as
stable/main. Is it perhaps under something other than unstable/main?
I'm using a brand new download of fink 0.7.1.
I do see that there is an update of fink itself under the unstable
stuff. I didn't do that. I suppose perhaps that could be required.
Since I *DO* use this machine for production work, I didn't want to go
whole hog and install unstable versions of everything. I configure
fink for unstable just to install those very few things that I want
that aren't available in the stable branch. Then I reconfigure it
back to stable. (I just keep 2 copies of the fink config file to
make switching between stable and unstable easy - just copy the
right config fi9le and then run "fink index".)
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Dave Seaman 2004-10-25, 4:01 pm |
| On Mon, 25 Oct 2004 11:20:39 -0700, Richard E Maine wrote:
> Mike Zulauf <mazulauf@met.utah.edu> writes:
[color=darkred]
> What's the trick for g95 via fink then? I saw g95 mentioned in the
> package list on the fink web site, but fink doesn't actualy find it
> when I try. I installed gfortran through fink fine, and g95 manually,
> but can't get fink to see a g95. I just retried right before posting
> this to see if perhaps things have changed since last w.
> Yes, I configured fink to look in unstable/main as well as
> stable/main. Is it perhaps under something other than unstable/main?
> I'm using a brand new download of fink 0.7.1.
> I do see that there is an update of fink itself under the unstable
> stuff. I didn't do that. I suppose perhaps that could be required.
> Since I *DO* use this machine for production work, I didn't want to go
> whole hog and install unstable versions of everything. I configure
> fink for unstable just to install those very few things that I want
> that aren't available in the stable branch. Then I reconfigure it
> back to stable. (I just keep 2 copies of the fink config file to
> make switching between stable and unstable easy - just copy the
> right config fi9le and then run "fink index".)
I tried this just now and on my first attempt, "fink list g95" didn't
show anything. But then I did a "fink selfupdate" and after that
finished, I was able to install and run g95 from the fink distribution.
--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>
| |
| Richard E Maine 2004-10-25, 8:56 pm |
| Dave Seaman <dseaman@no.such.host> writes:
> I tried this just now and on my first attempt, "fink list g95" didn't
> show anything. But then I did a "fink selfupdate" and after that
> finished, I was able to install and run g95 from the fink distribution.
Hmm. I bet it is that unstable version of fink that I'm missing.
Fink selfupdate won't work through the facist firewall here; yes,
I tried everything mentioned in the fink docs - the firewall won't
allow any of the options. Was about to take it home and update
from there (it is a laptop, so that would work), but then found
how to manually update to 0.7.1. But that manual update was only
to the stable version. I can install some unstable things by just
changing the fink config file, but not g95.
Well, anyway the fact that you did a selfupdate at least does point to
the area of difference betwen your situation and mine. For now I'll
be happy now that I understand roughly wherein the difference is. As
I said, I have a sucessful manual installation of g95, so I don't
actually need to do it via fink right now - just wanted to understand
why the difference.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
|
|
|
|
|