Re: Call for help: Solaris C++ and Sun CC

2005-08-26 Thread Tim Mooney

In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...:


These two threads contain the patches recently applied to fix the
failure with undefined symbols on Solaris with CC (Sun C++ compiler):


http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html
http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html



I've never (manually) created these links or the links for libiostream.


The system I tested on does not have above unversioned symlinks, and so
links against a libCstd.a with PIC objects.  Obviously, the libbaz.so
created by the 'tagdemo-shared tagdemo-make' tests then has half of
libCstd contained in it.  Having this huge lib is both uncomfortable and
dangerous: when you start linking against several C++ libraries, you can
end up with all sorts of very subtle problems.

Then I found this documentation.  Now I'm unsure whether we should guard
against this issue (I'd like to), but more importantly: I don't know how
we _can_ guard against it easily.


If I'm following that thread correctly, the original problem (needing
-lCstd -lCrun -lc for C++) is fixed with Peter's patch and your subsequent
fixups.  The new issue is that at least Cstd and probably Crun will be
linked statically if the admin hasn't added the symlinks in the
appropriate place.

While I agree in principle that it would be nice for libtool to help
people avoid shooting themselves in the foot, I think in this case it's
more important to document the danger than it is to completely mitigate
it.  I say this primarily because there might be quite a lot of work to
actually get libtool to protect the user.

A comment in the docs and likely also in the Solaris C++ section of the
code would be "good enough", I think, unless someone comes up with an easy
way to guard against the issue.

I suppose the test could be special-cased for Solaris, and ldd or some
other tool used after linking to verify that a library we're expecting
would show up on the list of NEEDED shared libraries, but that seems
like a lot of work.

Tim
--
Tim Mooney  [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building  (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: CVS branch-2-0 R.I.P.

2005-08-26 Thread Gary V. Vaughan

Hi Albert,

On 26 Aug 2005, at 16:38, Albert Chin wrote:

On Fri, Aug 26, 2005 at 04:26:57PM +0200, Ralf Wildenhues wrote:

* Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST:

What is the requirements on the autotools for a libtoolized
package from HEAD? I heard a rumor that cvs versions were
required, at least at some point, is that really the case
or was it just a rumor?


At the moment they are required after a cvs checkout of Libtool  
HEAD for

building itself.


When will HEAD be able to bootstrap with the latest released
autoconf/automake?


Just as soon as autoconf and automake put out new releases ;-)

But really, we would have to back out a lot of patches from libtool
HEAD (including another major reorganisation of the source tree)
to make that work.  And the whole point of dropping branch-2-0
is to bring a 2.0 release closer.  The 3 patches I attached to an
earlier mail are not too onerous.  With those applied to autoconf-2.59
and automake-1.9.6, you can bootstrap right now.

Cheers,
Gary.
--
Gary V. Vaughan  ())_.  gary@ 
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]

