Re: Patch for Portland compiler support
* Jeff Squyres wrote on Wed, Nov 17, 2004 at 06:30:27PM CET: Actually, before I attempt the LT 2.x patch, how does this look for the 1.5 patch? I checked pgcc, pgCC, pgf77, and pgf90, both in the 1.5 test suite (I assuming that configuring LT with CC=pgcc [etc.] and then make check is what is necessary?) and with a small sample automake Yes, that should be fine. package that I made explicitly for testing porpoises. All seems to be working properly. Great! Could someone who is Wise in the Ways of Libtool tell me if this patch looks ok? I did [at least] one questionable thing: in the Linux linker section, I had to check for pgf77 or pgf90, because, contrary to the PG documentation, pgf77 and pgf90 need an additional -fpic in their linker command to create a shared library properly. Is this necessary for just a regular shared library or for a shared module (that can be loaded with dlopen)? If the former, then I think your patch is ok. Glancing at libtool.m4, there are a number of cases where it's necessary, maybe we should put them in a separate variable, like pic_link_flag or so. That'll only be for libtool HEAD, though. I'm also CC'ing the PG support team to see if they have any input. They should update their documentation. :-) Here's the revised patch (including some fixes from this morning; based on tests, not the PG documentation ;-) ): Note that branch-2-0 tests are somewhat more challenging, esp. on the Fortran front. I might want to wait with applying this patch until you get to those (in case you find out more necessary stuff there). Other than that, I'll take the patch. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
On Nov 18, 2004, at 3:49 AM, Ralf Wildenhues wrote:
I did [at least] one questionable thing: in the Linux linker
section, I had to check for pgf77 or pgf90, because, contrary to the
PG
documentation, pgf77 and pgf90 need an additional -fpic in their
linker command to create a shared library properly.
Is this necessary for just a regular shared library or for a shared
module (that can be loaded with dlopen)? If the former, then I think
your patch is ok.
It seems to be necessary even for normal shared libraries -- without
it, I get an error from the Portland linker.
Glancing at libtool.m4, there are a number of cases where it's
necessary, maybe we should put them in a separate variable, like
pic_link_flag or so. That'll only be for libtool HEAD, though.
Sounds reasonable.
Here's the revised patch (including some fixes from this morning;
based
on tests, not the PG documentation ;-) ):
Note that branch-2-0 tests are somewhat more challenging, esp. on the
Fortran front. I might want to wait with applying this patch until you
get to those (in case you find out more necessary stuff there).
Other than that, I'll take the patch.
That sounds like a reasonable plan. Let me port this over to the CVS
HEAD and see if it helps refine the 1.5 patch. Today's pretty hosed
for me; I can probably get to this tomorrow or over the weekend.
Many thanks.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
Hi Jeff, * Jeff Squyres wrote on Wed, Nov 17, 2004 at 03:00:22PM CET: Some of the consumers of our software use the Portland Group compilers (http://www.pgroup.com/). Libtool 1.5.x doesn't seem to recognize these compilers, and therefore doesn't always do the Right Things. Libtool doesn't know about Portland's compilers at all (so far). I have *barely* dived into the libtool source, but I have come up with a patch for the current CVS branch-1-5 that seems to make libtool do the Right Things for pgcc on Linux (I didn't try for an analogue on the CVS trunk for the 2.x series). Could this patch be considered for future releases of Libtool? Actually, I'm wondering about the name. There has once been a pentium gcc, abbreviated pgcc as well. How unfortunate :( I don't know how much the pentium gcc is still in use, but the fact that this one is not meant deserves at least a comment within the m4 snippet. Looking at its webpage, it looks pretty dead, though. (Fortunately, gcc on linux understands all the variable values you've submitted so far. We might just get away with it anyway.) But certainly there will be more problems with pgcc? What about pgf77 and pgCC? Could you or one of your consumers be bothered to try branch-2-0 of libtool (1.9f will do fine as well) and report us more possible problems its testsuite reports (VERBOSE=x output for failed tests is good), so that we can support it right, not only halfway? (This is the more interesting for you since we won't bother much with libtool-1.5 any more as soon as 2.0 is out). Do you/your consumers use pgcc on Windows? That's probably going to be a whole different (and scarier) story. Other than that, we love ChangeLog entries. :) --- libtool.m4 19 Sep 2004 12:13:50 - 1.314.2.50 +++ libtool.m4 17 Nov 2004 13:54:58 - @@ -4952,6 +4952,11 @@ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC' _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static' ;; + pgcc*) + _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' + _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic' + _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic' +;; ccc*) _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,' # All Alpha code is PIC. Please forgive me if this patch is egregiously wrong -- if it is, any advice on making it Right would be tremendously appreciated! Looks good. The branch-2-0 equivalent would be similar -- just grep for ccc in libtool/m4/libtool.m4. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
On Nov 17, 2004, at 9:38 AM, Ralf Wildenhues wrote:
Some of the consumers of our software use the Portland Group compilers
(http://www.pgroup.com/). Libtool 1.5.x doesn't seem to recognize
these compilers, and therefore doesn't always do the Right Things.
Libtool doesn't know about Portland's compilers at all (so far).
Gotcha.
I have *barely* dived into the libtool source, but I have come up with
a patch for the current CVS branch-1-5 that seems to make libtool do
the Right Things for pgcc on Linux (I didn't try for an analogue on
the
CVS trunk for the 2.x series). Could this patch be considered for
future releases of Libtool?
Actually, I'm wondering about the name. There has once been a pentium
gcc, abbreviated pgcc as well. How unfortunate :(
I don't know how much the pentium gcc is still in use, but the fact
that
this one is not meant deserves at least a comment within the m4
snippet.
Looking at its webpage, it looks pretty dead, though.
Yikes! I had no idea about pentium-gcc. I trust your judgment on this
one -- if it's ok with you guys to ignore, I'm happy to ignore it, too.
;-)
(Fortunately, gcc on linux understands all the variable values you've
submitted so far. We might just get away with it anyway.)
But certainly there will be more problems with pgcc? What about pgf77
and pgCC? Could you or one of your consumers be bothered to try
branch-2-0 of libtool (1.9f will do fine as well) and report us more
possible problems its testsuite reports (VERBOSE=x output for failed
tests is good), so that we can support it right, not only halfway?
(This is the more interesting for you since we won't bother much with
libtool-1.5 any more as soon as 2.0 is out).
Shirley -- I can do this right now. I'll post back shortly.
Do you/your consumers use pgcc on Windows? That's probably going to be
a whole different (and scarier) story.
Unfortunately, no. We have a Cygwin port, but to my knowledge people
only use gcc with it there.
[snippage]
Please forgive me if this patch is egregiously wrong -- if it is, any
advice on making it Right would be tremendously appreciated!
Looks good. The branch-2-0 equivalent would be similar -- just grep
for
ccc in libtool/m4/libtool.m4.
Will do.
I'll check into CC/f77 issues and post back with a new set of patches
-- for 1.5.x and 2.x.
Thanks!
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
