How do I disable all libaries (including runtime)?

[Griwes]

http://en.wikipedia.org/wiki/Dunning%E2 ... ger_effect

Get a dual boot with Linux or install Linux in VM if it takes so long on your Cygwin.

Again, that is THE solution for using GCC for OSDev, generally.

[qw]

I stated in my first post that I wasn't going to build a GCC cross compiler, and politely asked that people not even suggest it.

"Some questions are logically nonsensical because the querent thinks they know more than they do. A lot of these have the form ‘How do I use X to accomplish Y?’ There's nothing wrong with this, except that sometimes X is a chocolate-covered banana and Y is the integration of European currency systems."

Put down the chocolate-covered banana and step away from the European currency systems.

[thepowersgang]

Let's also note that you appear to be using cygwin, which is evil. (Not being mean to it, it does wonderous things, but it has to be evil to achieve them)

If compiling on windows, you WILL need a cross-compiler (which, due to the way windows works, WILL take a while to compile). I'd also suggest using MinGW and msys instead of cygwin, as they don't do UNIX emulation (but do present a unix-like filesystem) and are hence more efficient.

[Kazinsal]

Third party input with regards to build times: On my quad-core i7, Cygwin building a GCC cross compiler takes close to four hours. Same processor, Ubuntu in VirtualBox, about half an hour. Same on Ubuntu on bare metal. About fourty-five minutes on my Core 2 Quad server, which is also spending a chunk of processor time running a Source dedicated server.

OP, build a cross compiler in an environment that isn't a bunch of hacks on top of each other. Your problems will be solved. Thank us later.

[Owen]

Same processor, MinGW/msys, about 35mins, I'd expect.

Cygwin is @$$ slow, but it has to be

[Love4Boobies]

Building a GCC cross-compiler and cross-Binutils with MinGW is faster but it isn't that fast, unfortunately. It took me about 1:30 on a Core i7. I'd also like to report that I was able to build kernels with both MinGW and a native Linux port, using -ffreestanding. I'm not sure the same is possible with Cygwin, though.

[bluemoon]

It's quite impressive that building cross compiler on windows would take so long.

I just rebuild a gcc 4.6.3 (core, g++) on my mac with:
1. making a 512MB ram drive (few seconds)
2. unzip them (few seconds)
3. configure (few seconds)
4. time make -j 12 all-gcc, the result is:

Code: Select all

real	1m11.918s
user	7m50.714s
sys	0m59.167s

[Jezze]

You've got 12 cpus!?

[xenos]

Usually when there is a new GCC version out, I build a new set of cross compilers and it takes me about half a day on Ubuntu 12.04. That is, building gcc core and C++ for i686, x86_64, arm, mips and m68k. All I need to do is fire up my automated build script in the morning (or in the evening and have it run at night).

[Griwes]

You've got 12 cpus!?

One usually set make's -j to 1.5 * logical cores of machine.
At least I do so, others may have other ways to determine amount of make workers, dunno.

[SoulofDeity]

I stated in my first post that I wasn't going to build a GCC cross compiler, and politely asked that people not even suggest it.

"Some questions are logically nonsensical because the querent thinks they know more than they do. A lot of these have the form ‘How do I use X to accomplish Y?’ There's nothing wrong with this, except that sometimes X is a chocolate-covered banana and Y is the integration of European currency systems."

Put down the chocolate-covered banana and step away from the European currency systems.

I wasn't saying building a cross-compiler is wrong, I was just asking for an alternative solution.

I know I'm a **** a lot when it comes to programming, and it's not that I think I'm high and mighty or anything, I just get pissed off at how ridiculously hard people make things. Most libraries are extremely messy, inflated, hard to port, error prone (both during the build stage and at run time), slow, and overall complicated to use.
Take for example libpng. There's a ton of different instructions for reading the file through filters, having to read signatures, allocating and struct and info pointers, etc. Why make it so complicated? Just make a function "png_readImage(void *buffer, int width, int height, int line)". Or for example the truetype library, why all the unnecessary functions? Just open the file (parsing the glyph information) and give them a "renderGlyph" function.
I'm probably gonna get spammed by standard junkies and people just calling me stupid...but honestly think there needs to be a new standard for everything. That's why I got into OS development.

/rant over

[bluemoon]

Take for example libpng. There's a ton of different instructions for reading the file through filters, having to read signatures, allocating and struct and info pointers, etc. Why make it so complicated? Just make a function "png_readImage(void *buffer, int width, int height, int line)".

I'm not commenting on the code quality of libpng, I appreciate their effort, after all it's free.
My opinion is when deal with 3rd party libraries, always abstract(ie. warp) it with an interface and work with that interface for the rest of your project. The side-effect is that no matter how messy or complicate the libraries is, you only need to directly use it once.

Take libpng as an example, I have a general image reader class looks like this, which looks pretty standard and used by most programmers:

Code: Select all

class PREFIX_PNGFile : public PREFIX_ImageFile {
public:
    virtual void close();
    virtual int  load ( const char* file );
};

But do a single png_readImage(void *buffer, int width, int height, int line), or a single interface fits everyone? No.

when dealing with android, things are stored inside ZIP file (apk file). So the resource loader need to take care of the file source (being standard file or within zip file).
In that case, thanks for the libpng functions are flexible and I can handle it with calls to png_set_read_fn(png_ptr, zfp, png_zip_read); and modify the above C++ class interface.

[SoulofDeity]

Take for example libpng. There's a ton of different instructions for reading the file through filters, having to read signatures, allocating and struct and info pointers, etc. Why make it so complicated? Just make a function "png_readImage(void *buffer, int width, int height, int line)".

I'm not commenting on the code quality of libpng, I appreciate their effort, after all it's free.
My opinion is when deal with 3rd party libraries, always abstract(ie. warp) it with an interface and work with that interface for the rest of your project. The side-effect is that no matter how messy or complicate the libraries is, you only need to directly use it once.

Take libpng as an example, I have a general image reader class looks like this, which looks pretty standard and used by most programmers:

Code: Select all

class PREFIX_PNGFile : public PREFIX_ImageFile {
public:
    virtual void close();
    virtual int  load ( const char* file );
};

But do a single png_readImage(void *buffer, int width, int height, int line), or a single interface fits everyone? No.

when dealing with android, things are stored inside ZIP file (apk file). So the resource loader need to take care of the file source (being standard file or within zip file).
In that case, thanks for the libpng functions are flexible and I can handle it with calls to png_set_read_fn(png_ptr, zfp, png_zip_read); and modify the above C++ class interface.

There's obviously more instructions that would have to be implemented such as reading from a buffer, reading png's in layers for progressive scanning, writing pngs to a file or buffer, etc. However, filters are unnecessary, having to allocate and free several structures is a hassle, and the use of jump buffers for error handling is very unsafe. (in fact, it's one of the features that caused the PSP to be exploited)

[qw]

I wasn't saying building a cross-compiler is wrong, I was just asking for an alternative solution.

Why would you want an alternative if a cross compiler is obviously the best solution? It is quite easy to build and it gets rid of all the stuff that you find so annoying. Of course it takes time to build, but you only build it once, and you lost a lot more time finding an alternative solution already.

[Griwes]

I think that's because he is some kind of hipster, who cannot use standard solutions by design.