Hi Jason,
It seems that python could be compiled with pgi compiler as long as
we change the compiler flag " -Xlinker -export-dynamic ", which is the
defaut option in the GNU environment. I have tried some other available
options in the configuration file shown below. if the option *
LINKFORSHARED="-Wl,--export-dynamic"* mentioned in the *line 7503* was
choosen, compilation of python with PGI will be completed successfully.
Please have a try.
*[lin.comp Python-2.6.6]$ vim configuration*
7472 if test -z "$LINKFORSHARED"
7473 then
7474 case $ac_sys_system/$ac_sys_release in
7475 AIX*) LINKFORSHARED='-Wl,-bE:Modules/python.exp -lld';;
7476 hp*|HP*)
7477 LINKFORSHARED="-Wl,-E -Wl,+s";;
7478 # LINKFORSHARED="-Wl,-E -Wl,+s
-Wl,+b\$(BINLIBDEST)/lib-dynload";;
7479 BSD/OS/4*) LINKFORSHARED="-Xlinker -export-dynamic";;
* 7480 Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dynamic";;
* 7481 # -u libsys_s pulls in all symbols in libsys
7482 Darwin/*)
7483 # -u _PyMac_Error is needed to pull in the mac toolbox glue,
7484 # which is
7485 # not used by the core itself but which needs to be in the
core so
7486 # that dynamically loaded extension modules have access to it.
7487 # -prebind is no longer used, because it actually seems to
give a
7488 # slowdown in stead of a speedup, maybe due to the large
number of
7489 # dynamic loads Python does.
7490
7491 LINKFORSHARED="$extra_undefs"
7492 if test "$enable_framework"
7493 then
7494 LINKFORSHARED="$LINKFORSHARED
"'$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)'
7495 fi
7496 LINKFORSHARED="$LINKFORSHARED";;
7497 OpenUNIX*|UnixWare*) LINKFORSHARED="-Wl,-Bexport";;
7498 SCO_SV*) LINKFORSHARED="-Wl,-Bexport";;
7499 ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
* 7500 FreeBSD*|NetBSD*|OpenBSD*|DragonFly*)
7501 if [ "`$CC -dM -E - </dev/null | grep __ELF__`" != "" ]
7502 then
7503 LINKFORSHARED="-Wl,--export-dynamic"
7504 fi;;
* 7505 SunOS/5*) case $CC in
7506 *gcc*)
7507 if $CC -Xlinker --help 2>&1 | grep export-dynamic
>/dev/null
7508 then
7509 LINKFORSHARED="-Xlinker --export-dynamic"
7510 fi;;
7511 esac;;
7512 CYGWIN*)
7513 if test $enable_shared = "no"
7514 then
7515 LINKFORSHARED='-Wl,--out-implib=$(LDLIBRARY)'
7516 fi;;
7517 QNX*)
7518 # -Wl,-E causes the symbols to be added to the dynamic
7519 # symbol table so that they can be found when a module
7520 # is loaded. -N 2048K causes the stack size to be set
7521 # to 2048 kilobytes so that the stack doesn't overflow
7522 # when running test_compile.py.
7523 LINKFORSHARED='-Wl,-E -N 2048K';;
Best Regards,
Lin
2011/3/16 Jason Swails <jason.swails.gmail.com>
> Hi Lin,
>
> I don't think Python is compiled in static, but I don't think this should
> be
> an issue for a couple reasons.
>
> Most of the PGI users, I think, will have GCC readily available (even many
> systems using modules, like Kraken and Athena) with libraries in standard
> locations so that you don't have to load a new module to compile python,
> then have it break after you unload it.
>
> Also, if this all fails, then you can use -nopython to force Amber to use
> the system python instead of the one that came bundled with AmberTools.
> All
> of this should be handled automatically at compile time, so the user
> doesn't
> have to actually *see* any of this going on.
>
> I think Ross has a system here with PGI compilers that I can test some
> stuff
> out on, so I'll report back on my findings.
>
> All the best,
> Jason
>
> On Wed, Mar 16, 2011 at 11:31 AM, Lin Fu <linfu3200.gmail.com> wrote:
>
> > Hi Jason,
> >
> > You mean the python compiled here is static version, which will not be
> > dynamically linked to any gnu stuff. If both python here in the amber and
> > sander are static version, it will be fine since it is only system level
> > call instead of source code level call. but If both are only dynamical
> link
> > version, it might cause problem. since we might need to load both gnu and
> > pgi stuff, which is usually excluded by module on the cluster. please
> > correct me if it is not. Thanks.
> >
> > Best Regards,
> > Lin
> > 2011/3/16 Jason Swails <jason.swails.gmail.com>
> >
> > > It should make no difference. The python interpreter can be compiled
> > with
> > > GCC, and it can run any python script. MMPBSA.py calls sander via a
> > system
> > > call, so as long as it's *installed*, it'll work.
> > >
> > > Also keep in mind that MMPBSA.py is not compiled, since python is an
> > > interpreted language. We can get away with this because Python doesn't
> > > actually *link* to anything, it's just used to interpret python
> > > programs/scripts.
> > >
> > > --Jason
> > >
> > > On Wed, Mar 16, 2011 at 10:39 AM, Lin Fu <linfu3200.gmail.com> wrote:
> > >
> > > > Hi Jason,
> > > >
> > > > >It doesn't seem like there's really any way around this. What do
> > people
> > > > think about letting Python just use GCC if it can find it in case
> > someone
> > > > chooses pgi at configure time?
> > > > Not sure whether it will make the user confusing or not. Will the
> > > MMPBSA.py
> > > > be compatible with the MPI with different compilers if user runs in
> > > > parallel. Another problem is that on most clusters Environment Module
> > is
> > > > used to manage the different enviroment of compiler, such as module
> > load
> > > > intel/pgi/gnu. some options are exclusive. Can gnu-compiled MMPBSA.py
> > > > invoke
> > > > the pgi-compiled serial version of sander, which is called by the
> > > > MMPBSA.py.
> > > > >if you can reconfigure using -nopython, and run it again to see if
> > there
> > > > are any errors elsewhere that would be great.
> > > > It seems that mtkpp can also not pass the pgi compiler even after
> > > excluding
> > > > the python module due "-Wall" problem, but Ben said that he will give
> > an
> > > > solution about that.
> > > >
> > > > Best Regards,
> > > > Lin
> > > >
> > > > 2011/3/15 Jason Swails <jason.swails.gmail.com>
> > > >
> > > > > Hi Lin,
> > > > >
> > > > > It doesn't seem like there's really any way around this. What do
> > > people
> > > > > think about letting Python just use GCC if it can find it in case
> > > someone
> > > > > chooses pgi at configure time?
> > > > >
> > > > > It won't cause any incompatibilities with anything else (as it's
> > quite
> > > > > isolated), and I think that getting it to compile correctly with
> PGI
> > is
> > > > > going to be difficult.
> > > > >
> > > > > We already have to force Python to use a different (xcode) compiler
> > > when
> > > > > building on Mac OS X, so I don't think this is really going to
> cause
> > > any
> > > > > issues.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > And Lin, if you can reconfigure using -nopython, and run it again
> to
> > > see
> > > > if
> > > > > there are any errors elsewhere that would be great.
> > > > >
> > > > > Thanks!
> > > > > Jason
> > > > >
> > > > > On Tue, Mar 15, 2011 at 4:42 PM, Lin Fu <linfu3200.gmail.com>
> wrote:
> > > > >
> > > > > > Hi Jason,
> > > > > >
> > > > > > I have tried to compile this version of ambertools with pgi, but
> it
> > > > > failed
> > > > > > to compile python module since "-Xlinker and -export-dynamic" can
> > not
> > > > be
> > > > > > recognized by pgcc. Not sure whether you got similar error.
> > > > > > pgcc -Xlinker -export-dynamic -o python \
> > > > > > Modules/python.o \
> > > > > > libpython2.6.a -lpthread -ldl -lpthread
> > > -lutil
> > > > > > -lm
> > > > > > pgcc-Error-Unknown switch: -Xlinker
> > > > > > pgcc-Error-Unknown switch: -export-dynamic
> > > > > > make[1]: *** [python] Error 1
> > > > > >
> > > > > > Best Regards,
> > > > > > Lin
> > > > > >
> > > > > > 2011/3/14 Jason Swails <jason.swails.gmail.com>
> > > > > >
> > > > > > > If anyone has access to the PGI compilers, bits of AmberTools
> > > aren't
> > > > > > > compiling for me out-of-the-box on athena, but there are enough
> > > > > > > Cray-specific idiosyncrasies that I'm not confident enough to
> > label
> > > > > them
> > > > > > > PGI
> > > > > > > problems.
> > > > > > >
> > > > > > > Also, for those of you who will try building this alongside
> > Amber11
> > > > > > (dirty
> > > > > > > or clean), don't forget to apply the script AT15_Amber11.py
> after
> > > > > > configure
> > > > > > > (from any directory, it just uses absolute paths based on
> > > AMBERHOME).
> > > > > > > Configure should print a warning message about this in any
> case.
> > > > > > >
> > > > > > > All the best,
> > > > > > > Jason
> > > > > > >
> > > > > > > On Mon, Mar 14, 2011 at 12:03 PM, David A Case <
> > > > > case.biomaps.rutgers.edu
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hi everyone:
> > > > > > > >
> > > > > > > > The second "release candidate" for AmberTools 1.5 is here:
> > > > > > > >
> > > > > > > > http://ambermd.org/downloads/AmberTools.14mar11.tar.bz2
> > > > > > > >
> > > > > > > > Please test this out:
> > > > > > > >
> > > > > > > > a. on its own
> > > > > > > > b. in conjunction with Amber11 (either in a clean install,
> > or
> > > > > > untarred
> > > > > > > > on top of a working, "dirty" directory already
> > containing
> > > AT
> > > > > > 1.4.)
> > > > > > > >
> > > > > > > > It is better to test this than the at15-with-patches branch,
> > > since
> > > > > this
> > > > > > > is
> > > > > > > > what users would actually be getting. No GEM here yet, but
> > other
> > > > > > things
> > > > > > > > should be getting close.
> > > > > > > >
> > > > > > > > ...thx...dac
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > AMBER-Developers mailing list
> > > > > > > > AMBER-Developers.ambermd.org
> > > > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Jason M. Swails
> > > > > > > Quantum Theory Project,
> > > > > > > University of Florida
> > > > > > > Ph.D. Candidate
> > > > > > > 352-392-4032
> > > > > > > _______________________________________________
> > > > > > > AMBER-Developers mailing list
> > > > > > > AMBER-Developers.ambermd.org
> > > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > > >
> > > > > > _______________________________________________
> > > > > > AMBER-Developers mailing list
> > > > > > AMBER-Developers.ambermd.org
> > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jason M. Swails
> > > > > Quantum Theory Project,
> > > > > University of Florida
> > > > > Ph.D. Candidate
> > > > > 352-392-4032
> > > > > _______________________________________________
> > > > > AMBER-Developers mailing list
> > > > > AMBER-Developers.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > >
> > > > _______________________________________________
> > > > AMBER-Developers mailing list
> > > > AMBER-Developers.ambermd.org
> > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > >
> > >
> > >
> > >
> > > --
> > > Jason M. Swails
> > > Quantum Theory Project,
> > > University of Florida
> > > Ph.D. Candidate
> > > 352-392-4032
> > > _______________________________________________
> > > AMBER-Developers mailing list
> > > AMBER-Developers.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 16 2011 - 16:30:02 PDT
