Re: Patch for Portland compiler support

[Ralf Wildenhues]

* 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

■噂の特だね！！ただだよ！ドットコム■創刊号

[ただだよ！ドットコム]

$B(.!z!y(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!z!y(/(B
(B  [EMAIL PROTECTED]@[EMAIL PROTECTED](B2004.11$BH/9T!d(B
$B(1!z!y(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!z!y(0(B
(B 
$B!y(B1,351,792$BItH/9T!y(B
(B
$B"[EMAIL PROTECTED]"d(B
(B
$B!!R2p$O40A4:_Bp6HL3$N$*;E;v$G$9!#(B
$BFq$7$$CN<[EMAIL PROTECTED],MW!#(B
$BD6=i?4/$7$G$bM>J,$K2T$2$l$P!&!&!&(B
(B[EMAIL PROTECTED]&$=$&;E;v$,!&!&!&(B
$B!vI,$:Kh7n;E;v$,$[$7$$$N$K!&!&!&(B
(B
$B(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/(.(,(/(B
(B   $BA4(B  $BIt(B  $B2r(B $B!!>C(B  $B$5(B  
$B$l(B  $B!!(B  $B$k(B   $B!!(B $B$N(B  $B$K(B $B!&!&!&(B
$B(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0(1(,(0(B
(B
$BDL>o$N:_Bp%o!<%/$O%9%-%k!J7P83Ey!K$,$J$1$l$P$G$-$^$;$s!#(B
$B$=$N7k2L!"%9%-%k%A%'%C%/$Kl$rGK2u$9$k6HL3K832$H$7$FAJ$($?$$$N$,(B
$BK\2;$G$9!#(B
(B
$BFbMF$NL5$$:_Bp%o!<%/$K$O!V$b$&%&%s%6%j!*!*!W$G$9!#(B
(B
$B!VFCJL$J;q3J$,$J$$!D!W"*!X(BSOHO$B!Y$K;q3J!"8!Dj$OI,MW$"$j$^$;$s(B
$B!V<+J,$O$b$&:[EMAIL 
(BPROTECTED]"*:_Bp%o!<%/$KG/Np$O4X78$J$$$7DjG/$b$"$j$^$;$s!*(B
$B!V0i;y$,[EMAIL PROTECTED]"*#1F|#1;~4VDxEY$J$i==J,$"$k$O$:$G$9!*(B
$B!VJ8;zF~NODxEY$7$+=PMh$J$$!D!W"*$=$l$G==J,$G$9!#(B
(B
$BEPO?o$K0BDjE*$J;E;v$r6!5k$9$k$3$H$,3N\:Y;qNA!JL5NA!K$O2<5-$N%[!<%`%Z!<[EMAIL PROTECTED]<$5$$"!"!"!(B
(B  $B!!(B
$B!!(B
$B!!(B$B!~!!(Bhttp://tadadayo.infoseek.ne.jp $B!~(B
$B!!(B
(B
$B!!(B
$B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
$B!c;[EMAIL PROTECTED]http://tadadayo.infoseek.ne.jp$B!Y$X%"%/%;%9$9$k!#(B
$B#2(B. $B!X;[EMAIL PROTECTED])!<%`!Y$K$7$?$,$C$FI,MW;v9`$rF~NO$9$k!#(B
$B#3!%(B $B%a!<%k%"%I%l%9$O$*4V0c$($N$J$$$h$&$KF~NO$7$F$/[EMAIL PROTECTED](B
$B#4!%(B $BF~NO;v9`$r3NG'$7!XAw?.!Y$r%/%j%C%/!#(B
(B 
$B"(I,$:;[EMAIL PROTECTED]<%I$r$*K:$l$J$$$h$&$K$*4j$$CW$7$^$9!#(B
(B
(B-
$B"(%a!<%k$,Jx$l$F8+$($k>l9g$O!V(BMS$B%4%7%C%/!W$d!V(BOsaka$BEyI}!W(B
(B  $B$J$IEyI}%U%)%s%H$G$4Mw$/[EMAIL PROTECTED](B
$B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
(B Copyright (C) 2004 $B!w(BFreedom,Inc.  All rights reserved.
(B $B5v2D$J$/E>:\$9$k$3$H$r6X$8$^$9!#(B
$B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
(B
(B
(B
(B
(B
(B
(B
(B
(B
(B___
(BLibtool mailing list
([EMAIL PROTECTED]
(Bhttp://lists.gnu.org/mailman/listinfo/libtool

Using libtool 2.0 in autoconf tests

[Sander Niemeijer]

Hi,
I have send this question to the list about a month ago, but 
unfortunately, there hasn't been an answer yet, and the release of 
libtool 2.0 is not that far away (right?).



I have some self written autoconf tests that check for linking shared 
libraries against some specific other libraries (these other libraries 
should be available as shared libraries or we might have a PIC problem. 
That is what my tests checks for). For this I had to create a variant 
of the AC_LINK_IFELSE macro that doesn't use CC/LD but the libtool 
script to perform the compilation/linking. With libtool 1.5.x the 
libtool script was nicely available, but with libtool 2.0 the libtool 
script is only available after AC_OUTPUT is handled. So _after_ all 
autoconf tests are performed.

How can I still perform my autoconf tests when libtool 2.0 comes out? 
Is there some way to generate the libtool 2.0 script before AC_OUTPUT? 
Is it otherwise possible to use some configure script variables in 
combination with ltmain.sh to perform my shared library specific 
AC_LINK_IFELSE check?

From a general perspective I also find it rather strange having the 
libtool script only available after AC_OUTPUT. It is like having CC (or 
any other necessary compiler/linker) only available after AC_OUTPUT. 
Since I am doing my compilation and linking with libtool, I would think 
it only logical that I would also be able to perform some autoconf 
tests with my compilation/linking tool.

Best regards,
Sander Niemeijer

___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Patch for Portland compiler support

[Jeff Squyres]

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: Using libtool 2.0 in autoconf tests

[Peter Ekberg]

Sander Niemeijer wrote:
> Hi,
> 
> I have send this question to the list about a month ago, but
> unfortunately, there hasn't been an answer yet, and the release of
> libtool 2.0 is not that far away (right?).
> 
> 
> 
> 
> I have some self written autoconf tests that check for linking shared
> libraries against some specific other libraries (these other libraries
> should be available as shared libraries or we might have a
> PIC problem.
> That is what my tests checks for). For this I had to create a variant
> of the AC_LINK_IFELSE macro that doesn't use CC/LD but the libtool
> script to perform the compilation/linking. With libtool 1.5.x the
> libtool script was nicely available, but with libtool 2.0 the libtool
> script is only available after AC_OUTPUT is handled. So _after_ all
> autoconf tests are performed. 
> 
> How can I still perform my autoconf tests when libtool 2.0 comes out?
> Is there some way to generate the libtool 2.0 script before AC_OUTPUT?
> Is it otherwise possible to use some configure script variables in
> combination with ltmain.sh to perform my shared library specific
> AC_LINK_IFELSE check? 
> 
>  From a general perspective I also find it rather strange having the
> libtool script only available after AC_OUTPUT. It is like
> having CC (or
> any other necessary compiler/linker) only available after AC_OUTPUT.
> Since I am doing my compilation and linking with libtool, I
> would think
> it only logical that I would also be able to perform some autoconf
> tests with my compilation/linking tool.

We have the same issue (for different reasons) in the GGI family of
libraries and I was eagerly waiting for an answer to your question.
I had forgotten about it though. I'm now writing to mention that
our workaround is an horrible hack that calls a second configure
script from inside the real configure script. The second configure
script (called genlibtool) has the sole purpose of generating the
libtool script. This is an horrible hack since it currently does
not solve all troubles (only some) resulting from two instances of
configure (albeit with different names) being active at the same
time. It also generates the libtool script twice which is a waste.

So, to sum it up, a possible horrible workaround and you are not
alone. Hope that at least makes you feel better...

http://www.ggi-project.org should have links to the source code if
you want to have a closer look at our "solution". The current
release candidate does not use the libtool-2-0 branch, so you have
to get the cvs version from sourceforge to see it.

Cheers,
Peter


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Wholes"ale Prices on Med`cine

[Lidia Lee]

Your favorite medcation --> 70% 0FF Sa1e (limitd. time only)

VlAGRA from $63
VALlUM from $70
AMBlEN from $66
ClALlS from $90
XANX from $77
+ MORE..

0RDER NOW & GET SHlPPlNG AT N0 C0ST
http://844.net.besentby.com


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Get Meds Prescription Directly

[Ernie Burch]

Your favorite medcation - 70% 0FF Sa1e (limitd. time only)

VlAGRA from $62
VAL1UM from $70
AMBlEN from $69
ClAL1S from $94
XANX from $71
+ M0RE..

0RDER NOW & GET SHIPPING AT N0 C0ST
http://823.net.besentby.com


___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TODO

[Gary V. Vaughan]

Bob Friesenhahn wrote:
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
It wouldn't be at all difficult to have 'libtoolize --ltdl 
--disable-nls' install a non-internationalised libltdl minus message 
catalogues into a parent package.  But yes, we would have to take care 
to do it carefully.  An improved post-2.0 testsuite should help there :-)
There are oodles of dangers here.  For example, a package distribution 
maintainer for a particular OS may not agree with the package 
developer's choices so he will install his own libltdl with the extra 
message catalogues.  This could make things very confusing/difficult for 
the package developer.   There is already plenty of confusion caused by 
package distribution maintainers who replace the existing libtool in a 
package with one that they prefer.
So you think it's a problem that (a) the project maintainer can choose 
to ship a non-internationalised libltdl with their project, and then
(b) a system integrator chooses to link against an internationalised
libltdl?

Any sensible project maintainer will ship i15d libltdl with their i15d
package, or non-i15d libltdl with their non-i15d package.  If some-one
chooses to mix and match, they are beyond our help!
If the project maintainer stupidly `libtoolize --ltdl --disable-nls'
installs libltdl in their i15d package, and a systems integrator chooses
to fix it by relibtoolizing --enable-nls to match the parent project,
that's a good thing.
If the integrator stupidly relibtoolized with a different option when
the project maintainer shipped the correct libltdl, he is beyond our 
help too.

On the flip side, the package developer may choose to distribute an 
internationalized libltdl, which causes new issues for end-users and 
package distribution maintainers.
I fail to see the problem... but it is 2am...
Cheers,
Gary.
--
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool 2.0 in autoconf tests

[Ralf Wildenhues]

* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET:
> 
> I have send this question to the list about a month ago, but 
> unfortunately, there hasn't been an answer yet, and the release of 
> libtool 2.0 is not that far away (right?).

Hmm.  We need to at least wait for the copyright issue to settle, I
guess.  Other than that, a cursory search of my mail archives of the
libtool lists show up on the order of 10-20 unresolved problems, yours
being one of them (might as well post a TODO list for 2.0).

It's good you bring it up again, it's an important problem from a user's
point of view.

> I have some self written autoconf tests that check for linking shared 
> libraries against some specific other libraries (these other libraries 
> should be available as shared libraries or we might have a PIC problem. 
> That is what my tests checks for). For this I had to create a variant 
*snip*

I agree with your view of things.  I think we should allow this to be
done.

Gary, you did the whole bootstrap reorganization.  Is anything close to
this possible?

Regards,
Ralf


___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool