Re: Trying to run 2.1a test suite

Hi Jeff, * Jeff Squyres wrote on Tue, Nov 23, 2004 at 08:12:43PM CET: > I'm working on the Portland Group compilers patch for both the libtool > CVS HEAD and the 1-5 branch (both are attached), and as suggested, am > trying to run the "make check" test suite against the CVS HEAD (it > passes on

RFC: proposal for indirect deplibs

This is a draft on how to proceed with the link_all_deplibs problem. The idea is to expose the complexity portably to the user. The rationale is that people get bitten by this complexity anyway, so there is little gain in hiding it. At the same time, systems without needed-following linker should

Re: RFC: proposal for indirect deplibs

Ralf Wildenhues <[EMAIL PROTECTED]> writes: [definitions] my head is already swimming because "dependent", "dependency" and "dependence" all are very subtly different and have different meanings in different contexts. i like the term "upstream" and "downstream" because a moment's thought in c

Re: RFC: proposal for indirect deplibs

* Thien-Thi Nguyen wrote on Wed, Nov 24, 2004 at 11:53:25AM CET: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > >[definitions] > > my head is already swimming because "dependent", "dependency" and > "dependence" all are very subtly different and have different > meanings in different context

Re: Trying to run 2.1a test suite

Ah -- excellent! I think someone said this ("work in the branch-2-0 branch"), but I ignored it and worked on the trunk because I foolishly assumed that they were effectively the same (note to self: your own development practices are not the same as everyone else's! ;-) ). On Nov 24, 2004, at 3

Patches for Portland Group (aka "pgi") compiler support

(I figured I'd start this in a different thread so that it would be easy to find when searching; the patches are identical to what I submitted before, but in the interest of tying this all up in one thread...) I've attached 2 patches to libtool.m4 -- one for branch-1-5 and one for branch-2-0 -

Re: Trying to run 2.1a test suite

* Jeff Squyres wrote on Wed, Nov 24, 2004 at 02:18:14PM CET: > Ah -- excellent! I think someone said this ("work in the branch-2-0 > branch"), but I ignored it and worked on the trunk because I foolishly > assumed that they were effectively the same We are in the process of rewriting the testsu

[support #100058] 1.4 - $buildir-path may not contain "~"

This mail is an automated notification from the support tracker of the project: GNU Libtool. /**/ [support #100058] Latest Modifications: Changes by: Peter O'Gorman <[EMAIL PROTECTED]> 'Date:

Re: [support #100058] 1.4 - $buildir-path may not contain "~"

Hi Peter, Not meaning to seem overly pedantic, but could you enumerate the release(s) you tested when you decided that it was safe to close this? Also, it seems like it would a good item to put into TODO (when you summarise the hideous TODO thread) that we should add a regression test to the new

cvs commit messages

Hi, I again managed to make a commit and forgot to do it properly (so no mail was sent to libtool-commits), so I filed a support request to get commit mails handled automatically again: Peter -- Peter O'Gorman - http://www.pogma.

Re: [support #100058] 1.4 - $buildir-path may not contain "~"

Gary V. Vaughan wrote: Hi Peter, Not meaning to seem overly pedantic, but could you enumerate the release(s) you tested when you decided that it was safe to close this? Also, it seems like it would a good item to put into TODO (when you summarise the hideous TODO thread) that we should add a regres

Re: [support #100058] 1.4 - $buildir-path may not contain "~"

Hi Peter! Peter O'Gorman wrote: > Gary V. Vaughan wrote: >> Not meaning to seem overly pedantic, but could you enumerate the >> release(s) you tested when you decided that it was safe to close this? > > I fixed this particular bug with: >

Re: cvs commit messages

Hi Peter, Peter O'Gorman wrote: > I again managed to make a commit and forgot to do it properly (so no > mail was sent to libtool-commits), so I filed a support request to get > commit mails handled automatically again: > Okay, th

[support #100058] 1.4 - $buildir-path may not contain "~"

This mail is an automated notification from the support tracker of the project: GNU Libtool. /**/ [support #100058] Latest Modifications: Changes by: Peter O'Gorman <[EMAIL PROTECTED]> 'Date:

FYI: Patches for Portland Group (aka "pgi") compiler support

* Jeff Squyres wrote on Wed, Nov 24, 2004 at 02:31:26PM CET: > (I figured I'd start this in a different thread so that it would be > easy to find when searching; the patches are identical to what I > submitted before, but in the interest of tying this all up in one > thread...) Good idea. > I'

Re: RFC: proposal for indirect deplibs

Ralf Wildenhues <[EMAIL PROTECTED]> writes: [definitions] Does that make more sense? yes thanks, i find "base" and "derived" easier to understand. What exactly do you mean with these terms? (I have a vague idea but would rather like to know a precise definition.) in trying to be mo

Re: RFC: proposal for indirect deplibs

On Wed, Nov 24, 2004 at 02:05:50PM +0100, Ralf Wildenhues wrote: > * Thien-Thi Nguyen wrote on Wed, Nov 24, 2004 at 11:53:25AM CET: > > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > >[definitions] > > > > my head is already swimming because "dependent", "dependency" and > > "dependence" a

Buy Cia'lis softtabs, 1 day s"ale

New ClALlS softtabs = lNSTANT R0CKHARD ERECTl0NS Simply disolve HALF A PlLL under your tongue 10min before action, for results that last all weekend. Normal retail is $19/PlLL 0rder from us today at the price of $3.33 not interested(0pt-0ut) ___ Libt

Relocatable libraries with libtool--can I do it?

Hi all. I'm having a severe problem with libtool-ized packages, of which there are more and more these days, in my environment. I'm wondering if anyone here can suggest how I should proceed; whether there's something in libtool that will help me, or whether libtool needs enhancements, or what. M

Re: RFC: proposal for indirect deplibs

On Wed, 24 Nov 2004, Ralf Wildenhues wrote: Definitions: direct dependency: A program or library has a direct dependency on a library, if it depends on some interface that library provides, see node Interfaces for a more thorough description. More classifications should applied for "direct dependen

Re: RFC: proposal for indirect deplibs

On Wed, Nov 24, 2004 at 07:47:54PM -0600, Bob Friesenhahn wrote: > On Wed, 24 Nov 2004, Ralf Wildenhues wrote: > >direct dependency: > >A program or library has a direct dependency on a library, if it depends > >on some interface that library provides, see node Interfaces for a more > >thorough des

Re: RFC: proposal for indirect deplibs

This is a great document. A few comments -- On Wed, Nov 24, 2004 at 02:05:50PM +0100, Ralf Wildenhues wrote: > needed-following linker: > A system with a needed-following linker has a means to record > dependencies on other libraries within a library (based on the soname of > the dependency libra