bug#1191: How to contribute back changes for Emacs on Solaris

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

This message is a follow up to one I sent to emacs-devel
last July:

	http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html

The question had to do with why emacs wasn't using dldump()
to produce the dumped executable under Solaris. It had been using it
up until 2002, at which point it was commented out, and it wasn't
clear why. No one knew the reason, and the consensus was "try it and see".

Since then, I've done some work to integrate emacs with
OpenSolaris as a standard package. I turned on dldump(),
and have been using the emacs binaries built with it daily
since July without issue.

So now, I have some things I'd like to send back up stream
and get integrated into the emacs distribution:

	- Man pages for things installed to /usr/bin that didn't
	  already have a manpage:
		b2m.1
		ebrowse.1
		grep-changelog.1
		rcs-checkin.1
	- Small changes to config.guess and configure to properly
	  detect amd64 hardware running Solaris.
	- Use dldump() instead of the generic ELF dump code
	  under Solaris.
	- Use the system malloc under Solaris (at least with
	  amd64, emacs crashes without this).

The manpages can be viewed at:

http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1

and the patches at:

http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch

The patches are for emacs 22.1. I've examined 22.3, and the
changes are applicable there as well. If 22.1 diffs are OK,
that's easiest for me, but if not, then please let me know what
I need to supply. These diffs are all very short, affecting a
small number of lines in each file.

So my questions: How can I go about submitting these changes?
Is there someone who might work with me to get this done?
What format would you need to get them in, and where can
I send them?

Thanks!

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > This message is a follow up to one I sent to emacs-devel
  > last July:
  > 
  > 	http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html
  > 
  > The question had to do with why emacs wasn't using dldump()
  > to produce the dumped executable under Solaris. It had been using it
  > up until 2002, at which point it was commented out, and it wasn't
  > clear why. No one knew the reason, and the consensus was "try it and see".
  > 
  > Since then, I've done some work to integrate emacs with
  > OpenSolaris as a standard package. I turned on dldump(),
  > and have been using the emacs binaries built with it daily
  > since July without issue.
  > 
  > So now, I have some things I'd like to send back up stream
  > and get integrated into the emacs distribution:
  > 
  > 	- Man pages for things installed to /usr/bin that didn't
  > 	  already have a manpage:
  > 		b2m.1
  > 		ebrowse.1
  > 		grep-changelog.1
  > 		rcs-checkin.1
  > 	- Small changes to config.guess and configure to properly
  > 	  detect amd64 hardware running Solaris.
  > 	- Use dldump() instead of the generic ELF dump code
  > 	  under Solaris.
  > 	- Use the system malloc under Solaris (at least with
  > 	  amd64, emacs crashes without this).
  > 
  > The manpages can be viewed at:
  > 
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1

Hopefully someone else can address these changes, I'll address the rest.

  > and the patches at:
  > 
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch

Please send this one to config-patches@gnu.org.
We don't modify this file directly in emacs, it gets updated from time
to time from:
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess

  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch

This one is fine, but it depends on the previous one being installed by
the config.guess maintainers.
BTW, do you know anything about emacs running on  powerpc*-*-solaris2*
or  rs6000-*-solaris2* ? configure.in mentions them.

  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch

Last time when you posted this you said you were going to test it on
multiple Solaris versions.  Have you managed to do that?  This is also
valid for the next patch.

  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch
  > 
  > The patches are for emacs 22.1. I've examined 22.3, and the
  > changes are applicable there as well. If 22.1 diffs are OK,
  > that's easiest for me, but if not, then please let me know what
  > I need to supply. These diffs are all very short, affecting a
  > small number of lines in each file.

AFAIK the 22.x branch is closed, there will not be any more releases
from that branch.  But we could install your changes on HEAD.

Thanks

        --dan

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
> Ali Bahrami <ali_gnu@emvision.com> writes:
> 
>   > This message is a follow up to one I sent to emacs-devel
>   > last July:
>   > 
>   > 	http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html
>   > 
>   > The question had to do with why emacs wasn't using dldump()
>   > to produce the dumped executable under Solaris. It had been using it
>   > up until 2002, at which point it was commented out, and it wasn't
>   > clear why. No one knew the reason, and the consensus was "try it and see".
>   > 
>   > Since then, I've done some work to integrate emacs with
>   > OpenSolaris as a standard package. I turned on dldump(),
>   > and have been using the emacs binaries built with it daily
>   > since July without issue.
>   > 
>   > So now, I have some things I'd like to send back up stream
>   > and get integrated into the emacs distribution:
>   > 
>   > 	- Man pages for things installed to /usr/bin that didn't
>   > 	  already have a manpage:
>   > 		b2m.1
>   > 		ebrowse.1
>   > 		grep-changelog.1
>   > 		rcs-checkin.1
>   > 	- Small changes to config.guess and configure to properly
>   > 	  detect amd64 hardware running Solaris.
>   > 	- Use dldump() instead of the generic ELF dump code
>   > 	  under Solaris.
>   > 	- Use the system malloc under Solaris (at least with
>   > 	  amd64, emacs crashes without this).
>   > 
>   > The manpages can be viewed at:
>   > 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1
> 
> Hopefully someone else can address these changes, I'll address the rest.
> 
>   > and the patches at:
>   > 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
> 
> Please send this one to config-patches@gnu.org.
> We don't modify this file directly in emacs, it gets updated from time
> to time from:
> http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
> 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
> 
> This one is fine, but it depends on the previous one being installed by
> the config.guess maintainers.
> BTW, do you know anything about emacs running on  powerpc*-*-solaris2*
> or  rs6000-*-solaris2* ? configure.in mentions them.
> 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
> 
> Last time when you posted this you said you were going to test it on
> multiple Solaris versions.  Have you managed to do that?  This is also
> valid for the next patch.
> 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch
>   > 
>   > The patches are for emacs 22.1. I've examined 22.3, and the
>   > changes are applicable there as well. If 22.1 diffs are OK,
>   > that's easiest for me, but if not, then please let me know what
>   > I need to supply. These diffs are all very short, affecting a
>   > small number of lines in each file.
> 
> AFAIK the 22.x branch is closed, there will not be any more releases
> from that branch.  But we could install your changes on HEAD.
> 
> Thanks
> 
>         --dan

Hi Dan,

    I will send the config.guess patch to config-patches@gnu.org today.
In the meantime, the change to configure should be safe to make immediately.

I'm only concerned about getting these changes into HEAD. My patches are
for 22.1, but only because that's the version I used for this work. So
that would be great. If you can use these old patches as a basis for making
the necessary changes (which are small) to HEAD, then that would be a big
time saver for me, and much appreciated. If you need specific patches against
HEAD, then point me at it and I'll put some together.