Research Scientist   ( '/   http://www.tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/{libtool,m4}
Technical Author   `(_~)_   http://sources.redhat.com/autobook




PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool


Re: CVS branch-2-0 R.I.P.

2005-08-26 Thread Albert Chin
On Fri, Aug 26, 2005 at 04:26:57PM +0200, Ralf Wildenhues wrote:
> * Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST:
> > 
> > What is the requirements on the autotools for a libtoolized
> > package from HEAD? I heard a rumor that cvs versions were
> > required, at least at some point, is that really the case
> > or was it just a rumor?
> 
> At the moment they are required after a cvs checkout of Libtool HEAD for
> building itself.

When will HEAD be able to bootstrap with the latest released
autoconf/automake?

-- 
albert chin ([EMAIL PROTECTED])


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: CVS branch-2-0 R.I.P.

2005-08-26 Thread Gary V. Vaughan

Hi Peter,

On 26 Aug 2005, at 15:06, Peter Ekberg wrote:

Gary V. Vaughan wrote:

Unless someone yells to the contrary real soon
now, I see no reason to continue to maintain branch-2-0 from
here on in.


What is the requirements on the autotools for a libtoolized
package from HEAD? I heard a rumor that cvs versions were
required, at least at some point, is that really the case
or was it just a rumor?


I've just successfully run 'make distcheck' on current libtool
HEAD on darwin, using very lightly patch autoconf-2.59, and
automake-1.9.6 (patches attached).  The resulting libtool
tarball should be installable and useable with considerably
older versions of the other autotools (there is a small series
of automake CVS revisions that won't work, but no released
versions... except possibly the extremely ancient).


I can personally live with that the person doing the actual
libtoolize needs cvs-autotools, but the rest of the
developers on the package should not be required to use
cvs-autotools.


Agreed.  Infact, apart from those of us bootstrapping a libtool
release, it is a bug for an installed released libtool (including
libtoolize) to require non-released autotools.

Cheers,
Gary.
--  
Gary V. Vaughan  ())_.  gary@ 
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]

Research Scientist   ( '/   http://www.tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/{libtool,m4}
Technical Author   `(_~)_   http://sources.redhat.com/autobook


autoconf-2.59--patch-1--honour-libobj-dir.patch
Description: Binary data


autoconf-2.59--patch-2--darwin-fortran-crt2-fix.patch
Description: Binary data


automake-1.9.6--patch-1--honour-libobj-dir.patch
Description: Binary data





PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool


Re: CVS branch-2-0 R.I.P.

2005-08-26 Thread Ralf Wildenhues
* Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST:
> 
> What is the requirements on the autotools for a libtoolized
> package from HEAD? I heard a rumor that cvs versions were
> required, at least at some point, is that really the case
> or was it just a rumor?

At the moment they are required after a cvs checkout of Libtool HEAD for
building itself.

Packages libtoolized with CVS Libtool do not need CVS Automake/Autoconf.
Packages `libtoolize -ldtl'ed with CVS Libtool /might/ at the moment
need CVS Autotools, but I am not sure.

Any of the restrictions mentioned in the former paragraph must and will
be removed before a stable release.  But that will most likely happen
after removing all other regressions are fixed and the branch point is
created.

And yes, we plan on testing all of this before the release.

> I can personally live with that the person doing the actual
> libtoolize needs cvs-autotools, but the rest of the
> developers on the package should not be required to use
> cvs-autotools.

Neither of them should need this.  Not even people working on the
release branch of Libtool.  Rationale: Libtool is a user of libltdl
and should work similar to other users of libltdl.  If that use needs
CVS Autotools, other packages that use libltdl most likely do, too.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool


RE: CVS branch-2-0 R.I.P.

2005-08-26 Thread Peter Ekberg
Gary V. Vaughan wrote:
> Sent: Friday, August 26, 2005 14:10
> To: Libtool
> Subject: CVS branch-2-0 R.I.P.
> 
> Fellow Libtoolers (if you're reading, that means you!),
> 
> I still have reservations, but am otherwise somewhat convinced that
> dropping development of branch-2-0 in favour of HEAD is a reasonable  
> thing
> to do at this juncture.  Unless someone yells to the contrary 
> real soon
> now, I see no reason to continue to maintain branch-2-0 from 
> here on in.
> 
> In due course, I think it is fine to release 2.0 from HEAD (or a new
> release branch from future trunk HEAD to be precise) even with known
> minor bugs, provided that we list them in the release 
> announcement.  In
> order to speed the release, and in the spirit  of "release early,  
> release
> often", I say we identify the actual showstoppers, and 
> release 1.9h from
> HEAD with just those fixed.  There is a list of showstoppers 
> on my wiki
> at http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap.
> 
> If 1.9h is well received, I believe we should release 2.0 soon after
> (minor bugs and all), and then work on the remaining regressions for a
> quick 2.0.2.  In order to prevent any further slippage, until 2.0.2 is
> out there we should reject all patches, and commit changes only for:
> 
>   - bugs
>   - regressions
>   - documentation
>   - testsuite improvements
>   - and maybe MSVC support, iff we can confine changes to this system.
> 
> Speak now, or forever hold your peace.

What is the requirements on the autotools for a libtoolized
package from HEAD? I heard a rumor that cvs versions were
required, at least at some point, is that really the case
or was it just a rumor?

I can personally live with that the person doing the actual
libtoolize needs cvs-autotools, but the rest of the
developers on the package should not be required to use
cvs-autotools.

Cheers,
Peter


___
http://lists.gnu.org/mailman/listinfo/libtool


CVS branch-2-0 R.I.P.

2005-08-26 Thread Gary V. Vaughan

Fellow Libtoolers (if you're reading, that means you!),

I still have reservations, but am otherwise somewhat convinced that
dropping development of branch-2-0 in favour of HEAD is a reasonable  
thing

to do at this juncture.  Unless someone yells to the contrary real soon
now, I see no reason to continue to maintain branch-2-0 from here on in.

In due course, I think it is fine to release 2.0 from HEAD (or a new
release branch from future trunk HEAD to be precise) even with known
minor bugs, provided that we list them in the release announcement.  In
order to speed the release, and in the spirit  of "release early,  
release

often", I say we identify the actual showstoppers, and release 1.9h from
HEAD with just those fixed.  There is a list of showstoppers on my wiki
at http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap.

If 1.9h is well received, I believe we should release 2.0 soon after
(minor bugs and all), and then work on the remaining regressions for a
quick 2.0.2.  In order to prevent any further slippage, until 2.0.2 is
out there we should reject all patches, and commit changes only for:

 - bugs
 - regressions
 - documentation
 - testsuite improvements
 - and maybe MSVC support, iff we can confine changes to this system.

Speak now, or forever hold your peace.

Cheers,
Gary.
--
Gary V. Vaughan  ())_.  gary@ 
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]

Research Scientist   ( '/   http://www.tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/{libtool,m4}
Technical Author   `(_~)_   http://sources.redhat.com/autobook





PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool