Reapply patch lost during recent "blind import" of libtool

Reapply patch lost during recent "blind import" of libtool

[Loren James Rittle]

[This message contains a patch (actually one that has been in the gcc
 source tree for many months), but it is going to the gcc mailing list
 with the listed CCs instead of gcc-patches at Gerald Pfeifer's
 request since it discusses SOP.]

Back around 2000-11-22, the following patch was submitted to
libtool-patches and gcc-patches before being applied to the gcc source
tree.  It was approved by multiple gcc maintainers and, at least in
principle, our libtool liaison (as I was led to believe was the proper
method yet it was never applied to the libtool source tree):

	http://gcc.gnu.org/ml/libstdc++/2000-11/msg00225.html
	http://gcc.gnu.org/ml/libstdc++/2000-11/msg00340.html

During the recent libtool merge (2001-03-22), which was done using the
"blind import" method allowed by GCC steering committee SOP, it was lost.

The reapplication of this trivial patch to the gcc source tree has
been pre-approved by Gerald Pfeifer.  I will resubmit it to
libtool-patches under separate cover.  It was tested on both mainline
and 3.0 (it is a clear regression from 2.95.X) and is confined to
configure code which only affects *-*-freebsd*.

I want to be completely clear: I do not blame Alexandre Oliva, the
person that updated our copy of libtool, for this situation.  I may
not have stressed in my postings to libtool-patches that this patch
was approved for use in the gcc tree and that it should go in the
official libtool source tree.

However, I do blame our policy of allowing "blind imports" of external
tools to our CVS tree.  At the very least, we should be using CVS
vendor tags to properly roll in external updates.  This would at least
allow the importer to easily produce a report of local patches that
accumulated in the gcc tree that were just blown away by the upgrade.
And it would force people to reconsider how/why they were dropped from
the official distribution of the tool which gcc depends upon.  As it
stands, it took me a while to even understand that my port developed a
problem (I randomly noticed that libstdc++.so was no longer being
built and installed and that an old installed version was being used).

Regards,
Loren

2001-04-10  Loren J. Rittle  <ljrittle@acm.org>

	* ltcf-cxx.sh: Support creation of C++ shared libraries on
	recent versions of FreeBSD (release 3 or later).
	* ltconfig: On FreeBSD, -lc must not be provided when building
	a shared library or else the standard -pthread gcc option is
	rendered worthless to later users of the built library.

Index: ltconfig
===================================================================
RCS file: /cvs/gcc/egcs/ltconfig,v
retrieving revision 1.16
diff -c -r1.16 ltconfig
*** ltconfig	2001/03/22 06:48:31	1.16
--- ltconfig	2001/04/11 03:40:43
***************
*** 1108,1113 ****
--- 1108,1114 ----
      freebsd-elf*)
        library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so $libname.so'
        need_version=no
+       need_lc=no
        need_lib_prefix=no
        ;;
      freebsd-*)
Index: ltcf-cxx.sh
===================================================================
RCS file: /cvs/gcc/egcs/ltcf-cxx.sh,v
retrieving revision 1.14
diff -c -r1.14 ltcf-cxx.sh
*** ltcf-cxx.sh	2001/03/22 18:13:39	1.14
--- ltcf-cxx.sh	2001/04/11 03:40:43
***************
*** 233,242 ****
          ;;
      esac
      ;;
!   freebsd*)
!     # FreeBSD uses GNU C++ and GNU ld
!     # FIXME: insert proper C++ library support
      ld_shlibs=no
      ;;
    hpux*)
      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
--- 233,246 ----
          ;;
      esac
      ;;
!   freebsd[12]*)
!     # C++ shared libraries reported to be fairly broken before switch to ELF
      ld_shlibs=no
+     ;;
+   freebsd*)
+     # FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
+     # conventions
+     ld_shlibs=yes
      ;;
    hpux*)
      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Loren" == Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

    Loren> However, I do blame our policy of allowing "blind imports"

I don't know that we have such a policy, except for a few things (like
config.guess) that are never changed in the GCC tree itself.

I agree with you that we shouldn't be doing blind imports in general.

In this particular case, I would have much preferred that the libtool
upgrade be done using the usual cvs/rcs merge techniques, rather than
simply the "blind import" method.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On Apr 11, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Loren" == Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
Loren> However, I do blame our policy of allowing "blind imports"

> I don't know that we have such a policy, except for a few things (like
> config.guess) that are never changed in the GCC tree itself.

> I agree with you that we shouldn't be doing blind imports in general.

> In this particular case, I would have much preferred that the libtool
> upgrade be done using the usual cvs/rcs merge techniques, rather than
> simply the "blind import" method.

I'd much rather have local annotations of GCC-local changes, if
they're at all needed.  I did look for such marks before importing the
new version of libtool, and found none.

I'll check in Loren's patch in the libtool tree, and then update the
copy of these files in the GCC version, from the libtool CVS tree.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> I'd much rather have local annotations of GCC-local
    Alexandre> changes, if they're at all needed.  I did look for such

Why put markers in the source?  

We have CVS to keep track of these kinds of things -- that's what tags
and vendor branches are for.

Even now, I would suggest importing the most recent version of libtool
into our repository just so that the next time we do this all it takes
is something like:

  cvs update -j -r libtool_1_0 -r libtool_2_0 

to get the changes.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On Apr 11, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> I'd much rather have local annotations of GCC-local
Alexandre> changes, if they're at all needed.  I did look for such

> Why put markers in the source?  

At the very least, so that someone who gets these files knows it's not
a pristine release of libtool, but something modified for GCC.  In a
perfect world, we'd never need to modify files in the GCC tree: we'd
just get patches installed in the libtool CVS tree and merged here.
I'm trying to keep this part of the world as perfect as possible.

In any case, whenever there are local changes to libtool files, at the
very least the version number should be modified.  Against my advice,
it never was.

> We have CVS to keep track of these kinds of things -- that's what tags
> and vendor branches are for.

I know very well how to deal with CVS for these things.  I also know
very well how much time I lose every time I import a new version of
libtool into other CVS repos, just to fix the merge conflicts, that
shouldn't even be there in the first place, but that somehow show up.
I don't want to waste that much time with libtool in GCC.  It's not
necessary.  We just don't need local changes.  We need to make sure
fixes get propagated upstream.  I'm willing to no longer accept
patches for the local copies of these files.  That's exactly what we
do with config.guess and config.sub.  Why should the libtool files be
any different?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> copies of these files.  That's exactly what we do with
    Alexandre> config.guess and config.sub.  Why should the libtool
    Alexandre> files be any different?

That's a fine policy -- as long as a) libtool works well as is, or b)
the changes we need are quickly propogated into the main repository
and back to us.

This hasn't been a problem with config.guess because the software
works well and requires many fewer changes than libtool has of late.
Basically all that every happens in config.guess is that is that a new
architecture appears.

In contrast, with libtool, some of us have had to make substantial
changes in extremely complex shell scripts, partly because quick
action from the libtool maintainers was not forthcoming.  And, by some
people's accounts, some parts of libtool do not yet fully support the
various architectures GCC targets.

In summary, I think that treating libtool as a read-only part of GCC
is a good idea, if it is practical.  A large part of that depends on
the libtool maintainers acting quickly to solve problems experienced
in GCC.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On Apr 11, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> That's a fine policy -- as long as a) libtool works well as is, or b)
> the changes we need are quickly propogated into the main repository
> and back to us.

I take the blame for not having been able to keep up with the few
patches submitted to libtool that I have approved for the GCC CVS
tree.  That was a mistake I'm not going to repeat.  I'll only approve
patches for libtool files in GCC after they're checked in in the
libtool CVS tree too, so that a newer version doesn't get changes
reverted, and so that users will be free to take whatever other
(newer) versions of libtool work for them and replace them in the GCC
tree.

> In summary, I think that treating libtool as a read-only part of GCC
> is a good idea, if it is practical.  A large part of that depends on
> the libtool maintainers acting quickly to solve problems experienced
> in GCC.

Yep.  Fortunately, one of the libtool maintainers also happens to be
one of the GCC configury maintainers :-)

Is there any place where we can document that patches for libtool
files should not be checked in in the GCC tree before being installed
in the libtool CVS tree, even when they come from people with global
write privs?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> Is there any place where we can document that patches
    Alexandre> for libtool files should not be checked in in the GCC
    Alexandre> tree before being installed in the libtool CVS tree,
    Alexandre> even when they come from people with global write
    Alexandre> privs?

Well, we can ask Gerald nicely to put it someplace on the web site,
near the coding standards. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" oflibtool

[Robert Boehne]

Mark Mitchell wrote:
> 
> >>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
> 
>     Alexandre> Is there any place where we can document that patches
>     Alexandre> for libtool files should not be checked in in the GCC
>     Alexandre> tree before being installed in the libtool CVS tree,
>     Alexandre> even when they come from people with global write
>     Alexandre> privs?
> 
> Well, we can ask Gerald nicely to put it someplace on the web site,
> near the coding standards. :-)
> 

This situation would be a little easier for Libtool maintainers
if patches for 'ltconfig.in' were made, rather than 'ltconfig'.
I don't think that tags are much of a solution, I agree that
these patches should be installed in Libtool's cvs first.
I'll try to help Alexandre out with that.

Robert

-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne@ricardo-us.com

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On Apr 11, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> Is there any place where we can document that patches
Alexandre> for libtool files should not be checked in in the GCC
Alexandre> tree before being installed in the libtool CVS tree,
Alexandre> even when they come from people with global write
Alexandre> privs?

> Well, we can ask Gerald nicely to put it someplace on the web site,
> near the coding standards. :-)

Well, if folks agree with this policy, I'd be happy to post a patch
myself :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> Well, if folks agree with this policy, I'd be happy to
    Alexandre> post a patch myself :-)

Do it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On Apr 12, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> Well, if folks agree with this policy, I'd be happy to
Alexandre> post a patch myself :-)

> Do it.

Yes, sir! :-)

Ok to install?

Re: Reapply patch lost during recent "blind import" of libtool

[Loren James Rittle]

Alexandre> Is there any place where we can document that patches
Alexandre> for libtool files should not be checked in in the GCC
Alexandre> tree before being installed in the libtool CVS tree,
Alexandre> even when they come from people with global write
Alexandre> privs?

> Well, if folks agree with this policy, I'd be happy to post a patch
> myself :-)

I am happy with your proposed change in policy.  I am also ACKing that
I read < orzodmaevt.fsf@guarana.lsd.ic.unicamp.br >, the message with
the actual documentation patch.

In addition to any English description, a good place to document this
policy might be in CVSROOT/commitinfo and a supporting script script.
We could write a simple rule in commitinfo to help enforce this policy
and the existing policy which covers config.guess (this example could
be extended to handle other special cases mentioned in your policy
documentation patch):

/cvs/gcc/.* true
/cvs/gcc check-import

Here is a sample check-import:

#!/bin/sh

W1="WARNING: This file should be upgraded from the related external"
W2="WARNING: master source repository using 'cvs import'."
W3="WARNING: See http://gcc.gnu.org/codingconventions.html for details."

shift; for i in $*; do case $i in
  config.guess) echo $W1; echo $W2; echo $W3; exit 1;;
  config.sub) echo $W1; echo $W2; echo $W3; exit 1;;
  ltconfig) echo $W1; echo $W2; echo $W3; exit 1;;
  ltmain.sh) echo $W1; echo $W2; echo $W3; exit 1;;
  libtool.m4) echo $W1; echo $W2; echo $W3; exit 1;;
  ltcf-*.sh) echo $W1; echo $W2; echo $W3; exit 1;;
esac; done

Here is the sample session using this approach (I set this up locally,
but used client/server CVS to ensure it would work the same remotely
to gcc.gnu.org):