I only know a little about emacs on the power architecture: Sun funded
a port during the 90's. As a point of irrelevant trivia, it was a little endian
system, and not big endian as one might expect. For reasons that are lost
in time, the port was completed, and a few pre-releases were made, but it never
shipped as a standard product, wasn't updated with the main branch, and quickly
faded away. My only quess is that powerpc*-*-solaris2* and rs6000-*-solaris2*
(the rs6000 also being a Power architecture system) date from this port, and
have probably never had more than a small handful of users --- probably none for
a decade or so.

There are people involved in a PowerPC port with OpenSolaris now (big endian,
a completely different deal) starting with the modern OpenSolaris code base.
I'm not sure if there's much overlap between the old stuff in emacs for power
on Solaris, and what would be needed for a modern version. There's probably more
affinity with the modern Linux ppc definitions.

About testing different Solaris versions, I remember the question being asked.
I thought I replied at the time, but can't be sure. In any event, the answer is
no. My interest is with the modern Solaris, which is OpenSolaris, and Solaris 10.
That's all I've tested, and I apologize for not having said that
directly. There are several reasons:

	- Maximizing the value of the time I spend on this project
	- No evidence of an actual problem with dldump for older Solaris,
	  including the fact that xemacs has apparently been using it
	  all along
	- The fact that the generic ELF dump code does work, and can be
	  used for those old releases. It isn't as nice as the dldump'd
	  version, but the resulting executables would run as well as they
	  ever did. Hence, there's an easy fallback if something did come up.

None of which, I admit, is actual testing. I feel that the risk of switching
the old versions to dldump() is minimal. However, if you feel more comfortable
applying this change such that it only applies to Solaris 10 and newer, that
would also be fine.

Thanks...

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > Dan Nicolaescu wrote:
  > > Ali Bahrami <ali_gnu@emvision.com> writes:
  > >
  > >   > This message is a follow up to one I sent to emacs-devel
  > >   > last July:
  > >   >   >
  > > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html
  > >   >   > The question had to do with why emacs wasn't using dldump()
  > >   > to produce the dumped executable under Solaris. It had been using it
  > >   > up until 2002, at which point it was commented out, and it wasn't
  > >   > clear why. No one knew the reason, and the consensus was "try it and see".
  > >   >   > Since then, I've done some work to integrate emacs with
  > >   > OpenSolaris as a standard package. I turned on dldump(),
  > >   > and have been using the emacs binaries built with it daily
  > >   > since July without issue.
  > >   >   > So now, I have some things I'd like to send back up stream
  > >   > and get integrated into the emacs distribution:
  > >   >   > 	- Man pages for things installed to /usr/bin that
  > > didn't
  > >   > 	  already have a manpage:
  > >   > 		b2m.1
  > >   > 		ebrowse.1
  > >   > 		grep-changelog.1
  > >   > 		rcs-checkin.1
  > >   > 	- Small changes to config.guess and configure to properly
  > >   > 	  detect amd64 hardware running Solaris.
  > >   > 	- Use dldump() instead of the generic ELF dump code
  > >   > 	  under Solaris.
  > >   > 	- Use the system malloc under Solaris (at least with
  > >   > 	  amd64, emacs crashes without this).
  > >   >   > The manpages can be viewed at:
  > >   >   >
  > > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1
  > >
  > > Hopefully someone else can address these changes, I'll address the rest.
  > >
  > >   > and the patches at:
  > >   >   >
  > > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
  > >
  > > Please send this one to config-patches@gnu.org.
  > > We don't modify this file directly in emacs, it gets updated from time
  > > to time from:
  > > http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
  > >
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
  > >
  > > This one is fine, but it depends on the previous one being installed by
  > > the config.guess maintainers.
  > > BTW, do you know anything about emacs running on  powerpc*-*-solaris2*
  > > or  rs6000-*-solaris2* ? configure.in mentions them.
  > >
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
  > >
  > > Last time when you posted this you said you were going to test it on
  > > multiple Solaris versions.  Have you managed to do that?  This is also
  > > valid for the next patch.
  > >
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch
  > >   >   > The patches are for emacs 22.1. I've examined 22.3, and the
  > >   > changes are applicable there as well. If 22.1 diffs are OK,
  > >   > that's easiest for me, but if not, then please let me know what
  > >   > I need to supply. These diffs are all very short, affecting a
  > >   > small number of lines in each file.
  > >
  > > AFAIK the 22.x branch is closed, there will not be any more releases
  > > from that branch.  But we could install your changes on HEAD.
  > >
  > > Thanks
  > >
  > >         --dan
  > 
  > Hi Dan,
  > 
  >    I will send the config.guess patch to config-patches@gnu.org today.
  > In the meantime, the change to configure should be safe to make immediately.

I'd rather wait and check in both of them together.

  > I'm only concerned about getting these changes into HEAD. My patches are
  > for 22.1, but only because that's the version I used for this work. So
  > that would be great. If you can use these old patches as a basis for making
  > the necessary changes (which are small) to HEAD, then that would be a big
  > time saver for me, and much appreciated. If you need specific patches against
  > HEAD, then point me at it and I'll put some together.

The changes are tiny, so the base version does not make any difference
in this particular case.

  > I only know a little about emacs on the power architecture: Sun funded
  > a port during the 90's. As a point of irrelevant trivia, it was a little endian
  > system, and not big endian as one might expect. For reasons that are lost
  > in time, the port was completed, and a few pre-releases were made, but it never
  > shipped as a standard product, wasn't updated with the main branch, and quickly
  > faded away. My only quess is that powerpc*-*-solaris2* and rs6000-*-solaris2*
  > (the rs6000 also being a Power architecture system) date from this port, and
  > have probably never had more than a small handful of users --- probably none for
  > a decade or so.

Thank you for the detailed info, then we can deprecate these ports for
the next release.

  > About testing different Solaris versions, I remember the question being asked.
  > I thought I replied at the time, but can't be sure. In any event, the answer is
  > no. My interest is with the modern Solaris, which is OpenSolaris, and Solaris 10.
  > That's all I've tested, and I apologize for not having said that
  > directly. There are several reasons:
  > 
  > 	- Maximizing the value of the time I spend on this project
  > 	- No evidence of an actual problem with dldump for older Solaris,
  > 	  including the fact that xemacs has apparently been using it
  > 	  all along
  > 	- The fact that the generic ELF dump code does work, and can be
  > 	  used for those old releases. It isn't as nice as the dldump'd
  > 	  version, but the resulting executables would run as well as they
  > 	  ever did. Hence, there's an easy fallback if something did come up.
  > 
  > None of which, I admit, is actual testing. I feel that the risk of switching
  > the old versions to dldump() is minimal. However, if you feel more comfortable
  > applying this change such that it only applies to Solaris 10 and newer, that
  > would also be fine.

