Building gcc-4.6.0-RC-20110314 on solaris8 (with gcc-3.3.2 preinstalled) fails with the following message: Can't locate File/Glob.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .) at /tmp/lcl/tmp/gcc/gcc-4.6.0-RC-20110314/libgomp/../contrib/make_sunver.pl line 19. BEGIN failed--compilation aborted at /tmp/lcl/tmp/gcc/gcc-4.6.0-RC-20110314/libgomp/../contrib/make_sunver.pl line 19. make[5]: *** [libgomp.map-sun] Error 1 Indeed, there is no Glob.pm in the folders indicated. Under Solaris2.10 (where we have /usr/perl5/5.8.4/lib/sun4-solaris-64int/File/Glob.pm) the build is ok up to the end. With GCC 4.5.2 no build problem with Solaris2.8 or Solaris2.10.
As documented in install.texi. @item Perl version 5.6.1 (or later) Necessary when regenerating @file{Makefile} dependencies in libiberty. Necessary when regenerating @file{libiberty/functions.texi}. Necessary when generating manpages from Texinfo manuals. Necessary when targetting Darwin, building @samp{libstdc++}, and not using @option{--disable-symvers}. Necessary when targetting Solaris 2 with Sun @command{ld}, building @samp{libstdc++}, and not using @option{--disable-symvers}. A helper scripts needs @samp{Glob.pm}, which is missing from @command{perl} 5.005 included in Solaris@tie{}8. The bundled @command{perl} in Solaris@tie{}9 and up works. Used by various scripts to generate some files included in SVN (mainly Unicode-related and rarely changing) from source tables.
Oh, thank you for pointing, but i should not be concerned since i didn't modify the sources (i simply include gmp/mpfr/mpc within the source directory tree). Perhaps this is a side-effect because two files have the same mtime (that will disappear with the final gcc-4.6.0)?
But are you using Sun ld, building libstdc++, and not using --disable-symvers?
Sun ld yes, libstdc++ i suppose (although i was caught in libgomp) and --disable-symvers is the next thing i'm going to try. Still not convinced that i am "modifying GCC".
(In reply to comment #4) > Sun ld yes, libstdc++ i suppose (although i was caught in libgomp) and > --disable-symvers is the next thing i'm going to try. > > Still not convinced that i am "modifying GCC". You're not, but I think the prerequisites docs are misleading. The Perl requirement shouldn't be in the "modifying GCC" section. Perl is required when doing any of: * regenerating Makefile dependencies in libiberty. * regenerating libiberty/functions.texi. * generating manpages from Texinfo manuals. * targetting Darwin, building `libstdc++', and not using --disable-symvers * targetting Solaris 2 with Sun ld, building `libstdc++', and not using --disable-symvers. Only the first two belong under the "modifying GCC" heading. You are targetting Solaris2 with Sun ld, building libstdc++ and not using --disable-symvers, so Perl (and Glob.pm) is required.
I did try with --disable-symvers with no effect. Indeed, have a look into libgomp/configure: lines 15784-15798 completely cover what you may have set within the command line. I changed line 15793 into "enable_symvers=no" and it seems far better: at least "Configuring stage 1 in ..../libgomp" has now finished OK.
Conclusion for the build under Solaris2.8, from my point of view, and compared to the build of gcc-4.5.2 (languages C and C++): - as perl 5.6.1 (or higher) is not directly available under solaris2.8 (and i would prefer not to install it), the "Installation instructions" recommend to use --disable-symvers (so we'll also abandon symbol versioning) - --disable-symvers does not work for the sub-folder libgomp (see previous comment). Instead, you have to replace (manually) "enable_symvers=sun" with "enable_symvers=no" in libgomp/configure - --disable-symvers works (presumably) for the sub-folder libstdc++-v3 - --disable-symvers has simply no effect in the sub-folder libssp. However, you obtain the desired result if you replace (manually) "ssp_use_symver=sun" with "ssp_use_symver=no" in libssp/configure With these pre-bootstrap steps, it should work. After many tests, the resulting compiler seems working and usable. For a cleaner gcc-4.6.0.tar.bz2, feel free to upgrade the Installation instructions (see also above), and/or libgomp/configure and/or libssp/configure.
what about --enable-symvers=no ? you shouldn't need to edit configure Rainer, any ideas/comments?
actually I see you're right, libgomp/configure doesn't allow symvers to be disabled for Solaris. Shouldn't there be a test like this before setting it? if test x$enable_symvers = xyes ; then
> --- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-03-17 13:58:19 UTC --- > actually I see you're right, libgomp/configure doesn't allow symvers to be > disabled for Solaris. Shouldn't there be a test like this before setting it? > if test x$enable_symvers = xyes ; then Indeed, just as in libstdc++-v3/configure. That's the `beauty' of having (at least) two different ways of configuring symbol versioning in tree. Rainer
> --- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-03-17 13:55:16 UTC --- > what about --enable-symvers=no ? > you shouldn't need to edit configure Of course not, that's clearly a bug. It would be even better to autodetect this condition, or avoid it by either using glob from the Perl core (which exists even in 5.005) or finally dropping Solaris 8 support, which is ancient history by now ;-) I'm uncertain that we want to touch any of this so late in the 4.6.0 release cycle. The docs are inaccurate in that make_sunver.pl is required for all versioned libraries, i.e. libgomp, libgfortran, libquadmath, libstdc++, and libjava, and of course in that having sufficiently recent perl is a requirement for everyone building GCC even from tarballs. I don't really understand Denis' reluctance to build a newer perl as a prerequisite: anyone who undertakes to build GCC himself needn't be afraid from Perl :-) Rainer
(In reply to comment #11) > I don't really understand Denis' reluctance to build a newer perl as a > prerequisite No problem with perl itself, i've a working perl-5.13.10 compiled on this solaris8. It is that i try to build with as few prerequisites as possible: currently, with only an old gcc and an old make (borrowed from sunfreeware, you must know that on Solaris no default C compiler is installed) i am able to build the last GCC, then the last GNU make, then the complete tool chain (patch, m4, gzip, bison, tar, coreutils etc.) up to date. I would have to also find a working binary perl, no big deal but if we can avoid that using a few sed commands, that's perfect.
> --- Comment #12 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-17 14:43:35 UTC --- > (In reply to comment #11) >> I don't really understand Denis' reluctance to build a newer perl as a >> prerequisite > No problem with perl itself, i've a working perl-5.13.10 compiled on this > solaris8. It is that i try to build with as few prerequisites as possible: > currently, with only an old gcc and an old make (borrowed from sunfreeware, > you must know that on Solaris no default C compiler is installed) i am able > to build the last GCC, then the last GNU make, then the complete tool chain > (patch, m4, gzip, bison, tar, coreutils etc.) up to date. I see, but on the other hand this will be a fairly uncommon undertaking. Given that Solaris 8 is 11 years old by now, you will only rarely have a minimal software environment and suddenly develop the desire to bring that completely up to date :-) Btw., what's your reason to still be running Solaris 8? I'm the Solaris GCC maintainer and seriously consider to deprecate it for GCC 4.7. > I would have to also find a working binary perl, no big deal but if we can > avoid that using a few sed commands, that's perfect. Certainly not: either I can make make_sunver.pl work with the core perl glob, or the --disable-symver option will be made to work properly. Rainer
(In reply to comment #13) > I see, but on the other hand this will be a fairly uncommon undertaking. You must know that the process is highly automatized, and, most importantly, that it is shared with several other (and more useful) environments, including Solaris10, Linux, cygwin and darwin ppc (by the way, up to now, only darwin has failed to build 4.6.0-RC, i think it is due to obscure altivec reasons). > Btw., what's your reason to still be running Solaris 8? I'm the Solaris > GCC maintainer and seriously consider to deprecate it for GCC 4.7. Here we still have many Solaris8's working, with support from Sun/Oracle up to March 2012 (http://www.oracle.com/us/support/library/lifetime-support-hardware-os-337182.pdf). You will not be blamed if GCC support is discontinued (ie removed) after that. Deprecation is ok for GCC 4.7. > > I would have to also find a working binary perl, no big deal but if we can > > avoid that using a few sed commands, that's perfect. > Certainly not: either I can make make_sunver.pl work with the core perl > glob, or the --disable-symver option will be made to work properly. It would be bad use of your time if you do this only for me. On the other hand, i successfully built 4.6.0-RC on Solaris 10, but only after having performed sed -e 's|complex\.h|nonexistent&|g' inside the file mpc/configure installed in the source tree (from mpc-0.9.tar.gz). Perhaps only a short sentence in "Host/target specific installation notes" is enough.
>> Btw., what's your reason to still be running Solaris 8? I'm the Solaris >> GCC maintainer and seriously consider to deprecate it for GCC 4.7. > Here we still have many Solaris8's working, with support from Sun/Oracle up to > March 2012 > (http://www.oracle.com/us/support/library/lifetime-support-hardware-os-337182.pdf). I know, but regular support has ended in March 2009 alreay, this one is only by special arrangement. E.g., Solaris 8 patches are only available anymore with a special contract. > You will not be blamed if GCC support is discontinued (ie > removed) after that. Deprecation is ok for GCC 4.7. I'll probably do so soon so people get a heads-up. >> > I would have to also find a working binary perl, no big deal but if we can >> > avoid that using a few sed commands, that's perfect. >> Certainly not: either I can make make_sunver.pl work with the core perl >> glob, or the --disable-symver option will be made to work properly. > It would be bad use of your time if you do this only for me. On the other hand, Not really: this is a stupid bug in a documented feature and supposed to work. A fix shouldn't be hard, but probably after 4.6.0 is released. > i successfully built 4.6.0-RC on Solaris 10, but only after having performed > sed -e 's|complex\.h|nonexistent&|g' inside the file mpc/configure installed > in the source tree (from mpc-0.9.tar.gz). That's part your fault and part ours: while install.texi states `MPC Library version 0.8.1 (or later)', later versions are rarely tested and often break, so it's best to stay with those exact versions. We need to improve the install docs in this regard. > Perhaps only a short sentence in "Host/target specific installation notes" > is enough. I'm reluctant to document every corner case in install.texi: nobody will read this and important stuff gets missed. This PR will probably have to do. Rainer
(In reply to comment #15) > > i successfully built 4.6.0-RC on Solaris 10, but only after having performed > > sed -e 's|complex\.h|nonexistent&|g' inside the file mpc/configure installed > > in the source tree (from mpc-0.9.tar.gz). > That's part your fault and part ours: while install.texi states `MPC > Library version 0.8.1 (or later)', later versions are rarely tested and > often break, so it's best to stay with those exact versions. We need to > improve the install docs in this regard. If the selection of a version is not so important, please consider including the mpc-0.8.1 folder directly in the source tree from the beginning and don't discuss this subject anymore in the installation instructions (apart from thanking and copyright reasons). Perhaps the gmp/mpfr/mpc people would not prefer this way though.
>> That's part your fault and part ours: while install.texi states `MPC >> Library version 0.8.1 (or later)', later versions are rarely tested and >> often break, so it's best to stay with those exact versions. We need to >> improve the install docs in this regard. > If the selection of a version is not so important, please consider including > the mpc-0.8.1 folder directly in the source tree from the beginning and don't > discuss this subject anymore in the installation instructions (apart from > thanking and copyright reasons). Perhaps the gmp/mpfr/mpc people would not > prefer this way though. No, we don't want to go down that route for unmodified upsteam packages. This is FSF policy, btw., and not this issue. Rainer
Author: ro Date: Mon Mar 21 12:09:28 2011 New Revision: 171218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171218 Log: PR bootstrap/48135 * doc/install.texi (Prerequisites): Move Perl to build requirements. Always necessary on Solaris 2 with Sun ld. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
Author: ro Date: Mon Mar 21 12:10:30 2011 New Revision: 171219 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171219 Log: PR bootstrap/48135 * doc/install.texi (Prerequisites): Move Perl to build requirements. Always necessary on Solaris 2 with Sun ld. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/doc/install.texi
Author: ro Date: Mon Mar 21 12:12:19 2011 New Revision: 171221 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171221 Log: PR bootstrap/48135 * doc/install.texi (Prerequisites): Move jar etc. up. Explain support library version requirements. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
Author: ro Date: Mon Mar 21 12:13:26 2011 New Revision: 171222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171222 Log: PR bootstrap/48135 * doc/install.texi (Prerequisites): Move jar etc. up. Explain support library version requirements. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/doc/install.texi
Author: ro Date: Mon Mar 21 12:17:10 2011 New Revision: 171223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171223 Log: contrib: PR bootstrap/48135 * make_sunver.pl: Don't use File::Glob. gcc: PR bootstrap/48135 * doc/install.texi (Prerequisites, Perl): Remove Glob.pm reference. Solaris 8 perl works. Modified: trunk/contrib/ChangeLog trunk/contrib/make_sunver.pl trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
Author: ro Date: Mon Mar 21 12:24:17 2011 New Revision: 171224 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171224 Log: libgfortran: PR bootstrap/48135 * configure.ac (gfortran_use_symver): Handle --disable-symvers. * configure: Regenerate. libgomp: PR bootstrap/48135 * acinclude.m4 (enable_symvers): Handle --disable-symvers. * configure: Regenerate. libjava: PR bootstrap/48135 * configure.ac (libjava_cv_anon_version_script): Handle --disable-symvers. * configure: Regenerate. libquadmath: PR bootstrap/48135 * configure.ac (quadmath_use_symver): Handle --disable-symvers. * configure: Regenerate. libssp: PR bootstrap/48135 * configure.ac (ssp_use_symver): Handle --disable-symvers. * configure: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgomp/ChangeLog trunk/libgomp/acinclude.m4 trunk/libgomp/configure trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac trunk/libquadmath/ChangeLog trunk/libquadmath/configure trunk/libquadmath/configure.ac trunk/libssp/ChangeLog trunk/libssp/configure trunk/libssp/configure.ac
Thanks for you report. I believe all your issues are now resolved, either by improving the documentation, fixing the problem, or both :-) Some of the fixes even made it into 4.6.0, while others will appear in 4.6.1 or 4.7.0 only.
Author: ro Date: Mon Mar 28 17:09:27 2011 New Revision: 171617 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171617 Log: libgfortran: backport from mainline: 2011-03-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR bootstrap/48135 * configure.ac (gfortran_use_symver): Handle --disable-symvers. * configure: Regenerate. libgomp: backport from mainline: 2011-03-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR bootstrap/48135 * acinclude.m4 (enable_symvers): Handle --disable-symvers. * configure: Regenerate. libjava: backport from mainline: 2011-03-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR bootstrap/48135 * configure.ac (libjava_cv_anon_version_script): Handle --disable-symvers. * configure: Regenerate. libquadmath: backport from mainline: 2011-03-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR bootstrap/48135 * configure.ac (quadmath_use_symver): Handle --disable-symvers. * configure: Regenerate. libssp: backport from mainline: 2011-03-21 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> PR bootstrap/48135 * configure.ac (ssp_use_symver): Handle --disable-symvers. * configure: Regenerate. Modified: branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/configure branches/gcc-4_6-branch/libgfortran/configure.ac branches/gcc-4_6-branch/libgomp/ChangeLog branches/gcc-4_6-branch/libgomp/acinclude.m4 branches/gcc-4_6-branch/libgomp/configure branches/gcc-4_6-branch/libjava/ChangeLog branches/gcc-4_6-branch/libjava/configure branches/gcc-4_6-branch/libjava/configure.ac branches/gcc-4_6-branch/libquadmath/ChangeLog branches/gcc-4_6-branch/libquadmath/configure branches/gcc-4_6-branch/libquadmath/configure.ac branches/gcc-4_6-branch/libssp/ChangeLog branches/gcc-4_6-branch/libssp/configure branches/gcc-4_6-branch/libssp/configure.ac
Just for the record: gcc-4.7-20111210 works (with --enable-obsolete of course).