Re: READ ME: updating mpc, mpfr, and eventually gmp
from matthew sporleder: > Can you take a step back and try using default tools (gcc) and a clean > dir (build.sh -r should do it, or just completely delete your obj and > tool dir first)? That's what I did originally when I failed several times, but I could try again, omitting -j. What about wiping out the src directory contents except CVS subdirectory, and downloading all anew? Keeping CVS subdirectory, I think I could cvs up as opposed to cvs co? I might also attempt to build for i386 before going back to amd64. Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Sun, Dec 15, 2013 at 8:05 PM, Thomas Mueller wrote: > > Matt Sporleder asks: > > > What is your build.sh command? > > > Did the build ever work? > > Latest build.sh command was > > ===> build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm -B > nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V HAVE_LLVM=yes -V > MKLIBCXX=yes -U -j 9 distribution kernel=GENERIC > > I don't use llvm/clang all the time. > > I was able to build 6.99.23 and before that. > > There was something in the original post on this thread about cleaning both > the tools and normal build directories. > > So maybe I need to clean out the tools directory > (/BETA1/netbsd-HEAD/usr/src/tools) except for the CVS subdirectory? > > Or maybe clear the entire /BETA1/netbsd-HEAD/usr/src directory and build > directories in /BETA1/netbsd-HEAD/usr but preserving log files and CVS > subdirectory? > > > Tom > Can you take a step back and try using default tools (gcc) and a clean dir (build.sh -r should do it, or just completely delete your obj and tool dir first)?
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Mon, Dec 16, 2013 at 12:49:23PM +, Thomas Mueller wrote: > > "clean out the tools directory" means to remove the -T directory, > > i.e. ../tooldir.amd64.llvm in your case. > > That's what I first thought, but I was beginning to wonder if I need to do > a new cvs checkout or update after deleting entire source tree. > > I've removed the tooldir before, but no recent success. What file-system are you using for the "/tmp" on your build machine? There have been bugs in tmpfs which have been recently fixed. So if you are using tmpfs please try without. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Sun, Dec 15, 2013 at 11:34:39AM +, Thomas Mueller wrote: > My /etc/mk.conf is geared to pkgsrc, I don't see anything relevant to > building the system. If you encapsulate the pkgsrc settings in a block like this ... .if defined(BSD_PKG_MK) [...] .endif ... you can be sure that they don't affect the base system build. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Sun, 15 Dec 2013, Thomas Mueller wrote: My /etc/mk.conf is geared to pkgsrc, I don't see anything relevant to building the system. Is all the pkgsrc-related stuff protected by ".if defined(BSD_PKG_MK)" ? If not, then it will be used for a system build too. There was a suggestion to set -std=c++0x or -std=gnu0x; I could use 11 in place of 0x but don't know where to put it. In a special make.conf? Or build.sh command line? I was not joking when I referred to you a web page about how to ask questions. There are probably people who might be able to help you, but just can't understand what problem you are encountering. Please read and follow the advice in "How to ask questions the smart way" and "How to report bugs effectively" . Please try to keep "it doesn't build", "it crashes", "it doesn't work properly", and "I need help" in separate messages, with a different Subject line for each topic. Please include enough relevant details in your messages. For example: What does "Subject: READ ME: updating mpc, mpfr, and eventually gmp" have to do with any of this? If "there was a suggestion" to do something, then where was the suggestion made? (Link to it if possible.) NetBSD can be built on many platforms. There are sometimes problems, but they are usually fixed or at least understood quite quickly. If you have problems that other people don't, then the problems are likely to be due to differences between your system and other systems. Please start by removing as many of those differences as possible. Perform a clean build with no special options. If that doesn't work, then report the errors. If it works, then start adding your special options, just a few at a time so you have a chance of knowing which options cause problems. A clean build with no special options means at least this: * clean source tree, with no extra or modified files (it might be easiest to delete everything and check out a clean source tree); * no left over output files or temporary files from previous build attempts, such as TOOLDIR, RELEASEDIR, DESTDIR, or obj dirs; * no /etc/mk.conf or similar file; * no -V options passed to build.sh; * no environment variables that are intended to affect the build. --apb (Alan Barrett)
Re: READ ME: updating mpc, mpfr, and eventually gmp
from John Nemeth: > "clean out the tools directory" means to remove the -T directory, > i.e. ../tooldir.amd64.llvm in your case. That's what I first thought, but I was beginning to wonder if I need to do a new cvs checkout or update after deleting entire source tree. I've removed the tooldir before, but no recent success. Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Dec 16, 1:05am, "Thomas Mueller" wrote: } Subject: Re: READ ME: updating mpc, mpfr, and eventually gmp } Matt Sporleder asks: } } > What is your build.sh command? } } > Did the build ever work? } } Latest build.sh command was } } ===> build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm -B nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V HAVE_LLVM=yes -V MKLIBCXX=yes -U -j 9 distribution kernel=GENERIC } } I don't use llvm/clang all the time. } } I was able to build 6.99.23 and before that. } } There was something in the original post on this thread about } cleaning both the tools and normal build directories. } } So maybe I need to clean out the tools directory } (/BETA1/netbsd-HEAD/usr/src/tools) except for the CVS subdirectory? "clean out the tools directory" means to remove the -T directory, i.e. ../tooldir.amd64.llvm in your case. }-- End of excerpt from "Thomas Mueller"
Re: READ ME: updating mpc, mpfr, and eventually gmp
Matt Sporleder asks: > What is your build.sh command? > Did the build ever work? Latest build.sh command was ===> build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm -B nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V HAVE_LLVM=yes -V MKLIBCXX=yes -U -j 9 distribution kernel=GENERIC I don't use llvm/clang all the time. I was able to build 6.99.23 and before that. There was something in the original post on this thread about cleaning both the tools and normal build directories. So maybe I need to clean out the tools directory (/BETA1/netbsd-HEAD/usr/src/tools) except for the CVS subdirectory? Or maybe clear the entire /BETA1/netbsd-HEAD/usr/src directory and build directories in /BETA1/netbsd-HEAD/usr but preserving log files and CVS subdirectory? Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Dec 15, 2013, at 6:34 AM, "Thomas Mueller" wrote: >>> This is in particular a sudden inability to build NetBSD-current from >>> source. > >> Those happen, and are usually fixed by reading UPDATING and doing what it >> recommends (or in the case of obvious breaks, waiting a day, updating and >> running the build again). > >> -current is built by umpteen people (like eg me), and on current and >> releases and .. my Azubi even managed to build release on Linux with very >> little coaching, it's not hard, usually. > >> If you can't get it built using build.sh with fairly simple mk.conf -ever- >> (and not just "this one checkout"), there's something wrong with your >> machine or installation. > >>> Until I see information about an update of base gcc, I don't plan to try >>> any more using base gcc. I could try to build gcc-aux or gcc48 from pkgsrc >>> and use that, if build is successful. I think I could set HOST_CC and >>> HOST_CXX to tell the build to use that in place of base gcc. > >> That is IMO asking for interesting times. > >> regards, >>spz > > My /etc/mk.conf is geared to pkgsrc, I don't see anything relevant to > building the system. > > There was a suggestion to set -std=c++0x or -std=gnu0x; I could use 11 in > place of 0x but don't know where to put it. > > In a special make.conf? Or build.sh command line? > > I think I may need to wait more than a day on NetBSD-current. > > I just got through a successful "make buildworld" on FreeBSD 10-stable > (prerelease). > > I see on http://releng.netbsd.org/cgi-bin/builds.cgi > > in the build.sh command line, there is a reference to > /home/builds/etc/make.conf > > but no clue what's in this make.conf. > > Knowing that might possibly be helpful. > >> Given that it runs at the end of the build, it probably didn't. It >> seems almost certain that you have bad hardware. > > -- >> David A. Holland > > Or NetBSD is not fit for my hardware. FreeBSD is much stabler, I don't get > the comical crashes that I get with NetBSD. > > If with NetBSD-current I have USB keyboard and mouse and use more than one > virtual terminal, keyboard is likely to stop functioning, though not > immediately. > > Usually I can get the keyboard back by unplugging the mouse, but once a few > hours ago, the system crashed with a spew of green trouble messages > ehci-related (meaning USB 2.0). > > Tom What is your build.sh command? Did the build ever work? >
Re: READ ME: updating mpc, mpfr, and eventually gmp
> >This is in particular a sudden inability to build NetBSD-current from source. > Those happen, and are usually fixed by reading UPDATING and doing what it > recommends (or in the case of obvious breaks, waiting a day, updating and > running the build again). > -current is built by umpteen people (like eg me), and on current and > releases and .. my Azubi even managed to build release on Linux with very > little coaching, it's not hard, usually. > If you can't get it built using build.sh with fairly simple mk.conf -ever- > (and not just "this one checkout"), there's something wrong with your > machine or installation. > >Until I see information about an update of base gcc, I don't plan to try > >any more using base gcc. I could try to build gcc-aux or gcc48 from pkgsrc > >and use that, if build is successful. I think I could set HOST_CC and > >HOST_CXX to tell the build to use that in place of base gcc. > That is IMO asking for interesting times. > regards, > spz My /etc/mk.conf is geared to pkgsrc, I don't see anything relevant to building the system. There was a suggestion to set -std=c++0x or -std=gnu0x; I could use 11 in place of 0x but don't know where to put it. In a special make.conf? Or build.sh command line? I think I may need to wait more than a day on NetBSD-current. I just got through a successful "make buildworld" on FreeBSD 10-stable (prerelease). I see on http://releng.netbsd.org/cgi-bin/builds.cgi in the build.sh command line, there is a reference to /home/builds/etc/make.conf but no clue what's in this make.conf. Knowing that might possibly be helpful. > Given that it runs at the end of the build, it probably didn't. It > seems almost certain that you have bad hardware. -- > David A. Holland Or NetBSD is not fit for my hardware. FreeBSD is much stabler, I don't get the comical crashes that I get with NetBSD. If with NetBSD-current I have USB keyboard and mouse and use more than one virtual terminal, keyboard is likely to stop functioning, though not immediately. Usually I can get the keyboard back by unplugging the mouse, but once a few hours ago, the system crashed with a spew of green trouble messages ehci-related (meaning USB 2.0). Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
Hi,
mueller6...@bellsouth.net ("Thomas Mueller") writes:
>from Paul Goyette:
>> I've had intermittent similar problems with NetBSD for at least three
>> years now. I have no idea what the problem is, though. I've
>> suspected some sort of memory corruption, but was never able to make
>> any progress in tracking it down.
>It could be a corruption or bug in NetBSD. I've come to expect these
>things with NetBSD.
>This is in particular a sudden inability to build NetBSD-current from source.
Those happen, and are usually fixed by reading UPDATING and doing what it
recommends (or in the case of obvious breaks, waiting a day, updating and
running the build again).
-current is built by umpteen people (like eg me), and on current and
releases and .. my Azubi even managed to build release on Linux with very
little coaching, it's not hard, usually.
If you can't get it built using build.sh with fairly simple mk.conf -ever-
(and not just "this one checkout"), there's something wrong with your
machine or installation.
>Until I see information about an update of base gcc, I don't plan to try
>any more using base gcc. I could try to build gcc-aux or gcc48 from pkgsrc
>and use that, if build is successful. I think I could set HOST_CC and
>HOST_CXX to tell the build to use that in place of base gcc.
That is IMO asking for interesting times.
regards,
spz
--
s...@serpens.de (S.P.Zeidler)
Re: READ ME: updating mpc, mpfr, and eventually gmp
> > Last failure was on gmp, which later built successfully as a dependency > > from pkgsrc. > ah, i see the confusion here. > my post was *only* about the in-tree gmp/mpfr/mpc that we use > for the in-tree gcc and for building netbsd, and has nothing > to do with the versions in pkgsrc. i don't maintain the pkgsrc > versions and i don't know about them beyond installing sometimes. > build.sh generally does not use any locally installed software > besidse $CC, $CXX and -lz, and the latter really should be fixed. > we only want to depend upon local C and C++ compiler (and other > sundry items, but only for bootstrapping the real tools.) > .mrg. I noticed that the current base gmp/mpfr/mpc were the same versions as in pkgsrc. though the latter package in pkgsrc is listed as mpcomplex in category math. I tried to cross-compile NetBSD-current from FreeBSD-current with clang, but that failed. It wasn't really supposed to work anyway. Next is to try building from NetBSD-6.1_STABLE if that boots. If that fails, then FreeBSD 9.2_STABLE with gcc-aux. Tom
re: READ ME: updating mpc, mpfr, and eventually gmp
> Last failure was on gmp, which later built successfully as a dependency from > pkgsrc. ah, i see the confusion here. my post was *only* about the in-tree gmp/mpfr/mpc that we use for the in-tree gcc and for building netbsd, and has nothing to do with the versions in pkgsrc. i don't maintain the pkgsrc versions and i don't know about them beyond installing sometimes. build.sh generally does not use any locally installed software besidse $CC, $CXX and -lz, and the latter really should be fixed. we only want to depend upon local C and C++ compiler (and other sundry items, but only for bootstrapping the real tools.) .mrg.
re: READ ME: updating mpc, mpfr, and eventually gmp
On Mon, 2 Dec 2013, matthew green wrote: > > This is in particular a sudden inability to build NetBSD-current from > > source. > > could you be more explicit about what is failing? there > shouldn't be any issues remaining, but some types of > failure modes require cleaning out your build/obj trees, > and won't go away with any amount of cvs update. Check your limits. Newer versions of gcc tend to use more memory for optimization. If the cc1 process hits a data limit and is killed off you might get that sort of error from the compiler driver. Eduardo
Re: READ ME: updating mpc, mpfr, and eventually gmp
> > This is in particular a sudden inability to build NetBSD-current from > > source. > could you be more explicit about what is failing? there > shouldn't be any issues remaining, but some types of > failure modes require cleaning out your build/obj trees, > and won't go away with any amount of cvs update. > .mrg. Yes, I did wipe out the obj and tools directories. Last failure was on gmp, which later built successfully as a dependency from pkgsrc. I was stopped on lang/gcc-aux but succeeded with lang/gcc48. gnatgcc: error: /usr/pkg/lib/libiconv.a: no such file or directory libiconv was not listed as a dependency for gcc-aux. I found converters/libiconv with lib/libiconv.la in the PLIST, not quite the same as libiconv.a . I guess I need to mention this on pkgsrc-us...@netbsd.org . Now, how to tell the build system to use this gcc48 in place of base gcc? I think I would have to set HOST_CC and HOST_CXX. Command line or /etc/mk.conf? I now have gmp-5.1.3, gmp 3.1.2 and mpcomplex-1.0.1 from pkgsrc, how do I tell the system build not to build these redundantly? I guess math/mpcomplex is called mpcomplex instead of mpc to avoid conflict with audio/mpc. I guess if the base gcc could build mail/mpop, mail/msmtp, www/lynx, www/links-gui and lang/gcc48, it was not trashed. Maybe there is libiconv.a in converters/libiconv? pkg info -l libiconv shows libiconv-1.14_1: /usr/local/bin/iconv /usr/local/include/iconv.h /usr/local/include/libcharset.h /usr/local/include/localcharset.h /usr/local/lib/charset.alias /usr/local/lib/libcharset.a /usr/local/lib/libcharset.la /usr/local/lib/libcharset.so /usr/local/lib/libcharset.so.1 /usr/local/lib/libiconv.a /usr/local/lib/libiconv.la /usr/local/lib/libiconv.so /usr/local/lib/libiconv.so.3 /usr/local/man/man1/iconv.1.gz /usr/local/man/man3/iconv.3.gz /usr/local/man/man3/iconv_close.3.gz /usr/local/man/man3/iconv_open.3.gz /usr/local/man/man3/iconv_open_into.3.gz /usr/local/man/man3/iconvctl.3.gz /usr/local/share/doc/libiconv/iconv.1.html /usr/local/share/doc/libiconv/iconv.3.html /usr/local/share/doc/libiconv/iconv_close.3.html /usr/local/share/doc/libiconv/iconv_open.3.html /usr/local/share/doc/libiconv/iconv_open_into.3.html /usr/local/share/doc/libiconv/iconvctl.3.html but that is on my FreeBSD installation, from FreeBSD ports. Tom
re: READ ME: updating mpc, mpfr, and eventually gmp
> This is in particular a sudden inability to build NetBSD-current from source. could you be more explicit about what is failing? there shouldn't be any issues remaining, but some types of failure modes require cleaning out your build/obj trees, and won't go away with any amount of cvs update. .mrg.
Re: READ ME: updating mpc, mpfr, and eventually gmp
from Paul Goyette: > I've had intermittent similar problems with NetBSD for at least three > years now. I have no idea what the problem is, though. I've > suspected some sort of memory corruption, but was never able to make > any progress in tracking it down. It could be a corruption or bug in NetBSD. I've come to expect these things with NetBSD. This is in particular a sudden inability to build NetBSD-current from source. Until I see information about an update of base gcc, I don't plan to try any more using base gcc. I could try to build gcc-aux or gcc48 from pkgsrc and use that, if build is successful. I think I could set HOST_CC and HOST_CXX to tell the build to use that in place of base gcc. I could also try to cross-build from FreeBSD using gcc-aux from ports or from NetBSD 6.1_STABLE if that boots. Base gcc in FreeBSD through 9.x is 4.2.1 because that is the last release before gcc went to GPLv3. So there are things I can try before putting it on the back shelf. Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
I've had intermittent similar problems with NetBSD for at least three years now. I have no idea what the problem is, though. I've suspected some sort of memory corruption, but was never able to make any progress in tracking it down. On Sun, 1 Dec 2013, Thomas Mueller wrote: Base gcc hasn't been updated. Updating mpc, mpfr, and gmp are part of the preparation for update base gcc. "Segfault due to internal compiler error" is often due to bad memory. You might want to run pkgsrc/sysutils/memtestplus. I tried again, this time noticed that the choking point was in libgmp. So maybe it was the new stuff: mpc, mpfr and gmp. Maybe not compatible with existing gcc, or maybe an error in the code. Things I could try would be to try to build, from pkgsrc, gcc-aux or a newer version of gcc. Or maybe from NetBSD 6.1_STABLE if that boots, but then I have the same old(?) gcc. Another possibility would be to do the same from FreeBSD, using gcc-aux or a newer gcc from ports. Tom !DSPAM:529b9c96211091274116419! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: READ ME: updating mpc, mpfr, and eventually gmp
> Base gcc hasn't been updated. Updating mpc, mpfr, and gmp > are part of the preparation for update base gcc. "Segfault due to > internal compiler error" is often due to bad memory. You might > want to run pkgsrc/sysutils/memtestplus. I tried again, this time noticed that the choking point was in libgmp. So maybe it was the new stuff: mpc, mpfr and gmp. Maybe not compatible with existing gcc, or maybe an error in the code. Things I could try would be to try to build, from pkgsrc, gcc-aux or a newer version of gcc. Or maybe from NetBSD 6.1_STABLE if that boots, but then I have the same old(?) gcc. Another possibility would be to do the same from FreeBSD, using gcc-aux or a newer gcc from ports. Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
> Base gcc hasn't been updated. Updating mpc, mpfr, and gmp > are part of the preparation for update base gcc. "Segfault due to > internal compiler error" is often due to bad memory. You might > want to run pkgsrc/sysutils/memtestplus. Or it could be a bug in the NetBSD system. These happen more in NetBSD than FreeBSD. Note the "spurious reboot" thread. Memory was bad only on some NetBSD installations. Maybe the bug that bites me is unrelated to the topic of the thread. I could try building something from pkgsrc, such as lynx or a newer gcc, gcc-aux or gnat-aux or try rebuilding/cross-compiling from FreeBSD, but not using something so outdated as the base-system gcc-4.2.1. Even better would be if I could get the wi-fi working in FreeBSD. Tom
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Nov 29, 6:42am, "Thomas Mueller" wrote: } } > this is a warning that builds might fail due to the updated mpc } > and mpfr sources i've imported. you might need to clean both } > the tools and normal build dirs for them. } } > please send-pr or send me email if you see issues. thanks! } } I cleaned the tools and obj dirs, and haven't been able to rebuild } NetBSD-current amd64 or i386: } } Segfault due to internal compiler error. } } This happened in the current round about a week ago, then a couple } days, again less than an hour ago. } } Is something gone bad with an update to base gcc? I did a recent } update to NetBSD 6.1_STABLE successfully. Base gcc hasn't been updated. Updating mpc, mpfr, and gmp are part of the preparation for update base gcc. "Segfault due to internal compiler error" is often due to bad memory. You might want to run pkgsrc/sysutils/memtestplus. }-- End of excerpt from "Thomas Mueller"
Re: READ ME: updating mpc, mpfr, and eventually gmp
> this is a warning that builds might fail due to the updated mpc > and mpfr sources i've imported. you might need to clean both > the tools and normal build dirs for them. > please send-pr or send me email if you see issues. thanks! > .mrg. I cleaned the tools and obj dirs, and haven't been able to rebuild NetBSD-current amd64 or i386: Segfault due to internal compiler error. This happened in the current round about a week ago, then a couple days, again less than an hour ago. Is something gone bad with an update to base gcc? I did a recent update to NetBSD 6.1_STABLE successfully. If so, I may not be able to build anything else, but have some options including cross-compiling from FreeBSD, using a gcc from ports that would be newer than base-system gcc-4.2.1. Or I could build from NetBSD 6.1_STABLE: I just checked http://releng.netbsd.org/builds/HEAD/201311280720Z/amd64.build for build host. I could even try to build gcc-aux or gnat-aux (not sure of the difference between those two) and use that in place of base gcc. Tom
