Re: Trouble doing bootstrap
On Thu, 14 Oct 2010, Ian Lance Taylor wrote: > Ralf Wildenhues writes: > > >> 2) If we did use libtool to build gcc, then, yes, I would be concerned > >>about the relinking issue. > > > > Why? Because of 'make install' run as root? Any other reasons? > > Any install process which is more complex than cp is a matter for > concern. It should only be undertaken for a really good reason. And we should be aiming to make the GCC build, test and install process simpler: install to a staging directory during build, use the built-in relocatability in building target libraries and running testsuites rather than needing to pass long sequences of -B etc. options at those stages, and just copy the staging directory for final installation. (It's nasty that not just the build systems of the various toolchain components but upstream DejaGnu itself has hardcoded information about how bits of the tools can locate each other in their build directories. Nothing should ever need to know that; the staging install code should just put things so that they can find each other automatically.) -- Joseph S. Myers jos...@codesourcery.com
Re: Trouble doing bootstrap
On Thu, Oct 14, 2010 at 12:47:34PM -0700, Ian Lance Taylor wrote: > > It is not so unlikely that multiple instances of cc1, cc1plus, and f951 > > are running simultaneously. Granted, I haven't done any measurements. > > Most projects are written in only one language. Sure, there may be > cases where cc1 and cc1plus are running simultaneously. But I suspect > those cases are relatively unlikely. In particular, I suspect that the > gain when that happens, which is really quite small, is less than the > cost of using a shared library. Needless to say, I also have not done > any measurements. Projects that use C in some places and C++ in others are common, so a simultaneous cc1 and cc1plus run will often occur with parallel builds. However, the mp math libraries are relatively small compared to the size of cc1 or cc1plus so the memory savings from having one copy instead of two are minimal.
Re: Trouble doing bootstrap
Ralf Wildenhues writes: >> 2) If we did use libtool to build gcc, then, yes, I would be concerned >>about the relinking issue. > > Why? Because of 'make install' run as root? Any other reasons? Any install process which is more complex than cp is a matter for concern. It should only be undertaken for a really good reason. >> 3) Shared libraries are less efficient. You get some efficiency back if >>the libraries are in fact shared by multiple different executables >>running simultaneously. But in this case it is relatively unlikely >>that gmp, mpfr, and mpc will actually be used by any executable other >>than gcc. > > It is not so unlikely that multiple instances of cc1, cc1plus, and f951 > are running simultaneously. Granted, I haven't done any measurements. Most projects are written in only one language. Sure, there may be cases where cc1 and cc1plus are running simultaneously. But I suspect those cases are relatively unlikely. In particular, I suspect that the gain when that happens, which is really quite small, is less than the cost of using a shared library. Needless to say, I also have not done any measurements. Ian
Re: Trouble doing bootstrap
* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 08:43:51PM CEST: > Ralf Wildenhues writes: > > OK. I won't argue my point further, but I am interested to learn why > > shared libraries in nonstandard locations are seemingly frowned upon > > here. Is that due to fragility of the libtool approach of relinking, > > or for relocatability issues of the installed program? > > 1) We don't use libtool to build gcc. I know. That's easily "fixed" though.[1] Whether one uses the tool or reinvents or reuses part of the functionality is a different question than whether some functionality itself is desirable or not, however. > 2) If we did use libtool to build gcc, then, yes, I would be concerned >about the relinking issue. Why? Because of 'make install' run as root? Any other reasons? > 3) Shared libraries are less efficient. You get some efficiency back if >the libraries are in fact shared by multiple different executables >running simultaneously. But in this case it is relatively unlikely >that gmp, mpfr, and mpc will actually be used by any executable other >than gcc. It is not so unlikely that multiple instances of cc1, cc1plus, and f951 are running simultaneously. Granted, I haven't done any measurements. >So why make them shared libraries? We lose something, as >can be seen by the number of times this has come up in gcc-help. We >gain nothing. Well, we *could* make hardcoding the default in order to cope with gcc-help.[2] > 4) People sometimes suggest seeing the DT_RPATH/DT_RUNPATH of the >executable to point to the shared library locations. Past experience >has shown that this is a bad idea for some organizations. Some >places mount /usr/local/lib or other directories over NFS. Putting >that in DT_RPATH/DT_RUNPATH causes the dynamic linker to search those >directories at program startup. That causes startup to be much >slower, and can even cause it to hang until the NFS server returns. >That is not desirable for the compiler. Good points. Thanks, Ralf [1] I'll hope you'll excuse me playing devil's advocate here. ;-) [2] Oops. Twice in one message.
Re: Trouble doing bootstrap
Ralf Wildenhues writes: > * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST: >> Ralf Wildenhues writes: >> > Provide a configure switch --with-hardcoded-gccdeps that adds run path >> > entries for pre-installed support libraries? >> >> I'm fine with that, but it just introduces another configure option for >> people to learn about. If we have to teach people something, I'd rather >> teach them to use --disable-shared when they build the libraries >> themselves. > > OK. I won't argue my point further, but I am interested to learn why > shared libraries in nonstandard locations are seemingly frowned upon > here. Is that due to fragility of the libtool approach of relinking, > or for relocatability issues of the installed program? 1) We don't use libtool to build gcc. 2) If we did use libtool to build gcc, then, yes, I would be concerned about the relinking issue. 3) Shared libraries are less efficient. You get some efficiency back if the libraries are in fact shared by multiple different executables running simultaneously. But in this case it is relatively unlikely that gmp, mpfr, and mpc will actually be used by any executable other than gcc. So why make them shared libraries? We lose something, as can be seen by the number of times this has come up in gcc-help. We gain nothing. 4) People sometimes suggest seeing the DT_RPATH/DT_RUNPATH of the executable to point to the shared library locations. Past experience has shown that this is a bad idea for some organizations. Some places mount /usr/local/lib or other directories over NFS. Putting that in DT_RPATH/DT_RUNPATH causes the dynamic linker to search those directories at program startup. That causes startup to be much slower, and can even cause it to hang until the NFS server returns. That is not desirable for the compiler. Ian
Re: Trouble doing bootstrap
* Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 06:56:27PM CEST: > Ralf Wildenhues writes: > > Provide a configure switch --with-hardcoded-gccdeps that adds run path > > entries for pre-installed support libraries? > > I'm fine with that, but it just introduces another configure option for > people to learn about. If we have to teach people something, I'd rather > teach them to use --disable-shared when they build the libraries > themselves. OK. I won't argue my point further, but I am interested to learn why shared libraries in nonstandard locations are seemingly frowned upon here. Is that due to fragility of the libtool approach of relinking, or for relocatability issues of the installed program? Thanks, Ralf
Re: Trouble doing bootstrap
Ralf Wildenhues writes: > * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 03:07:46AM CEST: >> Paul Koning writes: >> > My build system doesn't have LD_LIBRARY_PATH defined so whatever is >> > the Linux default would apply. Perhaps I should change that. But it >> > seems strange that configure finds the prerequisites and then ends up >> > generating makefiles that produce a compiler that can't find those >> > things, even when it's built into the same /usr/local as the libraries >> > it depends on. >> >> Yes, it's a mess. But we don't know of any really clean way to fix it. > > Provide a configure switch --with-hardcoded-gccdeps that adds run path > entries for pre-installed support libraries? I'm fine with that, but it just introduces another configure option for people to learn about. If we have to teach people something, I'd rather teach them to use --disable-shared when they build the libraries themselves. > Of course the same could be done for when support libraries are built as > part of the GCC source tree, but then we'd have to know about whether > run path entries override LD_LIBRARY_PATH settings, and/or might need to > relink upon installation in order to not use old preinstalled stuff > while inside the build tree ... There is no problem when the support libraries are built as part of the gcc source tree, because in that case the build system automatically configures them with --disable-shared. Ian
Re: Trouble doing bootstrap
On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote: > Paul Koning writes: > >> My build system doesn't have LD_LIBRARY_PATH defined so whatever is >> the Linux default would apply. Perhaps I should change that. But it >> seems strange that configure finds the prerequisites and then ends up >> generating makefiles that produce a compiler that can't find those >> things, even when it's built into the same /usr/local as the libraries >> it depends on. > > Yes, it's a mess. But we don't know of any really clean way to fix it. > > I very strongly recommend that if you want to build gcc's supporting > libraries yourself, rather than getting them from your distro, that you > configure them with --disable-shared when you build them. > > Or, if you must, add /usr/local/lib to your /etc/ld.so.conf file or to > one of your /etc/ld.so.conf.d files, and run ldconfig. I tried the static-only approach. That worked for quite a while and then blew up with some java bits complaining they couldn't find libgmp.so. So for now I'm doing the ldconfig thing. paul
Re: Trouble doing bootstrap
On 14 October 2010 02:07, Paul Koning wrote: > > Explicitly setting LD_LIBRARY_PATH seems to cure the problem. It would be > good to have that called out in the procedures (or, preferably, made not to > be necessary). As Ian pointed out, it's documented under --with-mpc et al, although I only added that note recently. I find building the support libs in-tree is easiest, followed by installing them separately but with --disable-shared
Re: Trouble doing bootstrap
Hello, * Ian Lance Taylor wrote on Thu, Oct 14, 2010 at 03:07:46AM CEST: > Paul Koning writes: > > My build system doesn't have LD_LIBRARY_PATH defined so whatever is > > the Linux default would apply. Perhaps I should change that. But it > > seems strange that configure finds the prerequisites and then ends up > > generating makefiles that produce a compiler that can't find those > > things, even when it's built into the same /usr/local as the libraries > > it depends on. > > Yes, it's a mess. But we don't know of any really clean way to fix it. Provide a configure switch --with-hardcoded-gccdeps that adds run path entries for pre-installed support libraries? Of course the same could be done for when support libraries are built as part of the GCC source tree, but then we'd have to know about whether run path entries override LD_LIBRARY_PATH settings, and/or might need to relink upon installation in order to not use old preinstalled stuff while inside the build tree ... but I digress with a problem that has already been solved elsewhere, which I suppose is not acceptable to GCC for some reason. Cheers, Ralf
Re: Trouble doing bootstrap
Paul Koning writes:
> Explicitly setting LD_LIBRARY_PATH seems to cure the problem. It
> would be good to have that called out in the procedures (or,
> preferably, made not to be necessary).
It actually is in the install docs, though of course suggestions for
improvements are always welcome.
You might also need to ensure the shared libraries can be found by
the dynamic linker when building and using GCC, for example by
setting the runtime shared library path variable
(@env{LD_LIBRARY_PATH} on GNU/Linux and Solaris systems).
Ian
Re: Trouble doing bootstrap
On Oct 13, 2010, at 9:07 PM, Ian Lance Taylor wrote: > Paul Koning writes: > >> My build system doesn't have LD_LIBRARY_PATH defined so whatever is >> the Linux default would apply. Perhaps I should change that. But it >> seems strange that configure finds the prerequisites and then ends up >> generating makefiles that produce a compiler that can't find those >> things, even when it's built into the same /usr/local as the libraries >> it depends on. > > Yes, it's a mess. But we don't know of any really clean way to fix it. > > I very strongly recommend that if you want to build gcc's supporting > libraries yourself, rather than getting them from your distro, that you > configure them with --disable-shared when you build them. > > Or, if you must, add /usr/local/lib to your /etc/ld.so.conf file or to > one of your /etc/ld.so.conf.d files, and run ldconfig. Thanks, the static-only approach sounds good. I had to build my own instead of using the distro ones since those aren't up to date. Either that or I'm mixed up with my other test system (a Mac). paul
Re: Trouble doing bootstrap
Paul Koning writes: > My build system doesn't have LD_LIBRARY_PATH defined so whatever is > the Linux default would apply. Perhaps I should change that. But it > seems strange that configure finds the prerequisites and then ends up > generating makefiles that produce a compiler that can't find those > things, even when it's built into the same /usr/local as the libraries > it depends on. Yes, it's a mess. But we don't know of any really clean way to fix it. I very strongly recommend that if you want to build gcc's supporting libraries yourself, rather than getting them from your distro, that you configure them with --disable-shared when you build them. Or, if you must, add /usr/local/lib to your /etc/ld.so.conf file or to one of your /etc/ld.so.conf.d files, and run ldconfig. Ian
Re: Trouble doing bootstrap
On Oct 13, 2010, at 6:41 PM, Dave Korn wrote: > On 13/10/2010 22:34, Paul Koning wrote: > >> On my Linux system (CentOS 5.5) I'm trying to do a bootstrap of the current >> trunk. I have the dependencies (mpc, mfpr, gmp) installed. >> >> Did configure, no issues. >> >> Did "make bootstrap". Stage 1 runs clean up to >> "configure-stage1-target-libgcc" where it runs into "can't compile". >> >> Config.log reveals that cc1 (the one that was just built) can't find >> libmpc.so. >> >> Why not? It's installed... is it looking in the wrong place? I would >> expect a simple configure with a simple make bootstrap to do the right >> thing. >> >> I tried configure with --with-mpc pointing to the right mpc explicitly. No >> difference, same failure at the same spot. >> >> Do I need to have mpc in the build tree so it's built along with gcc? That >> seems strange, and it certainly isn't documented in >> http://gcc.gnu.org/contribute.html > > If mpc isn't in your standard $prefix, you'll need to point at it using > LD_LIBRARY_PATH. > >cheers, > DaveK Explicitly setting LD_LIBRARY_PATH seems to cure the problem. It would be good to have that called out in the procedures (or, preferably, made not to be necessary). paul
Re: Trouble doing bootstrap
On Oct 13, 2010, at 6:41 PM, Dave Korn wrote: > On 13/10/2010 22:34, Paul Koning wrote: > >> On my Linux system (CentOS 5.5) I'm trying to do a bootstrap of the current >> trunk. I have the dependencies (mpc, mfpr, gmp) installed. >> >> Did configure, no issues. >> >> Did "make bootstrap". Stage 1 runs clean up to >> "configure-stage1-target-libgcc" where it runs into "can't compile". >> >> Config.log reveals that cc1 (the one that was just built) can't find >> libmpc.so. >> >> Why not? It's installed... is it looking in the wrong place? I would >> expect a simple configure with a simple make bootstrap to do the right >> thing. >> >> I tried configure with --with-mpc pointing to the right mpc explicitly. No >> difference, same failure at the same spot. >> >> Do I need to have mpc in the build tree so it's built along with gcc? That >> seems strange, and it certainly isn't documented in >> http://gcc.gnu.org/contribute.html > > If mpc isn't in your standard $prefix, you'll need to point at it using > LD_LIBRARY_PATH. > >cheers, > DaveK Just before retrying the bootstrap, I grabbed each of the 3 prerequisites from the "infrastructure" directory on the gnu ftp server. Built and installed them with no-argument "configure" so they end up in /usr/local/. Did the same with gcc. My build system doesn't have LD_LIBRARY_PATH defined so whatever is the Linux default would apply. Perhaps I should change that. But it seems strange that configure finds the prerequisites and then ends up generating makefiles that produce a compiler that can't find those things, even when it's built into the same /usr/local as the libraries it depends on. paul
Re: Trouble doing bootstrap
On 13/10/2010 22:34, Paul Koning wrote: > On my Linux system (CentOS 5.5) I'm trying to do a bootstrap of the current > trunk. I have the dependencies (mpc, mfpr, gmp) installed. > > Did configure, no issues. > > Did "make bootstrap". Stage 1 runs clean up to > "configure-stage1-target-libgcc" where it runs into "can't compile". > > Config.log reveals that cc1 (the one that was just built) can't find > libmpc.so. > > Why not? It's installed... is it looking in the wrong place? I would > expect a simple configure with a simple make bootstrap to do the right > thing. > > I tried configure with --with-mpc pointing to the right mpc explicitly. No > difference, same failure at the same spot. > > Do I need to have mpc in the build tree so it's built along with gcc? That > seems strange, and it certainly isn't documented in > http://gcc.gnu.org/contribute.html If mpc isn't in your standard $prefix, you'll need to point at it using LD_LIBRARY_PATH. cheers, DaveK
