10

I've been compiling it in a virtual machine for over 8 hours now and it still hasn't finished.

The terminal is still printing things so I know it's still compiling.

The host system is a 2.10Ghz Intel Core2Duo with 4GB RAM and the guest is Linux on a PowerPC virtual machine (QEMU) one with 1GB RAM.

I know the dynamic instruction translation can slow things down a bit but even so, Glibc shouldn't take longer than 3 hours or so?

Is there something wrong or should I just continue to let do it's thing overnight?

Improve this question
3
  • 2
    Dynamic translation slows down such processes a lot. And Glibc is a huge piece of software. Therefore the result will be near endless compile times. Why don't you simply cross-compile on the Intel host for a PowerPC target? That's probably much faster. Commented Jun 28, 2010 at 11:41
  • Thing is. I'm building a cross Linux from scratch system and it says I must continue the installation on a PowerPC machine. Since the only one I have at hand is a 15 year old PowerBook I figured it'll be faster if I ran it from a virtual machine. Commented Jun 28, 2010 at 11:46
  • over 4 hours for glibc 2.24 on nehalem Commented Apr 15, 2023 at 5:34

1 Answer 1

Reset to default
6

For comparison, the last time Ubuntu compiled eglibc for a 64-bit machines, it took about 1.75 hours for amd64, and about 2.5 hours for both i386 and powerpc

I think it's just that dynamic translation is that slow, especially dynamic translation to a different architecture.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

From the same link, I looked up the compile times for uClibc and they were way shorter. Would using uClibc be a better option in this instance?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.