Re: [gentoo-user] "checking for working mkstemp....." taking forever
Frank Steinmetzger wrote: > I've encountered the same and didn't know how to solve it. I found out that > mkstemp was some standard C function so I remerged glibc, but that didn't do > the trick. Eventuella I restarted my installation. It as i686 with 32 bit > though. Did you change CHOST maybe? python folks can't write configure.in files (-> AC_TRY_RUN() causes headaches) ... that's also why it's not crosscompile'able ;-o file a bug to python folks, it's not gentoo's fault. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] "checking for working mkstemp....." taking forever
On Wednesday 02 September 2009 16:13:12 Mike Kazantsev wrote: > On Wed, 2 Sep 2009 13:12:22 +0200 > > Alan McKinnon wrote: > > On Wednesday 02 September 2009 01:16:10 Frank Steinmetzger wrote: > > > Am Mittwoch, 2. September 2009 schrieb Nick Khamis: > > > > Hello Everyone. > > > > > > > > I am trying to update-python and I am stuck at "checking for working > > > > mkstemp." for ever, what should I do.. This is a fresh install > > > > AMD64. > > > > > > > > Thanks in Advanced, > > > > Ninus. > > > > > > I've encountered the same and didn't know how to solve it. I found out > > > that mkstemp was some standard C function so I remerged glibc, > > > > mktemp is now in coreutils > > > > It used to be in debianutils > > > > Not glibc. > > I believe you're confusing mktemp with mkstemp, the latter being C > function indeed - man 3 mkstemp. You are correct and I am :-) I even double checked to make sure I was on the right track and could have sworn I saw mktemp somewhere in the OPs mail... It must be this bloody flu. Makes one's eyes work poorly... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] "checking for working mkstemp....." taking forever
On Wed, 2 Sep 2009 13:12:22 +0200 Alan McKinnon wrote: > On Wednesday 02 September 2009 01:16:10 Frank Steinmetzger wrote: > > Am Mittwoch, 2. September 2009 schrieb Nick Khamis: > > > Hello Everyone. > > > > > > I am trying to update-python and I am stuck at "checking for working > > > mkstemp." for ever, what should I do.. This is a fresh install > > > AMD64. > > > > > > Thanks in Advanced, > > > Ninus. > > > > I've encountered the same and didn't know how to solve it. I found out that > > mkstemp was some standard C function so I remerged glibc, > > mktemp is now in coreutils > > It used to be in debianutils > > Not glibc. I believe you're confusing mktemp with mkstemp, the latter being C function indeed - man 3 mkstemp. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature
Re: [gentoo-user] "checking for working mkstemp....." taking forever
On Wednesday 02 September 2009 01:16:10 Frank Steinmetzger wrote: > Am Mittwoch, 2. September 2009 schrieb Nick Khamis: > > Hello Everyone. > > > > I am trying to update-python and I am stuck at "checking for working > > mkstemp." for ever, what should I do.. This is a fresh install > > AMD64. > > > > Thanks in Advanced, > > Ninus. > > I've encountered the same and didn't know how to solve it. I found out that > mkstemp was some standard C function so I remerged glibc, mktemp is now in coreutils It used to be in debianutils Not glibc. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] "checking for working mkstemp....." taking forever
I did not change CHOST just CFLAGS and CXXFLAGS as per the manual. h Regards, Ninus
Re: [gentoo-user] "checking for working mkstemp....." taking forever
Am Mittwoch, 2. September 2009 schrieb Nick Khamis: > Hello Everyone. > > I am trying to update-python and I am stuck at "checking for working > mkstemp." for ever, what should I do.. This is a fresh install AMD64. > > Thanks in Advanced, > Ninus. I've encountered the same and didn't know how to solve it. I found out that mkstemp was some standard C function so I remerged glibc, but that didn't do the trick. Eventuella I restarted my installation. It as i686 with 32 bit though. Did you change CHOST maybe? -- Gruß | Greetings | Qapla' No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] checking for.....
* Alan McKinnon <[EMAIL PROTECTED]> wrote: > > You are expecting autoconf to actually do something sane when it runs??? > *rofl* The point is: the way autoconf does its 'checks' is completely insane - beginning with the expectation that an dumb script is more clever than an operator ;-o I've did a lot research in this area some time ago and came the conclusion, that autoconf cannot be fixed - it's broken by design. So I developed unitool: http://unitool.metux.de/ It uses an system/target-wide config database which can be either auto-generated or tweaked manually. I'm currently in the process of redesigning the database scheme to be more convenient and flexible and also allow several autoconf macros (eg. AC_CHECK_HEADER, ...) to directly query that config database. So autoconf can be easily rewritten to at least do a large bunch of checks via that db instead of compiling test programs. If anyone's interested in it, please let me know. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
Brandon Mintern ha scritto: I had thought the same thing myself some time ago, and I discovered that there had been work on a FEATURE called confcache. I believe it was abandoned, though, due to major difficulties. This is merely a guess, but I think some of the problems arise in that some of the things that are checked for actually change as a package is installed or updated (e.g. checking gcc version). This means that each package being installed would have to somehow flag confcache and indicate that it has changed, and confcache would have to keep a list of all these cached values and their dependencies. What was the problem with that? Ebuilds of stuff like gcc could be tailored to flag confcache. Otherwise, emerge could do the relevant checks before emerging the first package, and be trained to do them again after a known "troublesome" package has been emerged. I understand this requires coordination and maintaining, of course, and that's the non-trivial part, I guess. However, are there many packages affecting common configure checks? If they are, say, less than 10 affecting 80% of configure flags, it seems worth the hassle. If troubles arise, one can quickly try with confcache disabled, and debug. Heck, I'd help with it myself, if only I had some confidence with portage code and C compilation (However, I know Python, FWIW) m. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
On Fri, 02 May 2008 11:25:41 +0200 Wolf Canis wrote: > Brandon Mintern wrote: > > ccache caches the compile step. I believe the OP was specifically > > looking for something that would cache the answers to the "checking > > for" lines (the configuration step). > > Yes, you are right, but I thought that ccache cached parts of the > configuration too. > That's what I noticed in outputs during the build process. Perhaps my > conclusion > is wrong. > > W. Canis As part of identifying the capabilities and files of your operating system (distro) ./configure creates a lot of small programs and compiles them. I can see how caching compilation info would help with this. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
Brandon Mintern wrote: ccache caches the compile step. I believe the OP was specifically looking for something that would cache the answers to the "checking for" lines (the configuration step). Yes, you are right, but I thought that ccache cached parts of the configuration too. That's what I noticed in outputs during the build process. Perhaps my conclusion is wrong. W. Canis signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] checking for.....
ccache caches the compile step. I believe the OP was specifically looking for something that would cache the answers to the "checking for" lines (the configuration step). On Fri, May 2, 2008 at 4:49 AM, Wolf Canis <[EMAIL PROTECTED]> wrote: > [snip] > > Hello, > "ccache" does caching, I use it and I'm very satisfied. > > W. Canis -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
[EMAIL PROTECTED] wrote: In the middle of doing a major upgrade from very old pkgs to current 2008 and compiling lots and lots of stuff. Seeing that line `checking for WHATEVER' go by 486,211 times so far makes me wonder if there wouldn't be someway to cache all those answers somewhere so whatever test is done for each line could be dispensed with for most of them. Probably would need more than 2-3 compiles to have all but rare ones answered. Some items really check a lot of things. I think it would be a major time saver when discussing huge numbers of compiles. Hello, "ccache" does caching, I use it and I'm very satisfied. W. Canis signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] checking for.....
On Thursday 01 May 2008, Alan McKinnon wrote: > On Thursday 01 May 2008, [EMAIL PROTECTED] wrote: > > In the middle of doing a major upgrade from very old pkgs to > > current 2008 and compiling lots and lots of stuff. > > > > Seeing that line `checking for WHATEVER' go by 486,211 times so > > far makes me wonder if there wouldn't be someway to cache all > > those answers somewhere so whatever test is done for each line > > could be dispensed with for most of them. Probably would need > > more than 2-3 compiles to have all but rare ones answered. > > > > Some items really check a lot of things. > > > > I think it would be a major time saver when discussing huge > > numbers of compiles. > > You are expecting autoconf to actually do something sane when it > runs??? > > Har har. > You must be new here. > > :-) > > That problem has been discussed about 486,212 times and solved > about 0 times. Fortunately, more packages go over to cmake. Just a matter of time. Uwe -- Ignorance killed the cat, sir, curiosity was framed! -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
On Thursday 01 May 2008, [EMAIL PROTECTED] wrote: > In the middle of doing a major upgrade from very old pkgs to current > 2008 and compiling lots and lots of stuff. > > Seeing that line `checking for WHATEVER' go by 486,211 times so far > makes me wonder if there wouldn't be someway to cache all those > answers somewhere so whatever test is done for each line could be > dispensed with for most of them. Probably would need more than 2-3 > compiles to have all but rare ones answered. > > Some items really check a lot of things. > > I think it would be a major time saver when discussing huge numbers > of compiles. You are expecting autoconf to actually do something sane when it runs??? Har har. You must be new here. :-) That problem has been discussed about 486,212 times and solved about 0 times. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for.....
On Thu, May 1, 2008 at 3:11 PM, <[EMAIL PROTECTED]> wrote: > In the middle of doing a major upgrade from very old pkgs to current > 2008 and compiling lots and lots of stuff. > > Seeing that line `checking for WHATEVER' go by 486,211 times so far > makes me wonder if there wouldn't be someway to cache all those > answers somewhere so whatever test is done for each line could be > dispensed with for most of them. Probably would need more than 2-3 > compiles to have all but rare ones answered. > > Some items really check a lot of things. > > I think it would be a major time saver when discussing huge numbers > of compiles. > > > -- > gentoo-user@lists.gentoo.org mailing list I had thought the same thing myself some time ago, and I discovered that there had been work on a FEATURE called confcache. I believe it was abandoned, though, due to major difficulties. This is merely a guess, but I think some of the problems arise in that some of the things that are checked for actually change as a package is installed or updated (e.g. checking gcc version). This means that each package being installed would have to somehow flag confcache and indicate that it has changed, and confcache would have to keep a list of all these cached values and their dependencies. I think there might be potential, however, for something that cached some of the more common system checks such as number of command line arguments. Then again, if many of these configuration items are discovered through a simple system call or by running a quick command, I'm not sure how much faster something like confcache would actually be. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
On Saturday 11 August 2007 20:53:59 Canek Peláez wrote: > On 8/11/07, Mark Knecht <[EMAIL PROTECTED]> wrote: > > Hi, > >emerge gnome fails. Does anyone recognize what portage is > > complaining about here? > > I'm not really sure, but I solved it by reemerging dev-perl/XML-Parser. > -- > Canek Peláez Valdés > Facultad de Ciencias, UNAM Confirmed -- Guillermo Antonio Amaral Bastidas # Free & Open Source Software Advocate # KDE Developer: gamaral $ irc: [EMAIL PROTECTED] @ blog: http://blog.guillermoamaral.com/ @ site: http://www.guillermoamaral.com/ % gpg: http://downloads.guillermoamaral.com/public.asc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
On 8/11/07, Mark Knecht <[EMAIL PROTECTED]> wrote: > Hi, >emerge gnome fails. Does anyone recognize what portage is > complaining about here? I'm not really sure, but I solved it by reemerging dev-perl/XML-Parser. -- Canek Peláez Valdés Facultad de Ciencias, UNAM -- [EMAIL PROTECTED] mailing list
