|
From: Jason G. <jga...@la...> - 2003-09-06 12:50:42
|
Two things> 1) Latest RPM isn't always the latest version of make. You can get all the GNU stuff here: ftp://ftp.gnu.org/pub.gnu 2) RH has been known to make changes to software before they package it. It's possible you have the latest RH RPM of make and it's still broken because they broke it. If in doubt, 'use the source'. Jason > -----Original Message----- > From: Dirk Mueller [mailto:dm...@gm...] > Sent: Saturday, September 06, 2003 8:04 AM > To: val...@li... > Subject: Re: [despammed] Re: [Valgrind-users] RH9 > > On Saturday 06 September 2003 13:29, Nigel Horne wrote: > > > > Try upgrading > > > to a more recent version of 'make'. > > I have the latest RPM already. > > then the rpm is still broken. it works with any reasonably > recent make. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Tom H. <th...@cy...> - 2003-09-06 13:37:18
|
In message <287...@se...>
Jason Gauthier <jga...@la...> wrote:
> 1) Latest RPM isn't always the latest version of make.
> You can get all the GNU stuff here: ftp://ftp.gnu.org/pub.gnu
I know that - where do you I looked to check how recent the RH version
of make was...
> 2) RH has been known to make changes to software before they package it.
> It's possible you have the latest RH RPM of make and it's still broken
> because they broke it.
I know that as well. In this case though the assertion in question
is apparently a well known issue in that version of make and is nothing
to do with any RH patches. I don't understand why different people using
the same build of make see different results though - unless there's an
uninitialised memory read in make of course ;-)
> If in doubt, 'use the source'.
I disagree. The whole point of using a well known distribution is to
save yourself the bother of having to build everything yourself, so
my rule is to use the RH vesion unless I have a good reason not to do
so. Even then I normally take the newer source and rebuild the RPM using
the RH spec file and any patches, at least in the first instance.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nigel H. <nj...@ba...> - 2003-09-06 13:47:01
|
On Saturday 06 Sep 2003 2:36 pm, Tom Hughes wrote: > > If in doubt, 'use the source'. > > I disagree. The whole point of using a well known distribution is to > save yourself the bother of having to build everything yourself Exactly. > Tom -Nigel -- Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk |
|
From: Dan K. <da...@ke...> - 2003-09-06 20:18:58
|
Nigel Horne wrote: > On Saturday 06 Sep 2003 2:36 pm, Tom Hughes wrote: > >>>If in doubt, 'use the source'. >> >>I disagree. The whole point of using a well known distribution is to >>save yourself the bother of having to build everything yourself > > > Exactly. Y'all can disagree 'til you're blue in the face, but if Valgrind won't build with RH9 because RH9 ships with a broken make, you won't get anywhere until you install a working one. That said, valgrind-20030725 builds fine for me on RH9 with its make. No idea what's up with your copy. If I were you, I'd install a fresh copy of the latest gnu make just to see if that made a difference. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Steve G <lin...@ya...> - 2003-09-07 02:42:02
|
>If I were you, I'd install a fresh copy of the latest >gnu make just to see if that made a difference. I wouldn't. If you install a tarball over an rpm, you might get some of the directories wrong and then you have files all over the place that aren't tracked by rpm. The proper thing to do, is figure out how to reliably reproduce the bug, file a bugzilla bug report, and look in rawhide's srpms to get the latest official release. Build it and see if that takes care of it. It won't get better without a bug report. If there's a bug report already covering the problem add to it. They may not have a reliable test case. It also wouldn't hurt to mention it on the RH9 mail list. FWIW, I use RH9 and have no problems compiling either. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Dan K. <da...@ke...> - 2003-09-07 04:37:29
|
Steve G wrote: >>If I were you, I'd install a fresh copy of the latest >>gnu make just to see if that made a difference. > > > I wouldn't. If you install a tarball over an rpm, you might get > some of the directories wrong and then you have files all over > the place that aren't tracked by rpm. Yes, that would be messy. However, if you install the new make in /usr/local, there's no conflict, as it turns out. And /usr/local is the default install destination, so it's fairly safe. > The proper thing to do, is figure out how to reliably reproduce > the bug, file a bugzilla bug report, and look in rawhide's srpms > to get the latest official release. Build it and see if that > takes care of it. It won't get better without a bug report. If > there's a bug report already covering the problem add to it. They > may not have a reliable test case. It also wouldn't hurt to > mention it on the RH9 mail list. > > FWIW, I use RH9 and have no problems compiling either. Yep, reproducing it and boiling it down to a minimal test case, and then reporting it, is totally the way to make progress. However, when reporting the bug, it's always nice to be able to say "... and the bug doesn't happen in the latest GNU version installed from source." - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Steve G <lin...@ya...> - 2003-09-07 11:45:51
|
>However, if you install the new make in /usr/local, there's >no conflict, as it turns out. And /usr/local is the default >install destination rpm -ql make You will see nothing that goes into /usr/local. This is just the kind of accident that makes a mess out of your system. Try building the srpm from rawhide and install the resulting binary package. Its a safer course of action and slightly newer than RH 9's. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Greg H. <gr...@ho...> - 2003-09-07 13:57:56
|
On 07-Sep-2003 Dan Kegel wrote: > Steve G wrote: >>>If I were you, I'd install a fresh copy of the latest >>>gnu make just to see if that made a difference. >> >> >> I wouldn't. If you install a tarball over an rpm, you might get >> some of the directories wrong and then you have files all over >> the place that aren't tracked by rpm. > > Yes, that would be messy. However, if you install the new > make in /usr/local, there's no conflict, as it turns out. > And /usr/local is the default install destination, so it's > fairly safe. As far as I am aware, *no* distribution, has *ever* installed make, or any other major utility (or minor, for that matter) into /usr/local. best rgds, -Greg +---------------------------------------------------------------------+ You can release software that's good, software that's inexpensive, or software that's available on time. You can usually release software that has 2 of these 3 attributes -- but not all 3. | Greg Hosler gr...@ho... | +---------------------------------------------------------------------+ |
|
From: Dan K. <da...@ke...> - 2003-09-07 15:06:56
|
Greg Hosler wrote: > On 07-Sep-2003 Dan Kegel wrote: >>Steve G wrote: >>>>If I were you, I'd install a fresh copy of the latest >>>>gnu make just to see if that made a difference. >>> >>>I wouldn't. If you install a tarball over an rpm, you might get >>>some of the directories wrong and then you have files all over >>>the place that aren't tracked by rpm. >> >>Yes, that would be messy. However, if you install the new >>make in /usr/local, there's no conflict, as it turns out. >>And /usr/local is the default install destination, so it's >>fairly safe. > > As far as I am aware, *no* distribution, has *ever* installed make, or any other > major utility (or minor, for that matter) into /usr/local. That's right; that's why it's safe to install a 'make' compiled from sources into /usr/local. When you run 'configure' on the make sources, you'll see that the default installation path is /usr/local, so it's quite safe to build from sources if you just use the defaults; it's can't conflict with your system's make. Since two people seem to have misinterpreted what I wrote, here are the steps I'm suggesting: ------------- wget http://ftp.gnu.org/pub/gnu/make/make-3.80.tar.bz2 tar -xjvf make-3.80.tar.bz2 cd make-3.80 ./configure make su -c "make install" -------- This will install make to /usr/local; I just did it, and verified that's where it goes. You can then use the new make instead of the system make by putting /usr/local/bin in front of your PATH: PATH=/usr/local/bin:$PATH And voila, you're trying out make-3.80 without affecting your system's copy of make or its data files. You can revert to the system make just by setting your PATH back. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |