Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
On Thu, 2014-03-27 at 10:10 +, Jonathan Wakely wrote: > On 27 March 2014 09:35, Svante Signell wrote: > > - In an ideal situation no generated files should be shipped with a > > distribution, i.e. only configure.ac and Makefile.am, no configure, > > Makefile.in Makefile when not needed! > > But then end users need to have the autotools installed. I'm talking about people building packages from source, how many end users do that? The people building from source are either developers or package maintainers and the have these tools installed, for sure. > Installing alternative versions of the autotools should not be so > difficult for people who are capable of patching the GCC source. Of course not, but what's hindering upgrading the build system tools when new source versions are released. And again, will the autotools ever be backwards compatible?
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
On Thu, 2014-03-27 at 13:36 +0800, Chung-Ju Wu wrote:
> 2014-03-26 18:24 GMT+08:00 Svante Signell :
> > Hi,
> >
> > With the recent changes of not using automake for the build, only
> > auto{re}conf I have problems generating an updated Makefile.in from a
> > modified Makfile.am. Source is gcc-4.9-4.9-20140322
> >
>
> For gcc-4.9, I always use automake-1.11.1 and autoconf-2.64
> to regenerate 'configure' and 'Makefile.in' content.
Thanks, I downgraded to automake-1.11.1 and autoconf-2.64 and started
with a fresh install of Debian gcc-4.9-4.9-20140322.
Creating src/libgo/Makefile.in from Makefile.am only issued warnings:
(cd src/libgo;automake)
testsuite/Makefile.am:6: user variable `EXPECT' defined here...
/usr/share/automake-1.11/am/dejagnu.am: ... overrides Automake variable
`EXPECT' defined here
testsuite/Makefile.am:10: user variable `RUNTEST' defined here...
/usr/share/automake-1.11/am/dejagnu.am: ... overrides Automake variable
`RUNTEST' defined here
** I see one big problem with only autoconf2.64 being run when building:
All Makefile.in files have to be patched in addition to Makefile.am when
making changes, complicating things a lot!
Two questions/comments:
- When will gcc switch to use the latest versions of autoconf (2.69) and
automake (1.14) for it's build system? autoconf 2.64 and automake 1.11
are old by now, 26-Jul-2009 and 08-Dec-2009. Many distributions don't
have them any longer. For example for autoconf 2.65 in Debian you have
to use snapshot.debian.org. (up till now, there are specific versions
available: autoconf2.64 and automake1.11 (1.11.6))
- In an ideal situation no generated files should be shipped with a
distribution, i.e. only configure.ac and Makefile.am, no configure,
Makefile.in Makefile when not needed!
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
On Wed, 2014-03-26 at 16:30 +0100, Svante Signell wrote: > On Wed, 2014-03-26 at 16:20 +0100, Andreas Schwab wrote: > > Svante Signell writes: > > > > > autoconf 2.69: > > > > You must use autoconf 2.65, exactly. > > I thought autoconf versions were backwards compatible by now, obviously > not. Is this ever going to happen? Looks like the main src/configure.ac was generated for autoconf2.64: AC_PREREQ(2.64) (cd src/libgo/; autoconf) configure.ac:10: error: Please use exactly Autoconf 2.64 instead of 2.65. A mix of 2.64 and 2.65?
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
On Wed, 2014-03-26 at 16:20 +0100, Andreas Schwab wrote: > Svante Signell writes: > > > autoconf 2.69: > > You must use autoconf 2.65, exactly. I thought autoconf versions were backwards compatible by now, obviously not. Is this ever going to happen?
Re: gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
On Wed, 2014-03-26 at 11:24 +0100, Svante Signell wrote:
> Hi,
>
> With the recent changes of gcc not using automake for the build, only
> auto{re}conf I have problems generating an updated Makefile.in from a
> modified Makfile.am. Source is gcc-4.9-4.9-20140322.
>
> Some failing attempts:
>
> automake 1.14.1: (same with automake-1.11)
> (cd src/libgo; automake -if)
> aclocal.m4:16: warning: this file was generated for autoconf 2.64.
> You have another version of autoconf. It may work, but is not
> guaranteed to.
> If you have problems, you may need to regenerate the build system
> entirely.
> To do so, use the procedure documented by the package, typically
> `autoreconf'.
> config/go.m4:10: error: m4_copy: won't overwrite defined macro:
> AC_LANG_CONFTEST(Go)
> config/go.m4:10: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
> automake: error: autoconf failed with exit status: 1
removing src/libgo/Makefile.in gives the same error as with automake:
cd ../../../src/libgo
&& /bin/bash /home/srs/DEBs/gcc/gcc-4.9-4.9-20140322/src/missing --run
automake-1.11 --foreign Makefile
aclocal.m4:16: warning: this file was generated for autoconf 2.64.
You have another version of autoconf. It may work, but is not
guaranteed to.
If you have problems, you may need to regenerate the build system
entirely.
To do so, use the procedure documented by the package, typically
`autoreconf'.
config/go.m4:10: error: m4_copy: won't overwrite defined macro:
AC_LANG_CONFTEST(Go)
config/go.m4:10: the top level
autom4te: m4 failed with exit status: 1
automake-1.11: autoconf failed with exit status: 1
make[5]: Failed to remake makefile `Makefile'.
make[6]: Entering directory
`/home/srs/DEBs/gcc/gcc-4.9-4.9-20140322/build/i486-gnu/libgo'
cd ../../../src/libgo
&& /bin/bash /home/srs/DEBs/gcc/gcc-4.9-4.9-20140322/src/missing --run
automake-1.11 --foreign Makefile
aclocal.m4:16: warning: this file was generated for autoconf 2.64.
You have another version of autoconf. It may work, but is not
guaranteed to.
If you have problems, you may need to regenerate the build system
entirely.
To do so, use the procedure documented by the package, typically
`autoreconf'.
config/go.m4:10: error: m4_copy: won't overwrite defined macro:
AC_LANG_CONFTEST(Go)
config/go.m4:10: the top level
autom4te: m4 failed with exit status: 1
automake-1.11: autoconf failed with exit status: 1
make[6]: Failed to remake makefile `Makefile'.
make[6]: Leaving directory
`/home/srs/DEBs/gcc/gcc-4.9-4.9-20140322/build/i486-gnu/libgo'
...
Any idea on workarounds? Editing the old Makefile.in manually is not
nice, it is very unreadable. Too many things can go wrong :(
gcc-4.9: How to generate Makefile.in from a modified Makefile.am?
Hi,
With the recent changes of not using automake for the build, only
auto{re}conf I have problems generating an updated Makefile.in from a
modified Makfile.am. Source is gcc-4.9-4.9-20140322
Some failing attempts:
automake 1.14.1: (same with automake-1.11)
(cd src/libgo; automake -if)
aclocal.m4:16: warning: this file was generated for autoconf 2.64.
You have another version of autoconf. It may work, but is not
guaranteed to.
If you have problems, you may need to regenerate the build system
entirely.
To do so, use the procedure documented by the package, typically
`autoreconf'.
config/go.m4:10: error: m4_copy: won't overwrite defined macro:
AC_LANG_CONFTEST(Go)
config/go.m4:10: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
automake: error: autoconf failed with exit status: 1
autoconf 2.69:
(cd src/libgo;autoreconf -fi)
config/go.m4:10: error: m4_copy: won't overwrite defined macro:
AC_LANG_CONFTEST(Go)
config/go.m4:10: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
(cd src/libgo;autoreconf2.64 -fi)
configure.ac:22: error: Autoconf version 2.65 or higher is required
/usr/share/aclocal-1.14/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:22: the top level
autom4te2.64: /usr/bin/m4 failed with exit status: 63
aclocal: error: echo failed with exit status: 63
autoreconf2.64: aclocal failed with exit status: 63
Re: Hurd port for GCC Go
On Fri, 2013-06-14 at 16:42 +0200, Thomas Schwinge wrote: > Hi! > > On Thu, 13 Jun 2013 10:39:58 +0200, I wrote: > > On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell > > wrote: > > > On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote: > > > > On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell > > > > wrote: > > > > > Attached are patches to enable gccgo to build properly on Debian > > > > > GNU/Hurd on gcc-4.7 (4.7.3-4). > > > > > > > > Thanks! I've begun integrating them into my GCC tree (based on upstream > > > > GCC trunk, so some changes to be done to your patches), and get it in a > > > > state for Fotis to base his GSoC work on. ... > I have now pushed my working branch to tschwinge/t/hurd/go, and will > update this from time to time, both for integrating further changes (my > own as well as those that you send me), and merge in GCC trunk changes. > On that branch, use something like »git diff :/refs/top-bases/baseline« > to diff your working tree against the branch's base. When reviewing the > commit history on that branch, it may be helpful to exclude any bulk > merges from trunk, so use something like »git log HEAD ^origin/trunk«. > > Fotis and Svante, please base any futher work for the Hurd port for GCC > Go on that branch. Send patches by email, for now. > > > I got as far as having GCC Go compiling with GCC trunk sources; more to > > come later. Sorry, I'm not fluent in git. Which command to use to check out your branch tschwinge/t/hurd/go? Cannot find it at http://git.savannah.gnu.org/cgit/hurd/glibc.git/
Re: Hurd port for GCC Go (was: [PATCH] gccgo patch 0-2 (9))
Hi Thomas, On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote: > Hi! > > On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell > wrote: > > Attached are patches to enable gccgo to build properly on Debian > > GNU/Hurd on gcc-4.7 (4.7.3-4). > > Thanks! I've begun integrating them into my GCC tree (based on upstream > GCC trunk, so some changes to be done to your patches), and get it in a > state for Fotis to base his GSoC work on. Where to find your GCC tree? Also I had problems to tracing this commit: <http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=t/context_functions&id=018259d791f1ced4b2ced88c393cc74de15006ed>. I did not find anything related to context_functions at http://git.savannah.gnu.org/cgit/hurd/glibc.git/ Furthermore, for testing purposes, is it straight-forward to add the new functions getcontext/setcontext/makecontext*/movecontext to the debian sources, e.g. 2.13-39+hurd.3 or 2.17-6 (when that is released?). Where should these be placed in the tree: hurd/, sysdeps/mach/hurd/, elsewhere? And how to avoid the stubs at stdlib/ being compiled in?
Re: Inquiry about GCC Summer Of Code project idea.
Hi Fotis, I finally found my changes made so far for gccgo on a computer suffering double hard disk crashes. Hopefully most of the changes are available on the backup I found. As it looks they were not too extensive. I'll send a patch asap to the bug-hurd list, so you can continue from there (when you are accepted by Google/GNU) Good luck, Svante Signell On Fri, 2013-05-03 at 21:23 +0300, Fotis Koutoulakis wrote: > Hello! > > > First of all I would like to thank you everyone for your input. I > really appreciate it. > > > I would also like you to know that I managed to study the material > that you all have linked to (or that is generally available online on > the project's wikis of that matter) and I managed to come up with a > proposal for the project idea that got me hooked in the beginning. > > > A link to it can be found > here: > https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/nlightnfotis/1 > (I hope it is publicly visible, it seems to me it is). > > > Of course, I am more than open to comments/criticism as well as > clarifications. > > > Last but not least, I would like to thank you all for your time, as > well as grab the chance to apologize for my late proposal and my late > answer. > > > Sincerely, > Fotis Koutoulakis > > > On Tue, Apr 30, 2013 at 4:58 PM, Ian Lance Taylor > wrote: > On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge > wrote: > > > > On <http://darnassus.sceen.net/~hurd-web/open_issues/gccgo/> > I have just > > updated/posted a > getcontext/makecontext/setcontext/swapcontext usage > > analysis. This might constitute a "road block": the Hurd > currently does > > not allow for changing the stack of a process/thread. > Implemented a > > while before TLS/__thread variables came along, we have a > legacy > > threadvar mechanism implemented in glibc, which places > thread-local > > variables (errno, for example) at the bottom of a thread's > stack. Then, > > when switching the stack of a thread, glibc can't locate > these anymore, > > and "bad things" happen. This threadvar mechanism is > scheduled to go > > away (we do implement TLS by now), but when working on that > I hit "some > > issues" and have not yet found the time to continue. > > > > <http://darnassus.sceen.net/~hurd-web/open_issues/glibc/t/tls-threadvar/> > > and > > <http://news.gmane.org/find-root.php?message_id=% > 3c878vdyqht3%2Efsf%40kepler%2Eschwinge%2Ehomeip%2Enet%3e> > > have the details. > > > > Now, it seems the GCC Go port is implemented in a way that > makes > > extensive use of switching stacks. So until this threadvar > issue is > > resolved, there is probably no way to really proceed with > the GCC Go port > > for GNU Hurd -- unless maybe this stack switching could be > hacked around > > (Ian?), say, by limiting oneself to not using Goroutines and > similar > > "specials", and having a custom/minimal Go runtime startup. > > > Go does require switching stacks. A port of Go that doesn't > support > goroutines would be useless--nothing in the standard library > would > work. It might be possible to use pthread_getspecific and > friends > instead of TLS. > > Ian > > > > > -- > Fotis 'NlightNFotis' Koutoulakis > > > - "Non semper aestas erit; venit hiems." >
