Hello,
There are a couple avenues open to you:
1) First, edit the configure script and replace "gcc" with "gcc44" wherever
you can find it (or if you can confidently pick out the important spots,
just replace it where you need to). Same with gfortran -> gfortran44 and
g++ -> g++44.
2) An alternative option is to create symbolic links to gfortran44, gcc44,
and g++44 named gfortran, gcc, and g++, respectively, to a place in your
PATH *BEFORE* the default gcc-4.1.2 binaries exist. I'm not exactly sure
how RHEL works, but for Ubuntu, /usr/bin/gcc is just a symbolic link to
whichever version it uses (i.e. /usr/bin/gcc-4.4). If this is the case, you
can just redirect those links to the version you want to use. Note, a
symbolic link is probably safest here (to preserve any relative paths that
may be built into the binary). Do this with "ln -s" as opposed to just
"ln". For example:
ln -s /path/to/gcc44 /new/path/to/gcc
where /new/path/to comes before /usr/bin in $PATH.
For my systems, I use (maybe a variant) of option (2). But here are the
pros and cons of each, IMO:
1) Pros: It works and it's an easy change that can be implemented with a
single find-and-replace command with your favorite text editor.
Cons: It's a fix for amber only. If another package you want to build needs
to be compiled with the newer compilers, you'll have to figure out how to
make the analogous fix to that package as well. Also, if you try to use
that configure script on another machine (i.e. if you copy over the source
code without untarring a fresh copy if you've made modifications or
something), you'll need to remember to undo those changes or it won't work
(unless of course it's an equivalent RHEL machine).
2) Pros: Once the change is made, your default compilers for everything will
be the 4.4 versions.
Cons: You're mucking around in important root directories with root
privileges (without sudo you can't redirect links), so mistakes can be
harmful to your system. Therefore, choice 2 requires care and confidence in
what you're doing.
As for using the correct libraries: each version of the gcc compiler
*should* link the proper libraries without having to do anything yourself,
and that has been my experience. But then again, I've always been careful
to use soft links to compilers when taking route 2 so if the compilers rely
on a built-in relative path to its libraries, referencing the link won't
break that.
It's been verbose, but hopefully helpful.
All the best,
Jason
On Wed, Aug 25, 2010 at 3:51 PM, Richard Owczarzy <rowczarzy.idtdna.com>wrote:
> Hello Mark,
>
> I am strugling with the same bug. Could you be more specific about solution
> for RHEL5? I can install gcc version 4.4.0 using yum packager alongside
> standard 4.1.2 version. However, new version have executables gcc44, g++44
> and gfortran44. How do I modify Amber 11 configure or config.h files to
> properly use new gcc version? How do I point to correct libraries for gcc
> version 4.4?
>
> Thank you,
>
> Richard Owczrazy
> Integrated DNA Technologies
>
>
>
> -----------------------------------------------------------------------------------------------------------
> From: Mark Williamson <mjw.sdsc.edu <mailto:mjw.sdsc.edu?Subject=Re%3A%20%5BAMBER%5D%20Workaround%20for%20gfortran-4.1.2%3F>
> >
> Date: Tue, 20 Jul 2010 16:51:43 -0700
>
>
> Marc Moreau wrote:
> > Hello all,
> >
> > I am trying to compile against gcc-4.1.2 which includes the buggy
> > gfortran-4.1.2.
> >
> > I'm trying to compile with -O2 instead of the default -O3. Does anyone
> > know of any other things to try, or specific compiler flags that allow
> > a work-around of the buggy section in fortran?
> >
> > I am aware that 4.3.2 and 4.4.x are out, but my system is old ( Centos
> > 4.3 ) which doesn't have RPMS for those compilers. Further, if I
> > upgrade the compiler ( more specifically the libraries ) I need to go
> > back and recompile && regression test all the other MD suites in use.
> > It's a non-trivial number so I really don't want to do that. We
> > expect that we will be getting new Hardware soon which will allow for
> > an upgrade of OS and such, then I can roll the old hardware to the new
> > system. But that is later. For now, upgrade is not an option.
> >
> >
> > -- Marc
> >
>
> Hi Marc,
>
> I've hit this frustrating issue in the past with RHEL4 (which
> essentially is what CentOS4 cloned). There is a RPM based solution
> within RHEL5 and CentOS5, but I also had upgrade constraints here.
>
> My solution for RHEL4 was to compile the 4.4 gcc compiler from scratch
> and then use it to build AMBER. I've written a howto on this and you can
> find it at:
>
> http://www.wmd-lab.org/mjw/howtos/compiling_gcc_4_4_4_under_RHEL4.txt
>
> It works rather well for me.
>
>
> --
> Mark Williamson, Post Doc
> Walker Molecular Dynamics Group
> Room 395E
> San Diego Supercomputer Center
> 9500 Gilman Drive
> La Jolla, CA 92093-0505
> Email: mjw at sdsc.edu
> Office: 858-246-0827
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Aug 25 2010 - 13:30:06 PDT