; cvs ci -m '' ltconfig 
WARNING: This file should be upgraded from the related external
cvs server: Pre-commit check failed
WARNING: master source repository using 'cvs import'.
WARNING: See http://gcc.gnu.org/codingconventions.html for details.
cvs [server aborted]: correct above errors first!

Here is a correct way to use CVS vendor branches with the above policy
rules (this example for libtool only, but config.guess, etc should be
similar):

1. Create an empty directory (i.e. do not work in a checked-out CVS
   working tree).  Populate it with upgraded libtool files taken from
   the master repository on subversion.gnu.org.

2. Run: cvs import /cvs/gcc SUBVERSION LIBTOOL_RELEASE_NUMBER
   within the directory populated in step 1.

3. Ignore any merge warnings the first time this is done.

4. Run: cvs admin -bSUBVERSION ltconfig ltmain.sh libtool.m4 ltcf-*.sh
   at the top level of a checked-out CVS working tree.

http://gcc.gnu.org/cvswrite.html says that:

``Maintainers are free to import files maintained outside the tree from
  their official versions without explicit write approval. Such files
  would include config.guess and config.sub.''

It appears that the usage of the word import in that context was not
taken literally as in ``cvs import'' since I see all changes on
config.guess were brought in via the standard `cvs ci'' mechanism.
The same is true of libtool.  One begins to see why merging in from
external sources is reported to be such a pain. ;-)

Now, I don't want to discount an important point that was indirectly
raised by Robert Boehne.  The gcc source tree is only using a
"post-processed" version of libtool thus it might not be appropriate
to ever allow local changes, but that fact does not discount the value
of using CVS vendor branches properly in conjunction with a commitinfo
script to help watch for mistakes.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Re: Reapply patch lost during recent "blind import" oflibtool

[Loren James Rittle]

In article < 3AD4FDC6.46C6DEA0@ricardo-us.com >,
Robert Boehne <rboehne@ricardo-us.com> writes:

> This situation would be a little easier for Libtool maintainers
> if patches for 'ltconfig.in' were made, rather than 'ltconfig'.

Robert, you have added some very good information to the mix.
In fact, here is what I immediately thought upon reading above:

  Yikes!  I didn't even know there was an ltconfig.in.  In the gcc
  source tree, we only have ltconfig.  ltconfig makes no mention that
  it is generated from another file thus I didn't even know I was
  making life hard for libtool maintainers when I sent patches against
  ltconfig.

> I don't think that tags are much of a solution, I agree that
> these patches should be installed in Libtool's cvs first.
> I'll try to help Alexandre out with that.

In light of the fact that the gcc source tree doesn't contain primary
libtool files, I see your point.  However, we should still consider
tracking libtool and other external sources in the gcc source tree via
vendor branches instead of plain checkins.

Regards,
Loren

Re: Reapply patch lost during recent "blind import" oflibtool

[Alexandre Oliva]

On Apr 12, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

>   Yikes!  I didn't even know there was an ltconfig.in.  In the gcc
>   source tree, we only have ltconfig.  ltconfig makes no mention that
>   it is generated from another file thus I didn't even know I was
>   making life hard for libtool maintainers when I sent patches against
>   ltconfig.

It's not as bad as it seems.  ltconfig differs from ltconfig.in
basically only in the fact that it gains a version number and a
timestamp, and line numbers in #line directives of here-documents are
fixed up.  Similarly for ltmain.sh and ltmain.in.

This is likely to change in the future.  It's very likely that
ltconfig.in, and all of ltcf-*.sh, will be folded into libtool.m4, and
that ltmain.in will be rewritten in some macro-processing language
(AutoGen or autoconf 2.50's m4sh).

> However, we should still consider tracking libtool and other
> external sources in the gcc source tree via vendor branches instead
> of plain checkins.

I don't have a strong opinion about this.  At first, I like the idea
of enforcing import-only updates.  On the other, it would seem to
prevent temporary work-arounds for problems, whenever the maintainers
of libtool become unresponsive.  Well, one can always import files
that consist solely of a single patch, instead of a full import, so we
don't really lose any abilities, whereas we gain warnings for those
who don't know about the rules.

Yeah, the more I think about this, the more I like it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" of libtool

[Gerald Pfeifer]

On 12 Apr 2001, Alexandre Oliva wrote:
> Ok to install?

Yes, thanks a lot!  (Only some most minor tweaks.)

+Some files and packages in the CVS tree are imported from elsewhere,
+and we want to minimize divergence from their upstream sources.  The
+following files should be updated only according to the rules set
+below:

This should be put in <p>Some...below:</p>

+<li>config.guess, config.sub: The master copy of these files is at <a
+href=" ftp://ftp.gnu.org/pub/gnu/config/" ;> ftp://ftp.gnu.org/pub/gnu/config </a>.
+Proposed changes should be e-mailed to <a
+href=" mailto:config-patches@gnu.org" ;>config-patches@gnu.org</a>.  Only
+after the change makes it to the FTP site should the new files be
+installed in the GCC CVS tree, so that their version numbers remain
+meaningful and unique.  Don't install the patch, install the whole
+file.

Here, and in the following, please close the list item with </li>.

Your patch adds very useful documentation!

Thanks,
Gerald

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> On Apr 12, 2001, Mark Mitchell <mark@codesourcery.com>
    Alexandre> wrote:

    >>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
    Alexandre> Well, if folks agree with this policy, I'd be happy to
    Alexandre> post a patch myself :-)

    >> Do it.

    Alexandre> Yes, sir! :-)

    Alexandre> Ok to install?

Yes, thanks.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" oflibtool

[Gerald Pfeifer]

On Thu, 12 Apr 2001, Loren James Rittle wrote:
> In addition to any English description, a good place to document this
> policy might be in CVSROOT/commitinfo and a supporting script script.
> We could write a simple rule in commitinfo to help enforce this policy
> and the existing policy which covers config.guess (this example could
> be extended to handle other special cases mentioned in your policy
> documentation patch):
>
> /cvs/gcc/.* true
> /cvs/gcc check-import
>
> Here is a sample check-import:
>
> #!/bin/sh
>
> W1="WARNING: This file should be upgraded from the related external"
> W2="WARNING: master source repository using 'cvs import'."
> W3="WARNING: See http://gcc.gnu.org/codingconventions.html for details."
>
> shift; for i in $*; do case $i in
>   config.guess) echo $W1; echo $W2; echo $W3; exit 1;;
>   config.sub) echo $W1; echo $W2; echo $W3; exit 1;;
>   ltconfig) echo $W1; echo $W2; echo $W3; exit 1;;
>   ltmain.sh) echo $W1; echo $W2; echo $W3; exit 1;;
>   libtool.m4) echo $W1; echo $W2; echo $W3; exit 1;;
>   ltcf-*.sh) echo $W1; echo $W2; echo $W3; exit 1;;
> esac; done


On 12 Apr 2001, Alexandre Oliva wrote:
> I don't have a strong opinion about this.  At first, I like the idea
> of enforcing import-only updates.  On the other, it would seem to
> prevent temporary work-arounds for problems, whenever the maintainers
> of libtool become unresponsive.  Well, one can always import files
> that consist solely of a single patch, instead of a full import, so we
> don't really lose any abilities, whereas we gain warnings for those
> who don't know about the rules.
>
> Yeah, the more I think about this, the more I like it.

So, how about setting up Loren's script?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Reapply patch lost during recent "blind import" oflibtool

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    >> Yeah, the more I think about this, the more I like it.

    Gerald> So, how about setting up Loren's script?

If the script only issues a warning message to the person who did the
check-in (and to `gcc@gcc.gnu.org'?) that's good.  If it actually
prevents the check-in, I think that's too strong.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Reapply patch lost during recent "blind import" of libtool

[Loren James Rittle]

In article < 20010511115318C.mitchell@codesourcery.com >,
Mark Mitchell <mark@codesourcery.com> writes:

>>> Yeah, the more I think about this, the more I like it.

Gerald> So, how about setting up Loren's script?

> If the script only issues a warning message to the person who did the
> check-in (and to `gcc@gcc.gnu.org'?) that's good.  If it actually
> prevents the check-in, I think that's too strong.

As posted, the script prevented check-in since import was the
documented way to update those files.  However, it is easy to change
the behavior by using 'exit 0' instead of 'exit 1'.

I would be happy to submit a final version of that approach using
Mark's feedback, if that is desired.

Loren

Re: Reapply patch lost during recent "blind import" of libtool

[Gerald Pfeifer]

On Fri, 11 May 2001, Loren James Rittle wrote:
> I would be happy to submit a final version of that approach using
> Mark's feedback, if that is desired.

It is. ;-)

Mark wrote "that's good" and I like it as well, plus also Alexandre
seems to be in favor of the principal approach you suggested, so let's
go for it.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On May 11, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

> In article < 20010511115318C.mitchell@codesourcery.com >,
> Mark Mitchell <mark@codesourcery.com> writes:

>>>> Yeah, the more I think about this, the more I like it.

Gerald> So, how about setting up Loren's script?

>> If the script only issues a warning message to the person who did the
>> check-in (and to `gcc@gcc.gnu.org'?) that's good.  If it actually
>> prevents the check-in, I think that's too strong.

> As posted, the script prevented check-in since import was the
> documented way to update those files.

Besides, it's easy enough to do an import instead of a check-in.  But
I understand it might be more convenient to be able to just check-in.
But then, when you got the warning, it would be too late already.
Could the exit status of the script depend on some command-line
argument given to cvs commit?

Another alternative I like is to get the commit script to test the
version numbers, at least in ltconfig and ltmain.sh, and make sure
they're modified between the existing version and the one about to be
committed, and, if they don't differ, issue a hard error.  This would
guarantee that locally-modified files are clearly marked as such.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" of libtool

[Loren James Rittle]

In article < orvgn7tngx.fsf@guarana.lsd.ic.unicamp.br >,
Alexandre Oliva <aoliva@redhat.com> writes:

>>> If the script only issues a warning message to the person who did the
>>> check-in (and to `gcc@gcc.gnu.org'?) that's good.  If it actually
>>> prevents the check-in, I think that's too strong.

>> As posted, the script prevented check-in since import was the
>> documented way to update those files.

> Besides, it's easy enough to do an import instead of a check-in.  

Yes, imports are never checked.  So someone trying to cheat the rules
can *always* import.  Is it OK for the checker script to make commits
on some files fail, if it is made clear how to use import to cheat the
system?

> But I understand it might be more convenient to be able to just
> check-in.  But then, when you got the warning, it would be too late
> already.

If it isn't a little painful to circumvent the correct process, I feel
we are right back where we were before attempting to improve the
status quo.

> Could the exit status of the script depend on some
> command-line argument given to cvs commit?

Unfortunately, under CVS, the filter that checks commits does not get
any client-provided arguments.

> Another alternative I like is to get the commit script to test the
> version numbers, at least in ltconfig and ltmain.sh, and make sure
> they're modified between the existing version and the one about to be
> committed, and, if they don't differ, issue a hard error.  This would
> guarantee that locally-modified files are clearly marked as such.

I can see why you want that, but that is a tad harder to do I am
afraid.  The commitinfo script has direct access to the names of files
to be changed and indirect access to the contents of the files to be
changed.  I don't know that one can legally run 'cvs update
-rUNKNOWN-WHAT-GOES-HERE -p' to get a copy of the file to compare against.

Regards,
Loren

Re: Reapply patch lost during recent "blind import" of libtool

[Alexandre Oliva]

On May 11, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

> I don't know that one can legally run 'cvs update
> -rUNKNOWN-WHAT-GOES-HERE -p' to get a copy of the file to compare
> against.

Yeah, I feared that much.  I guess we can live without this check.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Reapply patch lost during recent "blind import" of libtool

[Fergus Henderson]

On 11-May-2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:
> > Could the exit status of the script depend on some
> > command-line argument given to cvs commit?
> 
> Unfortunately, under CVS, the filter that checks commits does not get
> any client-provided arguments.

If the client is connecting via ssh, as is normally (always?) the case
for the GCC cvs server, and it propagates X connections, which I think
is currently NOT the case for the GCC cvs server, then it's possible to
use that to open a window on the client's X server to ask the user
whether they want to commit anyway.  See the Perl subroutine below.
(I think this code doesn't actually work correctly, but hopefully
it is sufficient to demonstrate the concept.)

I'm not sure what security risks there would be with allowing ssh to
propagate X connections.

> > Another alternative I like is to get the commit script to test the
> > version numbers, at least in ltconfig and ltmain.sh, and make sure
> > they're modified between the existing version and the one about to be
> > committed, and, if they don't differ, issue a hard error.  This would
> > guarantee that locally-modified files are clearly marked as such.
> 
> I can see why you want that, but that is a tad harder to do I am
> afraid.  The commitinfo script has direct access to the names of files
> to be changed and indirect access to the contents of the files to be
> changed.  I don't know that one can legally run 'cvs update
> -rUNKNOWN-WHAT-GOES-HERE -p' to get a copy of the file to compare against.

Yes, doing that might deadlock.
However, if you use `cvs -n update', I think it should be OK.
Of course, that still leaves the problem of filling in
"UNKNOWN-WHAT-GOES-HERE".

----------

# returns non-zero if commit should go ahead
sub check_if_user_wants_to_force_commit {
	if (open TTY, "/dev/tty") {
		print "Commit anyway? [n] ";
		if (<TTY> =~ /^y/i) {
			return 1;
		} else {
			return 0;
		}
	} else {
		my $file = shift(@_);
		my $result;
		my $have_X_display = $ENV{DISPLAY} ne "";

		if (! $already_remote) {
			#
			# If this is the first time through, we have a few
			# extra things to do and say.
			#

			$already_remote = 1;

			# We don't want the output to be (block) buffered
			$| = 1;

			print "\nCan't read from your terminal --- "
				. "you appear to be using remote CVS.\n";

			if ($have_X_display) {
				print "Trying X connection to "
					. "$ENV{DISPLAY}.\n\n";
			} else {
				print "You have no DISPLAY environment "
					. "variable set so I don't know\n"
					. "how to interact with you.  "
					. "Sorry.\n\n";
			}
		}

		return 0 unless $have_X_display;

		#
		# Try interacting with the user via X.  This probably only
		# works when connecting via something such as ssh which
		# redirects X connections back to their origin.
		#

		$result = system "xmessage", "-buttons", "yes:0,no:1",
				"Problem with `$file'.  Commit anyway?";
		$errcode = $result & 0xff;
		$exitval = $result >> 8;
		if ($errcode == 0 && ($exitval == 0 || $exitval == 1)) {
			return ! $exitval;
		} else {
			print "Error running `xmessage', sorry.\n";
			print "(Result code = ", $result, ")\n";
			return 0;
		}
	}
}

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: Reapply patch lost during recent "blind import" of libtool

[Joern Rennecke]

> I'm not sure what security risks there would be with allowing ssh to
> propagate X connections.

Better not go down this path.  What about the commit log?  Is that passed
to the commit checker?  Then the user can put a 'magic' keyword there.
E.g. like some shutdown scripts - give a reason why you really want this.

> > > Another alternative I like is to get the commit script to test the
> > > version numbers, at least in ltconfig and ltmain.sh, and make sure
...
> Yes, doing that might deadlock.
> However, if you use `cvs -n update', I think it should be OK.
> Of course, that still leaves the problem of filling in
> "UNKNOWN-WHAT-GOES-HERE".

How about just keeping the last version of ltconfig / ltmain.sh around on
the host that does the checking?