From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PZWzX-0004aK-Cd for garchives@archives.gentoo.org; Sun, 02 Jan 2011 23:05:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E40F6E0780 for ; Sun, 2 Jan 2011 23:05:34 +0000 (UTC) Received: from mailgate.caprica.metux.de (caprica.metux.de [82.165.128.25]) by pigeon.gentoo.org (Postfix) with ESMTP id 9D1D0E076E for ; Sun, 2 Jan 2011 22:45:16 +0000 (UTC) Received: from mailgate.caprica.metux.de (localhost.localdomain [127.0.0.1]) by mailgate.caprica.metux.de (8.14.4/8.14.4) with ESMTP id p02Mf1eX017439 for ; Sun, 2 Jan 2011 23:41:02 +0100 Received: (from uucp@localhost) by mailgate.caprica.metux.de (8.14.4/8.14.4/Submit) with UUCP id p02MeiJ4017418 for gentoo-embedded@lists.gentoo.org; Sun, 2 Jan 2011 23:40:44 +0100 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id p02McAuJ029027 for gentoo-embedded@lists.gentoo.org; Sun, 2 Jan 2011 23:38:10 +0100 Date: Sun, 2 Jan 2011 23:38:10 +0100 From: Enrico Weigelt To: gentoo-embedded@lists.gentoo.org Subject: Re: [gentoo-embedded] configure: error: C++ compiler cannot create executables Message-ID: <20110102223809.GB10971@nibiru.local> References: <20101230062751.GA10596@nibiru.local> <20101231011509.GA2178@nibiru.local> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-Archives-Salt: 2b211c34-0262-4404-9cb0-c60821bf00ec X-Archives-Hash: 1866dcce058fc4e734d0e388b25275f2 * Kfir Lavi schrieb: > Well, you are a purist ;-) At this point, yes ;-p > The thing is, I must use this ACE libs, and they are broken. > I have also so many other things to get working, I just have to live with > this approach. Yep, I know lots of those situations where you have to get the job done, but stumble across dozens of problems which would have been prevented by proper development methods and workflows. Just experiencing that at my current customer, where they don't even have a proper vcs (TFS is even more insane than SVN ;-o) > Your method regenerating the ./configure script, is very good, And often it's necessary, when you have the configure.in stuff. > and I'm asking myself, why its not done every install, or why we > get ./configure generated in the tar.gz. These arguments I've heared over the years: a) save time and cpu cycles for end users b) get around autotools version conflicts c) we always did so, so why change ? I dont buy any of them. There're better solutions. The best solution, IMHO, would be replacing all these dubious macros by a bunch of carefully written shell functions. Something like AC_CHECK_HEADER([foo.h],[do-something-if-found],[do-someting-if-not-found]) could be easily replaced by: if ac_check_header foo.h ; then do-something-if-found else do-something-if-not-found fi There would be no generation phase at all. I've started some hacking on that for zlib, a while ago. Maybe somebody might like to join me ... > > I'm even going farer: if upstream has an proper vcs, I take the > > releases from there, completely regenerating everything from > > scratch. All fixes are done within my VCS (essentially, I always > > have my own releases ontop the upstream's, as git tags). Sometimes > > you encounter packages, eg. coreutils, which doing really messy > > things like pulling in another tree via git and copying in files > > from there - a nightmare for packagers ;-o > > > > I wonder, do you patch every ebuild to do just that? > > Maybe there should be a new FEATURE that request the ebuild to download the > release from the VCS. That probably multiplies the QM load to the ebuild maintainers, as they would have to maintain different versions with the same version number. And the benefit is questionable. I'd rather propose (on per-package basis) directly maintain the sources (including dist-specific changes) in an own repository, so the whole download+unpack+patch phase is replaced by just a checkout, and things like rebasing dist-specific changes can be done directly via vcs. These repositories can now also be used easily by other folks, distros can monitor and share their changes easily. http://www.metux.de/download/oss-qm/normalized_repository.pdf cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------