I don't feel comfortable doing these changes without any testing at
all.  In that case, the best would be to add a new file
emacs/src/s/sol2-10.h that includes sol2-6.h and also contains your
changes.  
Then change configure.in to use that new file for Solaris 10+.

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
<snip>
 >
 > I don't feel comfortable doing these changes without any testing at
 > all.  In that case, the best would be to add a new file
 > emacs/src/s/sol2-10.h that includes sol2-6.h and also contains your
 > changes.
 > Then change configure.in to use that new file for Solaris 10+.

I've done that, and built the result on Solaris Nevada (amd64),
Solaris 10 (sparc), and Solaris 9 (x86). It seems to work properly,
and to use dldump() for S10 and Nevada (aka OpenSolaris), while
using the generic dump for S9.

I rolled the amd64 configure change into this as well --- I needed it
to test, and it makes sense to do the complete deal in one go.

Here is the contents of src/s/sol2-10.h, in between the '====' lines:

==========================================================================
/* Handle Solaris 2.10 */

#include "sol2-6.h"

/*
  * Use the Solaris dldump() function to dump emacs, instead of
  * the generic unexelf code. The resulting binary has a complete
  * symbol table, and is better for debugging and other observability
  * tools (debuggers, pstack, etc).
  *
  * If you encounter a problem using dldump(), please consider sending
  * a message to the OpenSolaris tools-linking mailing list:
  *      http://mail.opensolaris.org/mailman/listinfo/tools-linking
  *
  * Note: Emacs used to use  dldump() before, but this was changed
  * in revision 1.3 of sol2-6.h, on September 13, 2002, with the comment:
  *
  *      dldump does not handle all the extensions used by GNU ld
  *
  * It is not clear what extensions this refers to. Testing with
  * OpenSolaris shows that it works on newer Solaris versions.
  * If a problem surfaces, please post the details to the OpenSolaris
  * mailing list given above.
  *
  * It is likely that dldump() works with older Solaris too,
  * but this has not been tested, and so, this change is for S10
  * and newer only at this time.
  */

#undef UNEXEC
#define UNEXEC unexsol.o
==========================================================================

And here are the context diffs for the changes to configure.in

==========================================================================
*** configure.in.orig   Sat Oct 18 17:40:27 2008
--- configure.in        Sat Oct 18 18:27:43 2008
***************
*** 974,980 ****
     ;;

     *-auspex-sunos* | *-sun-sunos* | *-sun-bsd* | *-sun-solaris* \
!     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
       | rs6000-*-solaris2*)
       case "${canonical}" in
         m68*-sunos1* )  machine=sun1 ;;
--- 974,980 ----
     ;;

     *-auspex-sunos* | *-sun-sunos* | *-sun-bsd* | *-sun-solaris* \
!     | i[3456]86-*-solaris2* | x86_64-*-solaris2* | i[3456]86-*-sunos5* | power
pc*-*-solaris2* \
       | rs6000-*-solaris2*)
       case "${canonical}" in
         m68*-sunos1* )  machine=sun1 ;;
***************
*** 988,993 ****
--- 988,1001 ----
         sparc* )                machine=sparc ;;
         * )             unported=yes ;;
       esac
+ ## FIXME: make this into a proper fix that checks the compiler type,
+ ## rather than relying on path. Or is /usr/ccs/lib/cpp a bad default now?
+     if [ "x$CC" = x/opt/SUNWspro/bin/cc ]; then
+         ## -Xs prevents spurious whitespace.
+       SOLARIS_NON_GNU_CPP="/opt/SUNWspro/bin/cc -E -Xs"
+     else
+       SOLARIS_NON_GNU_CPP=/usr/ccs/lib/cpp
+     fi
       case "${canonical}" in
         ## The Sun386 didn't get past 4.0.
         i[3456]86-*-sunos4        ) opsys=sunos4-0 ;;
***************
*** 1028,1044 ****
                 NON_GNU_CPP=/usr/ccs/lib/cpp
                 RANLIB="ar -ts"
                 ;;
!       *-sunos5* | *-solaris* )
                 opsys=sol2-6
! ## FIXME: make this into a proper fix that checks the compiler type,
! ## rather than relying on path. Or is /usr/ccs/lib/cpp a bad default now?
!               if [ "x$CC" = x/opt/SUNWspro/bin/cc ]; then
!                 ## -Xs prevents spurious whitespace.
!                 NON_GNU_CPP="/opt/SUNWspro/bin/cc -E -Xs"
!               else
!                 NON_GNU_CPP=/usr/ccs/lib/cpp
!               fi
                 ;;
         *                         ) opsys=bsd4-2   ;;
       esac
       ## Watch out for a compiler that we know will not work.
--- 1036,1049 ----
                 NON_GNU_CPP=/usr/ccs/lib/cpp
                 RANLIB="ar -ts"
                 ;;
!       *-sunos5.[7-9] | *-solaris2.[7-9] )
                 opsys=sol2-6
!               NON_GNU_CPP=${SOLARIS_NON_GNU_CPP}
                 ;;
+       *-sunos5* | *-solaris* )
+               opsys=sol2-10
+               NON_GNU_CPP=${SOLARIS_NON_GNU_CPP}
+               ;;
         *                         ) opsys=bsd4-2   ;;
       esac
       ## Watch out for a compiler that we know will not work.
==========================================================================

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > Dan Nicolaescu wrote:
  > <snip>
  > >
  > > I don't feel comfortable doing these changes without any testing at
  > > all.  In that case, the best would be to add a new file
  > > emacs/src/s/sol2-10.h that includes sol2-6.h and also contains your
  > > changes.
  > > Then change configure.in to use that new file for Solaris 10+.
  > 
  > I've done that, and built the result on Solaris Nevada (amd64),
  > Solaris 10 (sparc), and Solaris 9 (x86). It seems to work properly,
  > and to use dldump() for S10 and Nevada (aka OpenSolaris), while
  > using the generic dump for S9.
  > 
  > I rolled the amd64 configure change into this as well --- I needed it
  > to test, and it makes sense to do the complete deal in one go.
  > 
  > Here is the contents of src/s/sol2-10.h, in between the '====' lines:
  > 
  > ==========================================================================
  > /* Handle Solaris 2.10 */
  > 
  > #include "sol2-6.h"
  > 
  > /*
  >  * Use the Solaris dldump() function to dump emacs, instead of

Please mention here that the dldump function is used in unexsol.c,
otherwise people would have to guess what is going on.

  >  * the generic unexelf code. The resulting binary has a complete
  >  * symbol table, and is better for debugging and other observability
  >  * tools (debuggers, pstack, etc).


  >  * Note: Emacs used to use  dldump() before, but this was changed
  >  * in revision 1.3 of sol2-6.h, on September 13, 2002, with the comment:
  >  *
  >  *      dldump does not handle all the extensions used by GNU ld
  >  *
  >  * It is not clear what extensions this refers to. Testing with
  >  * OpenSolaris shows that it works on newer Solaris versions.
  >  * If a problem surfaces, please post the details to the OpenSolaris
  >  * mailing list given above.

This is not useful, you can omit it.

  >  * It is likely that dldump() works with older Solaris too,
  >  * but this has not been tested, and so, this change is for S10
                                                                ^^^
                                                                Solaris 10
  >  * and newer only at this time.
  >  */
  > 
  > #undef UNEXEC
  > #define UNEXEC unexsol.o

You also had a change to use system malloc.  Don't you want that in here too?


  > ==========================================================================
  > 
  > And here are the context diffs for the changes to configure.in
  > 
  > ==========================================================================
  > *** configure.in.orig   Sat Oct 18 17:40:27 2008
  > --- configure.in        Sat Oct 18 18:27:43 2008
  > ***************
  > *** 974,980 ****
  >     ;;
  > 
  >     *-auspex-sunos* | *-sun-sunos* | *-sun-bsd* | *-sun-solaris* \
  > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
  >       | rs6000-*-solaris2*)
  >       case "${canonical}" in
  >         m68*-sunos1* )  machine=sun1 ;;
  > --- 974,980 ----
  >     ;;
  > 
  >     *-auspex-sunos* | *-sun-sunos* | *-sun-bsd* | *-sun-solaris* \
  > !     | i[3456]86-*-solaris2* | x86_64-*-solaris2* | i[3456]86-*-sunos5* | power
  > pc*-*-solaris2* \
  >       | rs6000-*-solaris2*)
  >       case "${canonical}" in
  >         m68*-sunos1* )  machine=sun1 ;;
  > ***************
  > *** 988,993 ****
  > --- 988,1001 ----
  >         sparc* )                machine=sparc ;;
  >         * )             unported=yes ;;
  >       esac
  > + ## FIXME: make this into a proper fix that checks the compiler type,
  > + ## rather than relying on path. Or is /usr/ccs/lib/cpp a bad default now?
  > +     if [ "x$CC" = x/opt/SUNWspro/bin/cc ]; then
  > +         ## -Xs prevents spurious whitespace.
  > +       SOLARIS_NON_GNU_CPP="/opt/SUNWspro/bin/cc -E -Xs"
  > +     else
  > +       SOLARIS_NON_GNU_CPP=/usr/ccs/lib/cpp
  > +     fi
  >       case "${canonical}" in
  >         ## The Sun386 didn't get past 4.0.
  >         i[3456]86-*-sunos4        ) opsys=sunos4-0 ;;
  > ***************
  > *** 1028,1044 ****
  >                 NON_GNU_CPP=/usr/ccs/lib/cpp
  >                 RANLIB="ar -ts"
  >                 ;;
  > !       *-sunos5* | *-solaris* )
  >                 opsys=sol2-6
  > ! ## FIXME: make this into a proper fix that checks the compiler type,
  > ! ## rather than relying on path. Or is /usr/ccs/lib/cpp a bad default now?
  > !               if [ "x$CC" = x/opt/SUNWspro/bin/cc ]; then
  > !                 ## -Xs prevents spurious whitespace.
  > !                 NON_GNU_CPP="/opt/SUNWspro/bin/cc -E -Xs"
  > !               else
  > !                 NON_GNU_CPP=/usr/ccs/lib/cpp
  > !               fi
  >                 ;;
  >         *                         ) opsys=bsd4-2   ;;
  >       esac
  >       ## Watch out for a compiler that we know will not work.
  > --- 1036,1049 ----
  >                 NON_GNU_CPP=/usr/ccs/lib/cpp
  >                 RANLIB="ar -ts"
  >                 ;;
  > !       *-sunos5.[7-9] | *-solaris2.[7-9] )
  >                 opsys=sol2-6
  > !               NON_GNU_CPP=${SOLARIS_NON_GNU_CPP}
  >                 ;;
  > +       *-sunos5* | *-solaris* )
  > +               opsys=sol2-10
  > +               NON_GNU_CPP=${SOLARIS_NON_GNU_CPP}
  > +               ;;
  >         *                         ) opsys=bsd4-2   ;;
  >       esac
  >       ## Watch out for a compiler that we know will not work.
  > ==========================================================================


Can you generate this vs configure.in from CVS HEAD, that file has
changed a bit.

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan,

    I made the changes you suggested to the src/s/sol2-10.h. I
pulled a copy of CVS head, and produced diffs for configure.in based
on that. Both items are below, delimited by '=======' lines.

configure.in has changed since emacs 22.1, and there's a lot
less cruft there. As a result, this version of the change is simpler
than the previous one.

I've build the result on Nevada Solaris (OpenSolaris) and on Solaris 9,
and both work as expected.

-----

FYI: CVS HEAD does not build on Solaris 10. This is not due to my changes,
as I tried it on an unmodified workspace as well. The end of the
output is:

	checking for SmcOpenConnection in -lSM... no
	checking whether netdb declares h_errno... no
	checking for working alloca.h... no
	checking for alloca... no
	checking whether `alloca.c' needs Cray hooks... no
	checking stack direction for C alloca... -1
	configure: error: a system implementation of alloca is required

Solaris has alloca, so something is up with the test being used.
However, the changes I'm proposing here are orthogonal to whatever
is happening with that.

- Ali


=========================================================================
/* Handle Solaris 2.10 */

#include "sol2-6.h"

/*
  * Use the native system malloc()
  */
#define SYSTEM_MALLOC

/*
  * Use the Solaris dldump() function, called from unexsol.c, to dump
  * emacs, instead of the generic ELF dump code found in unexelf.c.
  * The resulting binary has a complete symbol table, and is better
  * for debugging and other observabilty tools (debuggers, pstack, etc).
  *
  * If you encounter a problem using dldump(), please consider sending
  * a message to the OpenSolaris tools-linking mailing list:
  *      http://mail.opensolaris.org/mailman/listinfo/tools-linking
  *
  * It is likely be that dldump() works with older Solaris too,
  * but this has not been tested, and so, this change is for
  * Solaris 10 and newer only at this time.
  */
#undef UNEXEC
#define UNEXEC unexsol.o
=========================================================================
*** configure.in.orig   Wed Oct 22 20:40:42 2008
--- configure.in        Wed Oct 22 20:53:20 2008
***************
*** 442,449 ****
     ;;

     *-sun-solaris* \
!     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
!     | rs6000-*-solaris2*)
       case "${canonical}" in
         i[3456]86-*-* )     machine=intel386 ;;
         amd64-*-*|x86_64-*-*)   machine=amdx86-64 ;;
--- 442,450 ----
     ;;

     *-sun-solaris* \
!     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
!     | x86_64-*-solaris2*    | x86_64-*-sunos5*    \
!     | powerpc*-*-solaris2*  | rs6000-*-solaris2*)
       case "${canonical}" in
         i[3456]86-*-* )     machine=intel386 ;;
         amd64-*-*|x86_64-*-*)   machine=amdx86-64 ;;
***************
*** 471,480 ****
                 NON_GNU_CPP=/usr/ccs/lib/cpp
                 RANLIB="ar -ts"
                 ;;
!       *-sunos5* | *-solaris* )
                 opsys=sol2-6
                 emacs_check_sunpro_c=yes
                 NON_GNU_CPP=/usr/ccs/lib/cpp
                 ;;
       esac
       ## Watch out for a compiler that we know will not work.
--- 472,486 ----
                 NON_GNU_CPP=/usr/ccs/lib/cpp
                 RANLIB="ar -ts"
                 ;;
!       *-sunos5.[7-9]* | *-solaris2.[7-9]* )
                 opsys=sol2-6
                 emacs_check_sunpro_c=yes
                 NON_GNU_CPP=/usr/ccs/lib/cpp
+               ;;
+       *-sunos5* | *-solaris* )
+               opsys=sol2-10
+               emacs_check_sunpro_c=yes
+               NON_GNU_CPP=/usr/ccs/lib/cpp
                 ;;
       esac
       ## Watch out for a compiler that we know will not work.
=========================================================================

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Ali Bahrami wrote:

<snip>



>  * It is likely be that dldump() works with older Solaris too,
>  * but this has not been tested, and so, this change is for
>  * Solaris 10 and newer only at this time.
>  */


Ah, the clear light of day...

That first sentence should be "It is likely that"...

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > Dan,
  > 
  >    I made the changes you suggested to the src/s/sol2-10.h. I
  > pulled a copy of CVS head, and produced diffs for configure.in based
  > on that. Both items are below, delimited by '=======' lines.

Thanks, I checked this in, with some simplifications.

  > =========================================================================
  > *** configure.in.orig   Wed Oct 22 20:40:42 2008
  > --- configure.in        Wed Oct 22 20:53:20 2008
  > ***************
  > *** 442,449 ****
  >     ;;
  > 
  >     *-sun-solaris* \
  > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
  > !     | rs6000-*-solaris2*)
  >       case "${canonical}" in
  >         i[3456]86-*-* )     machine=intel386 ;;
  >         amd64-*-*|x86_64-*-*)   machine=amdx86-64 ;;
  > --- 442,450 ----
  >     ;;
  > 
  >     *-sun-solaris* \
  > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
  > !     | x86_64-*-solaris2*    | x86_64-*-sunos5*    \
  > !     | powerpc*-*-solaris2*  | rs6000-*-solaris2*)

This hunk should not be necessary, *-sun-solaris* should match anyway.
Please verify that things still work.

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
> Ali Bahrami <ali_gnu@emvision.com> writes:
> 
>   > Dan,
>   > 
>   >    I made the changes you suggested to the src/s/sol2-10.h. I
>   > pulled a copy of CVS head, and produced diffs for configure.in based
>   > on that. Both items are below, delimited by '=======' lines.
> 
> Thanks, I checked this in, with some simplifications.
> 
>   > =========================================================================
>   > *** configure.in.orig   Wed Oct 22 20:40:42 2008
>   > --- configure.in        Wed Oct 22 20:53:20 2008
>   > ***************
>   > *** 442,449 ****
>   >     ;;
>   > 
>   >     *-sun-solaris* \
>   > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
>   > !     | rs6000-*-solaris2*)
>   >       case "${canonical}" in
>   >         i[3456]86-*-* )     machine=intel386 ;;
>   >         amd64-*-*|x86_64-*-*)   machine=amdx86-64 ;;
>   > --- 442,450 ----
>   >     ;;
>   > 
>   >     *-sun-solaris* \
>   > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
>   > !     | x86_64-*-solaris2*    | x86_64-*-sunos5*    \
>   > !     | powerpc*-*-solaris2*  | rs6000-*-solaris2*)
> 
> This hunk should not be necessary, *-sun-solaris* should match anyway.
> Please verify that things still work.

Dan,

    src/s/sol2-10.h is fine. There are some issues with the changes to
configure though.

The hunk you removed really is needed, at least the 'x86_64-*-solaris2*' part.
I put the 'x86_64-*-sunos5*' one in because it mirror how the 32-bit one
above is defined, but the 'x86_64-*-solaris2*' is needed to get a build.

The reason '*-sun-solaris*' isn't sufficient is that on X86
hardware, the "vendor" is not "sun":

     % ./config.guess
     i386-pc-solaris2.11
     % CC='gcc -m64' ./config.guess
     amd64-solaris2.11

There is a typo (missing ;; in a case statement), and the clause
for Solaris 7-9 fails because a bit got missed. I'm going to
show the part of the file I modified here, and mark the modified
lines with a '>' in column 1.

====================================================================

   *-sun-solaris* \
 >   | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
 >   | x86_64-*-solaris2*    | x86_64-*-sunos5*    \
 >   | powerpc*-*-solaris2*  | rs6000-*-solaris2*)
     case "${canonical}" in
       i[3456]86-*-* )     machine=intel386 ;;
       amd64-*-*|x86_64-*-*)	machine=amdx86-64 ;;
       powerpc* | rs6000* )  machine=ibmrs6000 ;;
       sparc* )		machine=sparc ;;
       * )		unported=yes ;;
     esac
     case "${canonical}" in
       *-sunos5.3* | *-solaris2.3* )
		opsys=sol2-3
		NON_GNU_CPP=/usr/ccs/lib/cpp
		;;
       *-sunos5.4* | *-solaris2.4* )
		opsys=sol2-4
		NON_GNU_CPP=/usr/ccs/lib/cpp
		RANLIB="ar -ts"
		;;
       *-sunos5.5* | *-solaris2.5* )
		opsys=sol2-5
		NON_GNU_CPP=/usr/ccs/lib/cpp
		RANLIB="ar -ts"
		;;
       *-sunos5.6* | *-solaris2.6* )
		opsys=sol2-6
		NON_GNU_CPP=/usr/ccs/lib/cpp
		RANLIB="ar -ts"
		;;
 >     *-sunos5.[7-9]* | *-solaris2.[7-9]* )
		opsys=sol2-6
		emacs_check_sunpro_c=yes
		NON_GNU_CPP=/usr/ccs/lib/cpp
 >		;;
       *-sunos5* | *-solaris* )
====================================================================

Or expressed as diffs:

====================================================================
2555,2556c2555,2557
<     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
<     | rs6000-*-solaris2*)
---
 >     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
 >     | x86_64-*-solaris2*    | x86_64-*-sunos5*    \
 >     | powerpc*-*-solaris2*  | rs6000-*-solaris2*)
2584c2585
<       *-sunos5.[7-9]* | *-solaris[7-9]* )
---
 >       *-sunos5.[7-9]* | *-solaris2.[7-9]* )
2588c2589
<
---
 >               ;;
====================================================================

Let me know and I'll retest. Thanks...

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > Dan Nicolaescu wrote:
  > > Ali Bahrami <ali_gnu@emvision.com> writes:
  > >
  > >   > Dan,
  > >   >   >    I made the changes you suggested to the
  > > src/s/sol2-10.h. I
  > >   > pulled a copy of CVS head, and produced diffs for configure.in based
  > >   > on that. Both items are below, delimited by '=======' lines.
  > >
  > > Thanks, I checked this in, with some simplifications.
  > >
  > >   > =========================================================================
  > >   > *** configure.in.orig   Wed Oct 22 20:40:42 2008
  > >   > --- configure.in        Wed Oct 22 20:53:20 2008
  > >   > ***************
  > >   > *** 442,449 ****
  > >   >     ;;
  > >   >   >     *-sun-solaris* \
  > >   > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* | powerpc*-*-solaris2* \
  > >   > !     | rs6000-*-solaris2*)
  > >   >       case "${canonical}" in
  > >   >         i[3456]86-*-* )     machine=intel386 ;;
  > >   >         amd64-*-*|x86_64-*-*)   machine=amdx86-64 ;;
  > >   > --- 442,450 ----
  > >   >     ;;
  > >   >   >     *-sun-solaris* \
  > >   > !     | i[3456]86-*-solaris2* | i[3456]86-*-sunos5* \
  > >   > !     | x86_64-*-solaris2*    | x86_64-*-sunos5*    \
  > >   > !     | powerpc*-*-solaris2*  | rs6000-*-solaris2*)
  > >
  > > This hunk should not be necessary, *-sun-solaris* should match anyway.
  > > Please verify that things still work.
  > 
  > Dan,
  > 
  >    src/s/sol2-10.h is fine. There are some issues with the changes to
  > configure though.
  > 
  > The hunk you removed really is needed, at least the 'x86_64-*-solaris2*' part.
  > I put the 'x86_64-*-sunos5*' one in because it mirror how the 32-bit one
  > above is defined, but the 'x86_64-*-solaris2*' is needed to get a build.
  > 
  > The reason '*-sun-solaris*' isn't sufficient is that on X86
  > hardware, the "vendor" is not "sun":
  > 
  >     % ./config.guess
  >     i386-pc-solaris2.11
  >     % CC='gcc -m64' ./config.guess
  >     amd64-solaris2.11
       ^^^^^^^^^^^^^^^^^^
This does not look right, it needs to be a triplet, not a pair, so amd64-pc-solaris2.11
But I'll wait until your config.guess changes are checked in.
It's actually quite surprising that config.guess did not support for
amd64/x86_64 on Solaris...

  > There is a typo (missing ;; in a case statement), and the clause
  > for Solaris 7-9 fails because a bit got missed. 

Thanks.  Fixed. 

  > I'm going to show the part of the file I modified here, and mark the
  > modified lines with a '>' in column 1.

BTW, context or unified diffs are preferred here. 

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
> Ali Bahrami <ali_gnu@emvision.com> writes:
...
>   >     % ./config.guess
>   >     i386-pc-solaris2.11
>   >     % CC='gcc -m64' ./config.guess
>   >     amd64-solaris2.11
>        ^^^^^^^^^^^^^^^^^^
> This does not look right, it needs to be a triplet, not a pair, so amd64-pc-solaris2.11

I found that interesting too, which is one reason I showed that output
to Ben in our other discussion. I trust that he'll flag it if its wrong.
However, emacs configure is happy with this, so perhaps it's really OK,

I'll fix whatever is needed there.

Isn't the idea of having a "vendor" for instruction sets rather
dated? I surely don't care who made my CPU, only what ISA it
supports and what OS is running.

> But I'll wait until your config.guess changes are checked in.
> It's actually quite surprising that config.guess did not support for
> amd64/x86_64 on Solaris...

amd64 support for Solaris came with Solaris 10 (2005), and most people
build the default that they get, which is 32-bit, never thinking to dig
deeper. I wanted a 64-bit emacs specifically to get around the buffer size
limit. So, perhaps I really am the first to hit this.

> 
> BTW, context or unified diffs are preferred here. 

Understood, and I have been sending context diffs until this
last one. The bits that got missed made me think that perhaps
it was the wrong thing. Sorry, I'll go back to doing that.

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > Dan Nicolaescu wrote:
  > > Ali Bahrami <ali_gnu@emvision.com> writes:
  > ...
  > >   >     % ./config.guess
  > >   >     i386-pc-solaris2.11
  > >   >     % CC='gcc -m64' ./config.guess
  > >   >     amd64-solaris2.11
  > >        ^^^^^^^^^^^^^^^^^^
  > > This does not look right, it needs to be a triplet, not a pair, so amd64-pc-solaris2.11
  > 
  > I found that interesting too, which is one reason I showed that output
  > to Ben in our other discussion. I trust that he'll flag it if its wrong.
  > However, emacs configure is happy with this, so perhaps it's really OK,

IMHO amd64-solaris2 is not a good idea.  config.guess is used by
anything that uses autoconf, there are many many scripts that depend on
having a triple.  What you had to fix in configure.in is just one such
example.

  > I'll fix whatever is needed there.
  > 
  > Isn't the idea of having a "vendor" for instruction sets rather
  > dated? I surely don't care who made my CPU, only what ISA it
  > supports and what OS is running.

Probably, but it's been around for a while, so it's ingrained in many
places... 

  > > BTW, context or unified diffs are preferred here. 
  > 
  > Understood, and I have been sending context diffs until this
  > last one. The bits that got missed made me think that perhaps
  > it was the wrong thing. Sorry, I'll go back to doing that.

The patch did not apply cleanly, I got rejects so I had to hand edit the
change.  Hence the problem, but don't worry about it, it's all good as
long as things move forward.

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > This message is a follow up to one I sent to emacs-devel
  > last July:
  > 
  > 	http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html
  > 
  > The question had to do with why emacs wasn't using dldump()
  > to produce the dumped executable under Solaris. It had been using it
  > up until 2002, at which point it was commented out, and it wasn't
  > clear why. No one knew the reason, and the consensus was "try it and see".
  > 
  > Since then, I've done some work to integrate emacs with
  > OpenSolaris as a standard package. I turned on dldump(),
  > and have been using the emacs binaries built with it daily
  > since July without issue.
  > 
  > So now, I have some things I'd like to send back up stream
  > and get integrated into the emacs distribution:
  > 
  > 	- Man pages for things installed to /usr/bin that didn't
  > 	  already have a manpage:
  > 		b2m.1
  > 		ebrowse.1
  > 		grep-changelog.1
  > 		rcs-checkin.1
  > 	- Small changes to config.guess and configure to properly
  > 	  detect amd64 hardware running Solaris.
  > 	- Use dldump() instead of the generic ELF dump code
  > 	  under Solaris.
  > 	- Use the system malloc under Solaris (at least with
  > 	  amd64, emacs crashes without this).
  > 
  > The manpages can be viewed at:
  > 
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1
  > 
  > and the patches at:
  > 
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
  > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch
  > 
  > The patches are for emacs 22.1. I've examined 22.3, and the
  > changes are applicable there as well. If 22.1 diffs are OK,
  > that's easiest for me, but if not, then please let me know what
  > I need to supply. These diffs are all very short, affecting a
  > small number of lines in each file.
  > 
  > So my questions: How can I go about submitting these changes?
  > Is there someone who might work with me to get this done?
  > What format would you need to get them in, and where can
  > I send them?

Your patches for the Solaris configuration are now in.
config.guess has been updated from upstream with your changes.
There's a man page for ebrowse now.
Not sure what to do about the man pages for b2m, grep-changelog, and
rcs-checkin.  You might want to open a separate bug for them.

Thanks

        --dan

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
> Ali Bahrami <ali_gnu@emvision.com> writes:
> 
>   > This message is a follow up to one I sent to emacs-devel
>   > last July:
>   > 
>   > 	http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html
>   > 
>   > The question had to do with why emacs wasn't using dldump()
>   > to produce the dumped executable under Solaris. It had been using it
>   > up until 2002, at which point it was commented out, and it wasn't
>   > clear why. No one knew the reason, and the consensus was "try it and see".
>   > 
>   > Since then, I've done some work to integrate emacs with
>   > OpenSolaris as a standard package. I turned on dldump(),
>   > and have been using the emacs binaries built with it daily
>   > since July without issue.
>   > 
>   > So now, I have some things I'd like to send back up stream
>   > and get integrated into the emacs distribution:
>   > 
>   > 	- Man pages for things installed to /usr/bin that didn't
>   > 	  already have a manpage:
>   > 		b2m.1
>   > 		ebrowse.1
>   > 		grep-changelog.1
>   > 		rcs-checkin.1
>   > 	- Small changes to config.guess and configure to properly
>   > 	  detect amd64 hardware running Solaris.
>   > 	- Use dldump() instead of the generic ELF dump code
>   > 	  under Solaris.
>   > 	- Use the system malloc under Solaris (at least with
>   > 	  amd64, emacs crashes without this).
>   > 
>   > The manpages can be viewed at:
>   > 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1
>   > 
>   > and the patches at:
>   > 
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
>   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch
>   > 
>   > The patches are for emacs 22.1. I've examined 22.3, and the
>   > changes are applicable there as well. If 22.1 diffs are OK,
>   > that's easiest for me, but if not, then please let me know what
>   > I need to supply. These diffs are all very short, affecting a
>   > small number of lines in each file.
>   > 
>   > So my questions: How can I go about submitting these changes?
>   > Is there someone who might work with me to get this done?
>   > What format would you need to get them in, and where can
>   > I send them?
> 
> Your patches for the Solaris configuration are now in.
> config.guess has been updated from upstream with your changes.
> There's a man page for ebrowse now.
> Not sure what to do about the man pages for b2m, grep-changelog, and
> rcs-checkin.  You might want to open a separate bug for them.
> 
> Thanks
> 
>         --dan


I'm not sure what I'll do about the manpages, but I don't consider them part of
this bug anymore.

So, we appear to be done, except for the issue I flagged a couple
of days ago. Ben made a modification to my patch for config.guess
(dropping the use of a fully qualified path for 'echo') that causes
emacs to not build correctly for a Solaris user using the bash shell.
It does build successfully, but will always choose to build a 64-bit binary.

I sent mail to Ben about it, and we'll see what he says. However, you
should probably hold off on closing things out just yet.

Another thing to know is that I'm going to disappear for 3 weeks starting
on Dec. 19, and will only have sporadic email access. So I hope we can
get this wrapped up before I go.

Thanks!

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Dan Nicolaescu]

Ali Bahrami <ali_gnu@emvision.com> writes:

  > Dan Nicolaescu wrote:
  > > Ali Bahrami <ali_gnu@emvision.com> writes:
  > >
  > >   > This message is a follow up to one I sent to emacs-devel
  > >   > last July:
  > >   >   >
  > > http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html
  > >   >   > The question had to do with why emacs wasn't using dldump()
  > >   > to produce the dumped executable under Solaris. It had been using it
  > >   > up until 2002, at which point it was commented out, and it wasn't
  > >   > clear why. No one knew the reason, and the consensus was "try it and see".
  > >   >   > Since then, I've done some work to integrate emacs with
  > >   > OpenSolaris as a standard package. I turned on dldump(),
  > >   > and have been using the emacs binaries built with it daily
  > >   > since July without issue.
  > >   >   > So now, I have some things I'd like to send back up stream
  > >   > and get integrated into the emacs distribution:
  > >   >   > 	- Man pages for things installed to /usr/bin that
  > > didn't
  > >   > 	  already have a manpage:
  > >   > 		b2m.1
  > >   > 		ebrowse.1
  > >   > 		grep-changelog.1
  > >   > 		rcs-checkin.1
  > >   > 	- Small changes to config.guess and configure to properly
  > >   > 	  detect amd64 hardware running Solaris.
  > >   > 	- Use dldump() instead of the generic ELF dump code
  > >   > 	  under Solaris.
  > >   > 	- Use the system malloc under Solaris (at least with
  > >   > 	  amd64, emacs crashes without this).
  > >   >   > The manpages can be viewed at:
  > >   >   >
  > > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1
  > >   >   > and the patches at:
  > >   >   >
  > > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
  > >   > http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch
  > >   >   > The patches are for emacs 22.1. I've examined 22.3, and the
  > >   > changes are applicable there as well. If 22.1 diffs are OK,
  > >   > that's easiest for me, but if not, then please let me know what
  > >   > I need to supply. These diffs are all very short, affecting a
  > >   > small number of lines in each file.
  > >   >   > So my questions: How can I go about submitting these
  > > changes?
  > >   > Is there someone who might work with me to get this done?
  > >   > What format would you need to get them in, and where can
  > >   > I send them?
  > >
  > > Your patches for the Solaris configuration are now in.
  > > config.guess has been updated from upstream with your changes.
  > > There's a man page for ebrowse now.
  > > Not sure what to do about the man pages for b2m, grep-changelog, and
  > > rcs-checkin.  You might want to open a separate bug for them.
  > >
  > > Thanks
  > >
  > >         --dan
  > 
  > 
  > I'm not sure what I'll do about the manpages, but I don't consider them part of
  > this bug anymore.
  > 
  > So, we appear to be done, except for the issue I flagged a couple
  > of days ago. Ben made a modification to my patch for config.guess
  > (dropping the use of a fully qualified path for 'echo') that causes
  > emacs to not build correctly for a Solaris user using the bash shell.
  > It does build successfully, but will always choose to build a 64-bit binary.
  > 
  > I sent mail to Ben about it, and we'll see what he says. However, you
  > should probably hold off on closing things out just yet.

Ben made the changes you requested:

commit 7086ee26381fdcc645d12c3177ee0be072dd82ef
Author: Ben Elliston <bje@gnu.org>
Date:   Thu Dec 11 15:31:45 2008 +1100

        * config.guess (i86pc:SunOS:5.*:*, i86xen:SunOS:5.*:*): The full
        path to /usr/bin/echo is necessary to work around the shell
        builtins for echo that do not handle newlines.  From Ali
        Bahrami.

and those are checked in the emacs CVS now.  Is that what you had in
mind?  If yes, please verify that things work for you now.

       --dan

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
> Ben made the changes you requested:
> 
> commit 7086ee26381fdcc645d12c3177ee0be072dd82ef
> Author: Ben Elliston <bje@gnu.org>
> Date:   Thu Dec 11 15:31:45 2008 +1100
> 
>         * config.guess (i86pc:SunOS:5.*:*, i86xen:SunOS:5.*:*): The full
>         path to /usr/bin/echo is necessary to work around the shell
>         builtins for echo that do not handle newlines.  From Ali
>         Bahrami.
> 
> and those are checked in the emacs CVS now.  Is that what you had in
> mind?  If yes, please verify that things work for you now.
> 
>        --dan

Oh, great! I didn't know, sorry.

I will pull a fresh workspace, test it this afternoon, and
report back.

- Ali

bug#1191: How to contribute back changes for Emacs on Solaris

[Ali Bahrami]

Dan Nicolaescu wrote:
...
> Ben made the changes you requested:
> 
> commit 7086ee26381fdcc645d12c3177ee0be072dd82ef
> Author: Ben Elliston <bje@gnu.org>
> Date:   Thu Dec 11 15:31:45 2008 +1100
> 
>         * config.guess (i86pc:SunOS:5.*:*, i86xen:SunOS:5.*:*): The full
>         path to /usr/bin/echo is necessary to work around the shell
>         builtins for echo that do not handle newlines.  From Ali
>         Bahrami.
> 
> and those are checked in the emacs CVS now.  Is that what you had in
> mind?  If yes, please verify that things work for you now.
> 
>        --dan


I've build 32 and 64-bit emacs on both sparc and x86,
using the CVS head. It builds, and seems to work fine.

I think we're done! Thanks...

- Ali

bug#1191: marked as done (How to contribute back changes for Emacs on Solaris)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]


Your message dated Thu, 11 Dec 2008 19:09:02 -0800 (PST)
with message-id <200812120309.mBC392kD002742@mothra.ics.uci.edu>
and subject line Re: bug#1191: How to contribute back changes for Emacs on Solaris
has caused the Emacs bug report #1191,
regarding How to contribute back changes for Emacs on Solaris
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
1191: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1191
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4486 bytes --]

From: Ali Bahrami <ali_gnu@emvision.com>
To: bug-gnu-emacs@gnu.org
Subject: How to contribute back changes for Emacs on Solaris
Date: Thu, 16 Oct 2008 21:44:20 -0600
Message-ID: <48F80A14.7010502@emvision.com>

This message is a follow up to one I sent to emacs-devel
last July:

	http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg00070.html

The question had to do with why emacs wasn't using dldump()
to produce the dumped executable under Solaris. It had been using it
up until 2002, at which point it was commented out, and it wasn't
clear why. No one knew the reason, and the consensus was "try it and see".

Since then, I've done some work to integrate emacs with
OpenSolaris as a standard package. I turned on dldump(),
and have been using the emacs binaries built with it daily
since July without issue.

So now, I have some things I'd like to send back up stream
and get integrated into the emacs distribution:

	- Man pages for things installed to /usr/bin that didn't
	  already have a manpage:
		b2m.1
		ebrowse.1
		grep-changelog.1
		rcs-checkin.1
	- Small changes to config.guess and configure to properly
	  detect amd64 hardware running Solaris.
	- Use dldump() instead of the generic ELF dump code
	  under Solaris.
	- Use the system malloc under Solaris (at least with
	  amd64, emacs crashes without this).

The manpages can be viewed at:

http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/b2m.1
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/ebrowse.1
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/grep-changelog.1
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/man/man1/rcs-checkin.1

and the patches at:

http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/config.guess.patch
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/configure.patch
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/dldump.patch
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/emacs/augment/patch/sysmalloc.patch

The patches are for emacs 22.1. I've examined 22.3, and the
changes are applicable there as well. If 22.1 diffs are OK,
that's easiest for me, but if not, then please let me know what
I need to supply. These diffs are all very short, affecting a
small number of lines in each file.

So my questions: How can I go about submitting these changes?
Is there someone who might work with me to get this done?
What format would you need to get them in, and where can
I send them?

Thanks!

- Ali




[-- Attachment #3: Type: message/rfc822, Size: 2228 bytes --]

From: Dan Nicolaescu <dann@ics.uci.edu>
To: 1191-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1191: How to contribute back changes for Emacs on Solaris
Date: Thu, 11 Dec 2008 19:09:02 -0800 (PST)
Message-ID: <200812120309.mBC392kD002742@mothra.ics.uci.edu>

Ali Bahrami <ali_gnu@emvision.com> writes:

  > I think we're done! Thanks...

OK.  Thanks.